file copies conception

Robert Collins robertc at
Thu Jan 17 22:11:10 GMT 2008

On Thu, 2008-01-17 at 15:13 -0600, John Arbash Meinel wrote:
> I think the clearest case I saw broke down something like:
> a) Split a file into 2 copies, A => A' B'
> b) Track them as 2 new independent files, which share some common
> history
> c) If you see a change to A (before the split) you should apply it to
> both A' and B'
> d) Changes which would only apply to one side become a simple conflict
> in the other.

This is what I used as the basis for my file copy semantics I proposed
about 6 months back; I have a whiteboard that documents a possible way
to implement this (and its reversible; you get joins at the same time).

> It would be possible to change (d) such that if it applies cleanly to
> one side, ignore a conflict in the other. (But note that there will be
> some changes which apply cleanly to both sides.)

Right; this is arguable on either side; I have no strong position.

> Now, you might run into some difficulties if someone merges a
> cherrypick
> of a change to A' or B', because that *should* be merged into A.

Thats why you need a reversible design; it applies it to A.

> This design doesn't seem terrible to implement, and it seems like it
> would be fairly obvious what is going on. So either it works like the
> person expects, or it fails in obvious ways.
> Also, if person 1 splits into A' and B', and person 2 splits into C'
> and
> D', and makes a change to D', how would that get propagated into A',
> B'?
> I think it is solvable, but we need to think about it.

The change to D' should apply to A by the former rule; A' and B' are
both 'derivatives of A' so will get the patch exactly as if it had been
made to A.


GPG key available at: <>.
-------------- 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 : 

More information about the bazaar mailing list