Proposal for simple metadata implementation

[Jesper Nøhr]

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.

> But exposing it to the user is inviting a complete disaster. Precisely
> because it's 'arbitrary', there are NO consistent, well-defined
> semantics and everyone will expect/need different behavior than what we
> provide. Not only do we need to define what happens at merge time (good
> luck with that), but we need to define every other transition as well
> (commit, copy, revert, backout, mq, etc.).

I don't agree with this. If this is a new thing, not in the core of
Mercurial, the power directly lies in that it *is* arbitrary. People
can use this for whatever purpose they see fit.

The only case we need to handle is merge. As I said, we can
monkeypatch merge and since this file is 100% immutable, there won't
be any conflicts. It's a versioned file, so
commit/copy/revert/backout/mq will all work the way they do now (well,
maybe not mq, but lets discuss that later.)

> And what happens when people want/need to change historical properties?

They can't.

> 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. Subversion uses a very similar approach to this,
and it's being used in a great number of useful ways.

As an addendum to this proposal, and I believe Benjamin Pollack will
elaborate on this any minute now, the format for storing this needs to
be expanded to include the revision number for when a property was
set. This would effectively make it a 4-tuple, (path, rev, key,
value). This solves a number of open questions that were present in my
initial proposal.

Again, this is an extension and I'm only trying to have people poke
holes in its implementation. I'm not proposing changing Mercurials
internals.


Jesper