Re: [Boost-users] What's happened to Ryppl?

Subject: Re: [Boost-users] What's happened to Ryppl?
From: Anthony Williams (anthony.ajw_at_[hidden])
Date: 2011-01-31 17:47:32

Steven Watanabe <watanabesj_at_[hidden]> writes:

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