Proposal for simple metadata implementation

Jesper Nøhr jesper at noehr.org
Wed Mar 4 09:29:03 CST 2009


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

It builds directly on top of the lose design described in
ArbitraryMetadata[1] which has been worked on by Ronny Pfannschmidt, except
that the metadata *will* be "versioned" (more on this later), and it will
only apply to files (not revisions.)

The extension would add 2 new commands to hg, something like 'setprop' and
'getprop'. setprop would set a property on a path, and getprop would print
the current value of the properties set on a path. The (key, value) pairs
themselves would be stored in a simple plaintext file, e.g.
'$(root)/.hgmetadata'. The (key, values) are stored together with a path
name, so a simple (unoptimized) format could look like this (.ini based):

[/README]
property_one = foo
property_two = bar
property_one = something else

Additionally, the extension would monkeypatch Mercurials internal merge
facility, to correctly handle conflicts on this particular file. Upon merge,
including conflicts, it would simple "intertwine" the properties. Since you
can't change or remove properties, and since duplicates are allowed, you
will never have a merge that can't be resolved automatically. Exact
duplicates will fold into just one property. Hence the user will never be
faced with any kind of metadata merge mess.

Also, as Dirkjan pointed out on IRC, what would happen for someone who isn't
using the extension? Well, a) the person would have the .hgmetadata file in
their repository just like anyone else, and b) that person will never change
this file so it will just sit there and be invisible. There are corner cases
where this file *could* potentially be in conflict, like if a person who
isn't using the extension pulls in a fork that has conflicting data. One way
we can avoid these cases is by using a simple plaintext format for the
metadata store, so that Mercurial will most likely merge these changes
without asking the users help.

Does anyone see any fundamental problems with this method? Any thoughts
appreciated.


Jesper

[1]: http://www.selenic.com/mercurial/wiki/index.cgi/ArbitraryMetadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial-devel/attachments/20090304/d8112862/attachment.htm 


More information about the Mercurial-devel mailing list