Need info about merging / conflicts
Preston Landers
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?
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.
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. 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.
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. 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?
thanks,
Preston Landers
Arthur Barrett
> 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?
Get one of the many good books on CVS, eg: Essential CVS.
> At my organization we are looking at adopting a new version control
> system (well, ideally an overall CM / defect tracking / workflow
> system).
I will plug CVS Suite because I work for that company ;)
I personally don't think that unreserved (auto merge) or reserved (lock)
approaches are the starting point of picking a verison control tool to
support your Software Configuration Management process.
When selecting a version control tool I believe the emphasis should be
on whether that tool supports the selected configuration management
process - in turn the CM process should have been selected to address
the management / business issues. I've often seen a manager request an
SCM system to assist with outsourcing to india, then a person selecting
a tool like VSS or PVCS that in no way supports any CM processes related
to outsourced development and multi site development.
Version control is not an end in itself - in fact SCM (software
configuration management) is there to solve particular business problems
like improve productivity, reduce costs, provide compliance with
legislation etc
There was a great article on the valuation of IT assets published in The
Financial Times UK Edition 36,501 on Monday October 1 2007, and I
believe the author will be releasing the complete whitepaper soon.
Basically it talks about the lack of business cases for the benefit of
software and also the business case for maintaining legacy assets. The
cost to a business of re-engineering the CM processes and replacing
version control software are often very high so it's worth knowing for
sure that the business is going to recoup that cost with benefits
provided by the new system (if there really does need to be one).
> 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.
There are very good arguments you can use, but I have a better approach
I use. Our CVS Suite is based on CVSNT not CVS (they both are free/GPL
and run on unix and windows) - CVSNT supports both the 'reserved'
(locking) mode and the 'unreserved' (auto merge) mode of working. I
find it is easier to convince people with the sort of fears you have
described to install CVSNT, and maybe start with 90% of projects and
teams using the 'old' way and just one team using the 'new' way - let
the evidence speak for itself.
The problem with any argument you develop to explain the case for
unreserved working is that you may win the argument but lose the person
- better to win the person and lose the argument. Tell the person 'look
you are probably right', but if we choose a system that lets us do both
then we can experiment a little, and such a system is more likely to
support a greater range of CM processes which means it's less likely to
be out of date in a few years time.
> 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. I was flabbergasted but didn't
> know what to say.
Many commercial products have 'auto merge' (including ClearCase),
however this saleperson is smart. One of the downfalls of open source
tools is that the command line, the server, and the gui and the web
browser, and the bug tracker are all different projects (and almost
always there are several choices for each), and it can be difficult to
put a unified 'glossy' easy to use set together. Again I'll plug what
my employer sells - CVS Suite (which does have a nice shiny diff-editor)
is a collection of open source tools designed to solve this problem for
commercial software developers, plus documentation and support.
Do not forget that there is a very strong commercial argument for using
open source tools rather than proprietary commercial tools. CVS has
been going for 21 years now and shows no sign of its popularity or
effectiveness diminishing -whereas IBM CMVC and many other proprietary
tools have dropped by the wayside. Using free and open source software
means that the software is generally more flexible (if you really really
don't like a feature - you can change or add to it) and have longer
lifetimes (though the project may fork as CVS has done with CVS,
OpenCVS, CVSNT, etc etc).
Regards,
Arthur Barrett
Sergei Organov
> 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.
Pierre Asselin
> Preston Landers <plan...@journyx.com> writes:
> > 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.
Yes, but it is adequate for the routine "sandbox" merges that happen
all the time in concurrent development, when someone else has been
editing the same files as you and beat you to the commit. This is
where Preston's users need an education.
The sandbox merges tend to fall apart across refactorings, in
particular when large code blocks are permuted. However commits
of that type are infrequent. They just need to be planned ahead
of time by the team.
--
pa at panix dot com
Sergei Organov
> Sergei Organov <o...@javad.com> wrote:
>> Preston Landers <plan...@journyx.com> writes:
>
>> > 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.
>
> Yes, but it is adequate for the routine "sandbox" merges that happen
> all the time in concurrent development, when someone else has been
> editing the same files as you and beat you to the commit. This is
> where Preston's users need an education.
That's in fact the easy case with CVS. The hard case is merging to/from
branches that requires manual tagging in order to remember what has been
already merged.
> The sandbox merges tend to fall apart across refactorings, in
> particular when large code blocks are permuted. However commits
> of that type are infrequent. They just need to be planned ahead
> of time by the team.
In addition, merging over renames is really painful with CVS, --
entirely manual and error-prone work :(
--
Sergei.
Preston Landers
> Date: Wed, 5 Dec 2007 15:21:17 -0600
> From: Preston Landers <plan...@journyx.com>
> Subject: Need info about merging / conflicts
> To: info...@nongnu.org
> I've brought up the benefits of working CVS style but I've run into
> considerable resistance, or lack of understanding of the benefits.
Thanks to everyone who replied.
The other developers in my organization are impressed by this product
(SpectrumSCM) and I admit it has some rather intriguing features. We
are currently doing a test evaluation (part time though, it may take
several weeks.)
The apparent lack of automerges still throws me off but we need a lot
of the workflow features this product offers.
They sent me a whitepaper that attempts to show why automerging is
bad. Some interesting parts:
In addition to the set of "safe" merges, and the set of "obviously
unsafe" merges there is an insidious case of "subtly unsafe" merges,
a case where automated programs don't recognize that the very act of
merging is introducing errors not present in either of the branch
files.
This is admittedly rare. In days past, software was often like
playing horseshoes: It was good enough to be close to the
goal. Buggy software was considered unavoidable, and getting a
program that works more often than not was considered a feat. In
such situations, a problem of this rarity was often ignored.
[...]
The problem of Type 2 and Type 3 merges occurs when code lines are
moved from one place in a file to another, or when lines appear
multiple times (e.g. for {i=0,i++,I} ). Then differencing may not
detect changes from one file that will cause semantic problems in
the resulting merged file. A small illustrative example of the kinds
of errors not easily detected by "automatic merge" tools is included
in the appendix to this paper. In actual production such errors
introduced in matching areas can be far larger, and the semantic
interactions more confusing.
BTW, what they are calling type 2 and 3 merges are:
2. Changes in one file only.
3. Changes in non-overlapping sections of both files
> ------------------------------
> Date: Thu, 06 Dec 2007 16:24:22 +0300
> From: Sergei Organov <o...@javad.com>
> Subject: Re: Need info about merging / conflicts
> To: info...@gnu.org
>
> <http://en.wikipedia.org/wiki/Merge_%28revision_control%29>
I did read up on the specifics of 3-way merging and it does seem
pretty straightforward and well understood.
> 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.
Well... I agree with all of that.
> To tell the truth, CVS is not that good at merges,
I can tell you that plain CVS by itself is definitely not a candidate,
and any commercial product built on CVS is unlikely to be a candidate
for us. And from what I understand, subversion is really not a whole
lot better.
> 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.
I (briefly) looked at all of those systems you mentioned and while
they all seem to have interesting features, the major problem for us
is the lack of an integrated issue tracking and workflow system.
> There are plenty of them in open-source world. E.g., the Emacs ediff
> package is really nice for interactive diffing and merging.
That's exactly what I use now. My complaint isn't about having to
manually fix up conflicts, that's a given. I was just wishing for a
branch merge tool that makes me need to use ediff less often.
> IMHO a system that is not capable to perform merges is plain useless.
Hopefully in the next few weeks I'll be able to find out exactly how
capable it is (maybe it's "close enough" to automatic...) and will
report back here.
thanks again for all replies.
Preston Landers