Metadata

[Marcus Sundman]

Quoting Thomas Arendsen Hein <thomas at intevation.de>:
> * Marcus Sundman <sundman at iki.fi> [20060322 10:43]:
> > Quoting Bryan O'Sullivan <bos at serpentine.com>:
> > > but if you need to, the mechanisms are there, and nice
> > > and flexible.
> > 
> > So you think it's better that everyone creates their own metadata 
> > handling system?
> 
> Yes, unless we come up with a solution which is easy to use and
> still fits _every_one's requirements.

So what's the problem with having an attribute map (key -> value-list) 
associated with each file in the repository?


> > What's the purpose of having a distributed scm if you 
> > can't use it with others anyway because your metadata-handlers are
> > incompatible?
> 
> What's the purpose of having metadata-handlers which have to be
> worked around because they can only do 90% of what people need while
> introducing 50% overhead for those who need only part of it and 200%
> for those who need just a little more?

How did you come to those numbers? Who has to work around an attribute 
system and in what way does that cause 50%-200% overhead?

To me it seems like you propose having wild tigers next to everyone so 
that those who want to get hurt (i.e. those who want to _guess_ the 
types of their files) can do so easily while people who don't want to 
get hurt (i.e. those who want to _know_ the types of their files) have 
to do a lot of work to create some kind of fence or cage or something.


> There are some "historic" threads about this topic in the ML archive
> which are worth being read.

I searched the ML archives quite a bit before posting my initial 
question, but I couldn't find much on the topic. I'm certainly 
interested in such past discussions, so I would really appreciate it if 
you'd be so kind to tell me where I could find them.


> > From afar mercurial seemed nice, but if this kind of
> > "worse-is-better" mentality is common here
> 
> I'd like this "less-magic-is-better" mentality, which is quite
> common here.

I agree that less magic is better, i.e. all processes should be clear 
and open, and the user should be in full control of them.

However, throwing away the most crucial information about a file does 
not in itself mean "less magic". It might cause "less magic" in the end, 
and if you think this is the case then I'm quite willing to hear you 
out.


> Yes, there are some cases where I think: "Oh, it would
> be nice to have this or that", but there are many moments where I
> see the problems caused by implementing such features only 90% in
> other SCMs, where this causes huge problems and needs ugly
> workarounds.

I'd be very interested in hearing more about these huge problems and 
ugly workarounds.


> Just think of newline handling in svn for repositories converted
> from CVS. With CVS not marking e.g. an image file as binary seldom
> did harm, but after converting to svn it suddenly breaks.

You're confusing the symptoms with the cause. Ignoring the file type 
like that in CVS was exactly what was causing the problem when 
converting to svn. IMO one should always strive to fix the cause rather 
than the symptoms.


> And you might want to have a look at what Monotone does here:
> http://www.venge.net/monotone/docs/File-Attributes.html
> 
> Would this fit your needs?

That looks a bit like an "ugly workaround" to me. Still, it probably 
would work well enough as long as Monotone updates the .mt-attrs before 
other files when doing an update. I haven't thought much about the 
consequences of that setup, though, so I can't feel confident that it 
won't cause nasty surprises down the road. Still, it's certainly better 
than nothing if one could easily configure one's view/edit/diff/merge 
tools to use the information in this file (e.g. by configuring Monotone 
to launch the appropriate viewer/editor/differ/merger program with the 
appropriate parameters according to the .mt-attrs file, or by using a 
meta-viewer/-editor/-differ/-merger that can take the info directly from 
the .mt-attrs file). It's a bit hairy (e.g. where should one specify 
what encoding the .mt-attrs file has?), but it might still even be the 
best alternative.


Regards,
Marcus Sundman