Proposal for simple metadata implementation

Matt Mackall mpm at selenic.com
Wed Mar 4 15:44:04 CST 2009


On Wed, 2009-03-04 at 22:19 +0100, Jesper Nøhr wrote:
> > 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.

If I check in revision x with foo.txt and a week later, I realize
"damnit, garbage in foo.txt.. I forgot to set the encoding to koi-8" and
check in revision x+423 with this fixed, what is the encoding of foo.txt
in revisions x:x+423? Presumably "", for now and forever. 

The important thing to notice here is that this kind of mistake will
happen in practice greater than 95% of the time. If a setting exists
that a user usually doesn't need to change, they will forget to change
it until after it causes something to break. Which means that this sort
of metadata is worse than unreliable. It will fail and it will fail when
it matters.

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




More information about the Mercurial-devel mailing list