[MERGE REVIEW] Revert destroys file contents produced by merge

[Martin Pool]

On 24 Feb 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> Hi all,
> 
> I've gotten merge and revert to collaborate so that when you revert a
> merge, it doesn't leave any junk behind.
> 
> Files whose contents were modified by merge are deleted without being
> backed up.  

Deleted, and then replaced by the reverted-to version?

> Files that were added by merge are deleted instead of being
> unversioned.

> However, if the files are modified afterward by the user, then revert
> will handle them normally.

So if they were added and then modified, they remain as unversioned.
But if they were modified by merge, then modified by the user, they get
reverted?

> This is done my producing a list of hashes of merge-produced contents,
> in the new splatfile format.

> This file is not specified for existing tree formats, but will be
> harmlessly ignored if present.
> 
> This also introduces the splatfile format, a very simple format for
> representing lists of lists of unicode strings.
> 
> Advantages over rio:
>  - all unicode strings are legal values
>  - very simple API
>  - aside from header, 1-to-1 correspondance between lines and stanzas
>  - escaping built-in and minimal.

This looks pretty good; to me it seems to provide a "list of strings"
companion to the "list of multimaps" in rio.  I think both have a place
- splatfile more so when we don't expect new fields to be added within a
particular format or to need repeated fields.  Do you agree?

The rio api should probably be simpler; I don't think there's much value
exposing the reader or writer classes. 

Every unicode string is valid on the RHS as far as I know.

> +SPLATFILE_1_HEADER = "BZR Splatfile Format 1"

Perhaps it would be better to set the header according to what it
contains, rather than how the data is encode?  In other words perhaps
'bzr merge-modified list format 1' - that implies the data format
anyhow.

Otherwise +1 from me.

-- 
Martin