Semantics for file copy

[Robert Collins]

On Wed, 2008-08-20 at 20:45 +0200, Martin von Gagern wrote:
> Hi!
> 
> I read http://bazaar-vcs.org/BzrFileCopies and the question therein.

I don't know how relevant that page is these days, we've had much more
discussion on list.


> For the content:
> 
> I think I would agree with the attempted answer by PierreAntoineChampin 
> that all changes applied to a common ancestor in one tree should be 
> applied to all files derived from that ancestor in another tree upon 
> merge. So both files should be in conflict, one containing a and c and 
> the other b and c.

Sure.

> More formally: for every pair a and b of files with a common ancestor c, 
> after the merge a should contain all changes applied to b since c, and b 
> should contain all changes applied to a since then. This sounds a lot 
> like a normal content merge, but due to the fact that here every file 
> can be part of more than one pair, this means changes from possibly more 
> than one line of modifications even during a single merge.

We have much more sophisticated merging than simple three-way; I think
the key point is that changes made to a file after the point it was
copied should not apply to the files copied from it.

> To handle this case more intelligently, any modification to the common 
> ancestor should be considered independently. If it can be applied 
> cleanly to one copy, and you know the surrounding block (say at least 
> two lines to either side) have been completely removed from the other 
> copy, then the modification should be dropped from the second copy 
> without causing a conflict.

There are arguments for and against this; I'm inclined to be
conservative.

> For the file names:
> 
> I would say that the resulting tree should contain the files c and b, 
> and report a path conflict for b / c.

I disagree, the mv a->b has no reason to conflict, and the copy to c
likewise.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080822/1f0091ea/attachment.pgp