[cvsnt] Re: Branch merging - this seems wrong...

[Tony Hoyle]

Gerhard Fiedler wrote:
> What might work is to use the change set of branch B /minus/ the change set
> from A1 to A4 -- that is, having a merge command option to tell cvsnt that
> all changes on A between the start of B and the tip of A should already be
> incorporated in B and that it should only consider the /other/ changes on
> B. (That would be a command for supporting specifically a scenario like
> option 4.) I'm not sure how realistic it would be to expect such an
> algorithm to work.

It can't work in any reliable sense - often to merge you resolve conflicts by 
taking bits of A and bits of B and creating a composite... there's no way for 
the server to know which bits you have taken.

For a mergepoint it doesn't care - it just knows that at that point A was 
merged with B so you have told it the branches are equivalent at that point... 
whether they really are or how they got there isn't the concern of the server.

Once you start trying to pick that apart to go in the other direction it all 
falls apart - you don't have enough information to know what was merged and 
how.. it's not a reversible process, so you have to start from the beginning 
and try to sort it out.

Some of the time this will work by accident (the changes are minimal, and all 
the deltas from B match existing lines in A).  In the worst cases you 
basically have to go back to the start and do line by line comparisons.

It's turning into a debate about style rather than whether bidirectional 
mergepoints are possible... I prefer to avoid such stuff (that's Arthurs' 
territory).

In your interdependent modules case I would have each team only using the 
stable branches of the other teams so their development doesn't overlap - you 
maintain strict promotion but nothing breaks.

For example if Arthur is working on his SCCI plugin I don't see it - I only 
ever checkout his stable releases as I'm not working on it.  He doesn't need 
to create artifical branches... he can work away without affecting me and just 
promote releases to test as required (in fact he checks in executables from 
time to time so I don't even need the source... I just rebuild as a matter of 
habit).

2.6 or 3.0 will have the concept of commit/publish as separate steps to make 
this even clearer - basically you can work on code, commit it and nobody sees 
your changes until you publish it (there's an implicit reserved edit in there 
too so that nobody can stomp on each others work - in a normal team situation 
that won't happen of course as everyone is working on different code).

Tony

* Nobody ever saw that code... don't worry about it :p