Proposal for simple metadata implementation

[Matt Mackall]

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.

> > 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.

And being 'arbitrary' is also precisely its downfall. Every type of
metadata has semantics associated with it and those semantics define how
it should be manipulated by the tool. But because we allow any type of
metadata whatsoever, all semantics are possible. But the tool is only
going to implement a single (or small set) of policies. If you try to
make it cover all possible policies, it will be too complex for mortals.

> 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.)

If I copy file x with metadata x.foo=bar, do we copy that metadata or
not? If the answer is no, some people with some data (eg "encoding")
will be surprised. If the answer is yes, some (probably overlapping)
people with some different data (eg "design document reference") will be
surprised. If the policy is "we never do anything except on merge",
people will be surprised.

And I'm at a complete loss as to why you think there won't be conflicts
at merge. Can people not set conflicting properties on different
branches?

> > And what happens when people want/need to change historical properties?
> 
> They can't.

I know that and you know that, but it's just one more thing that people
will get wrong.

> > 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.

-- 
http://selenic.com : development and support for Mercurial and Linux