How do other distributed teams manage conflict resolution when merging
entire branches back to a trunk when the person(s) doing the merge may not
be the person(s) who originally committed the conflicting check-ins, and in
fact may not be familiar with the section of code where the conflict occurs?
Fortunately, such conflicts are relatively rare, since it's rare to have two
people working on the exact same section of code in two separate branches at
the same time, but it does happen once in a while. And having people check
the same change into both a branch and the trunk to which that branch will
eventually be merged is not only more work, but has sometimes resulted in
Subversion flagging those as conflicting changes.
At work, with a team all in the same room, we just have one of the original
committers resolve the conflict in a shared working copy (the only time we
use shared working copies), and then commit after all the conflicts are
resolved. This doesn't seem like it would work for a team whose members may
not even be on the same continent, which is the case for an open source
project to which I occasionally contribute.
Do you just contact the original committers and ask them what's up? Do you
exclude that change until a later time when it can be resolved? Does the
merger take the time to become familiar with that section of code and fix
it?
Thanks for comments.
Brad
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 30 20:48:03 2007