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