info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Need info about merging / conflicts


From: Preston Landers
Subject: Re: Need info about merging / conflicts
Date: Fri, 7 Dec 2007 11:40:46 -0600
User-agent: mutt-ng/devel-r804 (Linux)

address@hidden(address@hidden)@2007.12.06 12:00:03 -0500:

> Date: Wed, 5 Dec 2007 15:21:17 -0600
> From: Preston Landers <address@hidden>
> Subject: Need info about merging / conflicts
> To: address@hidden

> 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 <address@hidden>
> Subject: Re: Need info about merging / conflicts
> To: address@hidden
> 
> <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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]