Re: [Monotone-devel] more merge problems

[Derek Scherger]

Nathaniel Smith wrote:
> This seems to indicate that in both branches you added a file called
> "file2", but the files added were different.  If you had a file called
> "file2" in the common ancestor and then edited it to be different in
> each branch, that would work fine, but this is a different; it's a
> tree layout conflict, not a within-file textual conflict.  Monotone
> currently has no way to deal with tree layout conflicts, and just
> bails out as you see...

That's exactly what I did, not realizing it would cause a problem. I'm just playing around 
with things at the moment trying to see how it works so it's not a big deal but it did 
make me think of a few things...

Looking at the schema it appears to me that files don't even have names independent of 
manifests (they're nothing but an sha1 version id and some data) so I'm playing around 
with a few different test cases to see how things work with this in mind.

Please note that in all of these tests I'm thinking more about what the graphs of 
manifests and files look like and what various operations might do to them rather than 
trying to solve any particular versioning problem. In this context I'm keeping the 
database very small (a few files and a few manifests) so that I can understand them.

It seems that the presence or absence of a common ancestor manifest is the crucial point 
in most of these cases.

*** Test Case 1: adding a file with the same name and same contents from two 
working copies

I expected that the second commit would NOT create a new file (since the sha1 is the same) 
and would also NOT create a new manifest (since the contents would be identical). This is 
exactly what happens but it did make me wonder what would happen with the various certs 
committed with the second manifest. It appears that the second set of date and changelong 
certs are created but they don't get listed by the log command. The branch and author 
certs don't get duplicated presumably since I'm the author of both and their on the same 
branch.

*** Test Case 2: adding a file with the same name and different contents from two working 
copies (which is the case that started this thread off)

I expected to get 2 different files (id and data) as well as two different manifests since 
they contain a different sha1 for one of the files. Again, this is exactly what happened. 
When I do monotone heads I see the different manifest versions listed. Note that I did 
this in the same db after Test Case 1 so the two manifests are descendants of the original 
manifest. If I do a diff between the two manifests I get the correct file difference listed.

I guess what I would expect out of a merge at this point would be to end up handling the 
tree conflict manually since merging the manifest is essentially a file merge... I might 
see the two conflicting sha1 version codes for the file and have to select one or the 
other or neither or both with the additional specification of unique names.

On second thought, maybe I should have to merge the contents of the two files that have 
the same name. It's certainly not a clear cut case, you probably need the option to merge 
the manifest or the file's contents somehow.

*** Test Case 3: adding a file under two different names from two working copies (in a 
clean db)

I expected to end up with one file and two manifests listing the two different names, and 
this is exactly what I got, monotone heads lists the two manifest versions  So now I have 
two manifests, listing the same file (contents) under two different names.

Here I think I would expect a merge to combine the two manifests by simply including the 
file under both names. The merge does succeed, but one of the names is dropped. I do see 
some rename certs in the db but they aren't listed by the log command. Actually, on a 
filesystem that supports it might be sensible to get 2 hard links to the same data, just 
as it is stored in the monotone db. hmm... this is probably pretty questionable though.

*** Test Case 4: add one file under one name in one working copy, and add another file 
under another name in another working copy (probably this is the most normal case).

This works fine if both working copies are up to date with the same manifest but if done 
in a clean database (i.e. with no manifest in it) then it ends up like case 3 above and 
one of the files gets dropped which almost certainly seems bad.

> (Does anyone out there have experience with bitkeeper, and can say how
> they deal with tree layout conflicts, esp. at the UI level?  It's not
> obvious what to do...)

I don't, but it seems that human intervention is definitely required and the UI 
representation is probably rather important. Considering case 2 above, if the manifest 
merge was done using a simple text editor that represented the conflict with cvs style 
markers you might be able to decide which line to keep and which to delete or you might 
just assign unique names to the two files and then fix them later.

I do realize that the manifest merge is probably done completely internally without using 
the external lua merge hooks but maybe using them would help solve the problem.

I have added the RCS merge program (which handles conflicts in the familiar cvs style) to 
my lua merge3 hook and it seems ok except that you get a file committed with conflict 
markers. This would probably be tough for manifests though, considering that their 
contents is rather important compared with regular files.

--
Cheers,
Derek