[MERGE REVIEW] Revert destroys file contents produced by merge

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> A format with one key/value pair per line is possibly easier to treat as
> a scalar merge from a weave-like form.  (It's probably still possible
> with a form that allows multi-line values, just by treating the
> most-recently-modified line as representative for the whole field.)

I think it's much tricker.  Also, you can make better guarantees about
weave file positioning when you know for sure that the key will come first.

> An early draft of rio used escape characters as splatfile does.  Someone
> (njs?) pointed out that if things like commit messages are allowed to
> extend across lines it makes it much more palatable for human readers.

I think this assumes that the commit message originator and the human
reader both use something like an 80-col display.  Otherwise, you end up
with short lines or line-wrapping in the viewer.

> The question then would be whether you want it to be only just human
> readable, or actually palatable to read.  For most files that will
> only be seen in debugging (such as a record of merge results) it's not a
> big deal.  If we want to include it in externalized changesets it's more
> important.

Sure.

> We don't use rio in the permanent data of any release so I'm happy to
> change the format if we think it'll be a better tradeoff.  I would like
> to settle it on a reasonably good tradeoff before the release.

Personally, I'd want a header so we can tell which rio version we're
reading.  But perhaps the rest of it can wait.

>>I think this is definitely true of the values.  You've managed to plant
>>a seed of doubt about keys, though.
> 
> 
> Did anything grow?

Yes.  I decided that these issues weren't hugely important, and switched
the code over to rio.  I'm not convinced that self-documenting formats
always make sense, but I'd rather get the functionality in than argue
over file formats.  Now that I understand that values can be arbitrary,
and how to use it to store a dict, I am happy enough with the format to
use it.

>>I suppose I could have written it as a multimap of {"revision-id":
>>"foo", "parent-id": "bar", "parent-id": "baz"}.  It just seemed natural
>>to write it as {"foo": "bar", "foo":"baz"}, at the time.
> 
> 
> Explicitly labelling them seems to give more room for future growth.  Of
> course we now have more of a pattern of explicitly labelling formats and
> upgrading them wholesale, which may mean this is less important.  But I
> think it's still useful.

I guess the harm I see is that
1. The correct way to use it to store maps isn't obvious.
2. It requires extra work determining the labels.
3. It's not immediately apparent how to use it to store lists of lists.

> Labelling fields does use some space but of course a particular format
> could choose to use small (even single-byte) names.  In this case giving
> the child revision-id only once is likely to be a space win.

The number of child revisions with more than one parent is relatively
small, so it's possible that eliminating labels cancels that out.  Not a
big deal either way, I think.

>>>I think allowing multiline values to span lines makes it much more
>>>readable for humans than escaping them.
>>
>>But you're not wrapping at any particular width, are you?  If so, you
>>may have an argument, but most file viewers will auto-wrap.
> 
> 
> The main case for multiline values, it seemed to me, was for multiline
> text entered by humans: at the moment only commit messages; possibly
> others in the future.  Those are likely to be of reasonable width.  If
> a viewer does wrap them that seems harmless to human legibility.

I suppose an alternative would be to force rio to be a 79-column format.
I'm not sure that's desirable.  What I meant about auto-wrapping is that
even an unwrapped format like splatfile will be fairly legible in modern
viewers, so I'm not sure it's necessary to provide wrapping in the format.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEDE1j0F+nu1YWqI0RAhEPAJ46GSjOC3YwFcd9NjSAQGsv2wK/awCfVda7
My91XRx9LBZoEzGStplt3h4=
=agp7
-----END PGP SIGNATURE-----