Re: Merging in CVS

[Eric Siegerman]

On Fri, Nov 22, 2002 at 12:23:56PM -0500, MacMunn, Robert wrote:
> Thanks.  Looks like merges must be difficult in CVS.  A lot of manual work.

Only when both new versions have changed the same area of the
file.  That is, if I edit line 100 and you edit line 120, there
won't be a conflict.  But if we both edit line 110, there will
be.

That's the theory.  In practice, here is a partial list of things
that can cause *lots* of conflicts:
 1. Line-ending differences:  your file has UNIX line endings;
    mine has Windows line endings (as if! :-).  Then CVS will see
    *every* line as different, so the whole file will be one huge
    conflict.

 2. If one (or both) people reformat the code -- run it through a
    code beautifier, change spaces to tabs or vice-versa, go
    through by hand and nicely line up abundant end-of-line
    comments, or whatever.

    Even though those changes don't have any effect on the
    program's behaviour, they're still changes as far as CVS is
    concerned, so they'll conflict with any other change (whether
    significant or also trivial) that another person makes in the
    same region of the file.

 3. If someone wraps a block of code in an "if" statement, say,
    they'll indent it all an extra level.  Again, the indentation
    change is a non-event as far as the compiler's concerned, but
    CVS can't tell that.

 4. CVS keywords, especially $Log$.

 5. Configuration files that need to be customized for each
    instance of the system (different sandboxes, different
    servers, etc.)  All the routine per-instance customizations
    often conflict with substantive changes.

    XML seems to be particularly bad for this, I suspect because
    there's so much redundancy that the merge algorithm can get
    confused more easily than with other file types.

Some of those situations should just be avoided:  (1); $Log$;
possibly other $Xxx$'s, though $Id$ can be useful enough to be
worth putting up with the resulting merge conflicts.

Others -- (2) and especially (3) -- are sometimes necessary, so
the trick is to do them in such a way as to minimize the pain.
If you know you're going to be making massive, trivial changes,
like beautifying the whole project, get other people to commit
their changes and go to lunch.  Then you update, do your thing,
and commit.  That way they won't have done any work, so there
won't be any conflicts.  Things like changing the indentation on
a large block of code are harder to schedule -- you do it based
on need, not on "would be an improvement" -- so the resulting
conflicts just kind have to be lived with.

(5) can be greatly improved by going to a template-based
approach.  For the project I'm currently on, I whipped something
up in Perl to do autoconf-like macro substitutions on the XML
config files.  If all the per-instance customizations -- host
names, port numbers, etc. -- are done by that Perl script, and
only the uncustomized templates are stored in CVS, the many
pointless conflicts will go away, and the only remaining
conflicts will be between groups of *substantive* changes.

A special case of (2) is files that are written with the aid of
smart tools -- XML editors, IDE's, and the like.  Then you don't
necessarily have control over the precise formatting; the tool
might change things in ways you didn't expect.  Similarly filled
text -- add a word, and the rest of the paragraph might get
reflowed.  Not much that can be done about those cases, unless
you (and your colleagues) are willing to forego the spiffy
tools...

In summary, merge conflicts are indeed a problem.  Worse in some
situations than in others, but usually manageable, by which I
mean, reducible to the level of annoyance rather than major
productivity drain.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Just Say No to the "faceless cannonfodder" stereotype.
        - http://www.ainurin.net/ (an Orc site)