Proposal for simple metadata implementation

Jesper Nøhr jesper at noehr.org
Wed Mar 4 15:19:43 CST 2009


On Wed, Mar 4, 2009 at 8:00 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Wed, 2009-03-04 at 19:05 +0100, Jesper Nøhr wrote:
>> On Wed, Mar 4, 2009 at 6:26 PM, Matt Mackall <mpm at selenic.com> wrote:
>> >
>> > On Wed, 2009-03-04 at 16:29 +0100, Jesper Nøhr wrote:
>> > > Hi list,
>> > >
>> > >
>> > > I've been considering a stupid-simple implementation of metadata in
>> > > Mercurial. It can be done on an extension-level, and without
>> > > wireprotocol implications (unless I'm horribly mistaken.)
>> >
>> > As I've mentioned several times before, I am rabidly against supporting
>> > arbitrary metadata.
>> >
>> > We have had support in the storage format for arbitrary metadata for
>> > over 3 years. It's used for rename and rename only.
>>
>> I'm not talking about putting this in the core of Mercurial, I'm
>> talking about this as an extension or a "new" facility for exposing
>> control of metadata to the user.
>
> I don't particularly care where or how it's implemented, I still think
> it's a bad idea. Otherwise, we'd already have it, as the core support is
> already there.
>
> I can't stop you from posting an implementation, of course, but I'd
> really rather you didn't as I'll then start getting requests for
> integrating it into main, bug reports, and various helpful people
> suggesting it as a solution to various inappropriate problems. A bad
> idea with an implementation means I have to spend a lot more work
> arguing against it.

Fair enough.

[...]
>> > This feature looks deceptively simple but is in fact hopelessly
>> > complicated. Its complexity to benefit ratio is astronomical and people
>> > are guaranteed to attempt to use it in all sorts of ill-advised ways
>> > when simpler, better ways exist (see keywords).
>>
>> This is not always the case. It can be used for good, e.g. specifying
>> encodings of files.
>
> Wow, my very favorite example of an ill-advised way to use metadata. For
> starters, this value will almost always be wrong for the first check-in
> of a given file when the encoding isn't the default ("why did this come
> out garbled? oops, I forgot to set the encoding!") and because metadata
> is immutable, anything that ever uses this value in the future will
> always be doing the wrong thing.

One important point was not clear here, apparently: The metadata will
be immutable for what already exists, but you can still add more. If
you incorrectly set the mimetype on a file in the first go, you can
remedy that by adding a new mimetype for the same file. There will now
be two entries, but whatever tool uses this information, will pick the
latest one.

In a lot of cases it's last-wins, but by not having the metadata store
immutable, you're going to end up with conflicts during merges.

Anyway. You and Benjamin has both raised good points, and I now
realize my proposal was half-baked. I'll leave it at that.

Thank you both,


Jesper



More information about the Mercurial-devel mailing list