Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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