Steven Watanabe
How do you avoid clobbering each other's incremental merges?
If the merges touch the same files, the second person's commit will fail. This is a good thing because /someone/ has to resolve the conflict. Updating and retrying the commit will work if the tool can handle the merge automatically. (I personally always re-run the tests after updating, to make sure that I've tested what will be the new state of the branch even if there were no merge conflicts.).
Right. This is one area where I get the most value from a DVCS (YMMV). When someone has done conflicting changes, you can commit your changes locally, so they are kept safe as a coherent whole. Only when you try and push to the shared repository do you get merge conflicts. When you've resolved the merge conflicts, you can then commit a new version locally, and push that to the main repo. The final revision history will now show your changes and the merge as separate entries in the log, and if you mess up the merge it's easy to revert back to your private state and try again. With subversion, unless you are working on a private branch, then if someone else makes conflicting changes before you check your code in then you have to merge their changes into your working directory before you can commit. Unless you save your changes first locally (e.g. in a zip file, or a backup directory), then if you mess up the merge you might well lose your local changes too. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976