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

Gerhard Fiedler lists at connectionbrazil.com
Wed Jun 7 00:45:40 BST 2006

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.

Tony Hoyle wrote:

> 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).

Yes, this works if the overall structure is relatively stable, in an
application like cvsnt, with a code base that already is many years old.
But imagine a team of forty developers stomping out a rather complex
application in a year... you can't always not change the interfaces, so
other code does get affected, and you can't always work only with the
stable releases of the other modules. The schedule won't allow that...

All the methodologies that rely on frequent refactoring also require
frequent changes to interfaces. And the time constraints often don't allow
you to wait until all the interfaces you're working with are stable.

What also helps is to lock A for a short time, or tell everybody not to
commit for a short time, merge everything reliably from A to B, and then
copy B over A and commit. After the last merge from A to B there shouldn't
be anything that would require to merge B back to A: the tip of B contains
all changes from B and all changes from A since the root of B. Doing it
this way, there's no need for bidirectional merging.


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook