Re: Need info about merging / conflicts

[Sergei Organov]

Preston Landers <address@hidden> writes:
> Does anyone know a good resource for information about how CVS (or any
> version control system for that matter) handles merging and
> identifying merge conficts?

<http://en.wikipedia.org/wiki/Merge_%28revision_control%29>

> At my organization we are looking at adopting a new version control
> system (well, ideally an overall CM / defect tracking / workflow
> system).  Most of the developers here are used to working only with a
> system (CMVC) that requires exclusive locks on file checkouts, and
> requires manually merging in all changes from side branches.

Been there.... Never again, please ;)

> I've brought up the benefits of working CVS style but I've run into
> considerable resistance, or lack of understanding of the benefits.
> I've been told that it's "stupid" to think that software can possibly
> safely merge code changes and safely identify conflicts, that it is
> "brittle", language dependent, somehow causes problems with
> compliation, etc, etc.

What people that didn't work with systems that do "automatic" merges
usually miss is the fact that the result of "automatic" merge is just a
modified source tree, even when there are no conflicts. It's up to human
to check that the result of the merge is sane and satisfactory (i.e.,
compiles, works as expected, etc.). At this point you can easily see
diff between merged source tree and the tree you've started the merge
from, and perform tweaks to the result, if required. Only after that the
modifications, the (tweaked) result of merge, should be committed.

I.e., the tool only does those hard part of work that could be easily
done automatically, and leaves the smart part to be resolved by
humans. What is very essential is that those "automatic" part ensures
that there will be no changes missed, -- that's where humans are really
weak.

> I'm poorly equipped to counter these arguments at the moment because I
> have so little understanding of the topic myself.  I just know from
> experience at a previous CVS-using organization that in CVS it is
> infinitely easier to deal with concurrent access and merging changes.

To tell the truth, CVS is not that good at merges, -- it requires quite
a lot of manual housekeeping to do merges right. Maybe CVSNT or SVN is
better on merges than CVS, -- I don't actually know. If you have no CVS
expert(s) available and do not yet use CVS, I'd consider to use
something else, probably even one of distributed VCSes, such as Bazaar,
Git, or Mercurial.

> BTW, when I asked one vendor why his product didn't support
> auto-merging, he suggested open source projects like CVS only use
> auto-merging because they're too poor to afford a nice, shiny
> Diff-Editor like this product had.

There are plenty of them in open-source world. E.g., the Emacs ediff
package is really nice for interactive diffing and merging.

> I was flabbergasted but didn't know what to say.  I'm pretty sure
> there are commercial products (Bitkeeper, Perforce?) which auto-merge
> because it makes sense and is easier... am I right?

IMHO a system that is not capable to perform merges is plain useless. I
happened to use PVCS one time in the past, -- it was a real pain. BTW,
if you want a feature comparison of different open-source and commercial
VCSes, visit, e.g.:

<http://en.wikipedia.org/wiki/Comparison_of_revision_control_software>

-- 
Sergei.