9

When it comes to merging, each control version has it's engine to do it. Conflicts are unavoidable but the question is - which revision control has best AI to avoid conflict.

Is it possible to measure such thing?

More specifically, we are thinking to move to GIT cause it has nice hype and rumour that handles conflict better...

Any comment is appreciated...

Improve this question
6
  • 10
    Ultimately, no VCS can handle "close merges" well without doing something other-worldly. If one person adds logic in a routine that goes in one direction, and someone else does something similar -- but entirely different -- humans have to get involved.
    – Peter Rowell
    Commented Jul 29, 2011 at 20:41
  • 1
    In theory merge algorithms could be very good if they actually compiled the source code. Seems kind of out there, but it's probably only a matter of time.
    – Karl Bielefeldt
    Commented Jul 29, 2011 at 21:21
  • 1
    @Karl: eh? compile what source code - if I change a line to say x=1 and my colleague changes the same line to say x=2, how will the compiler figure out which one is 'correct' given the rest of the merged commits.
    – gbjbaanb
    Commented Jul 29, 2011 at 22:23
  • 1
    @gbj, you'll never be able to avoid human intervention entirely, as your example proves. However, compiling the source code could more easily merge things like variable or method renames, or making a change in two functionally identical but textually different ways.
    – Karl Bielefeldt
    Commented Jul 29, 2011 at 22:39
  • Could not testing resolve some of the "human" factor. The humans know what they are trying to produce, so the conflict could be resolved by compiling and running test. Unit tests aught to be at a small enough level that a couple updates to the same method should be feasible in a few passes, if the test is successful both ways humans need to be involved, if the merge system determines there are too many variations that the compile is not tractable humans will need to be involved.
    – Quaternion
    Commented Jul 29, 2011 at 23:05

9 Answers 9

Reset to default
6

It has been said that the best algorithm is Darcs' patch algebra. Codeville also has an interesting algorithm in development.
However, for all practical reasons, any tool which uses three-way merge will do. This includes git (with variants), mercurial, bazaar, and lots of external tools (notable exceptions: opendiff and kaleidoscope on the Mac), so with good probability you are already using the best options; as @Peter noted, there are cases in which no algorithm can help you.

Improve this answer
4
  • 4
    There are subtle differences between 3-way merge algorithms, such as which common ancestor is chosen, and in the quality of the 2-way diffs they use in matching up lines, but you're right that the cases where it makes a practical difference are relatively rare.
    – Karl Bielefeldt
    Commented Jul 29, 2011 at 21:13
  • TMK Mercurial doesn't have a true 3 way merge, you have to do 2 two way merges
    – TheLQ
    Commented Jul 30, 2011 at 18:41
  • @TheLQ the docs say otherwise: mercurial.selenic.com/wiki/MergeProgram but they're a bit skimpy on the details
    – Agos
    Commented Jul 30, 2011 at 20:08
  • @TheLQ - There is a big difference between a three way diff and a three way merge. A three way diff is two files to be merged plus a common ancestor, where the common ancestor allows you to see how the two sources have diverged. A three way merge would need a four way diff, three divergent files plus their common ancestor.
    – Mark Booth
    Commented Aug 2, 2011 at 9:46
21

I don't think this is the right question to ask.

The problem is that there are lots of corner cases, and "smart" algorithms for merging can trick themselves into thinking they've done the merge correctly when in fact they've completely scrozzled your code. If you're lucky, such a bad merge causes a compile-time failure. If you're unlucky, it may introduce a subtle bug that takes ages to track down.

Git uses a fairly straightforward merge algorithm and throws up its hands and asks for help if it can't do the merge. In my opinion, this is exactly what you want your version control system to do. The amount of grief you are spared by this is well worth the time it takes you to manually fix conflicts. (Also, if there are conflicts in a merge, git lists the conflicted files in its auto-generated commit message for you -- this is a very handy thing for finding errors when you are spelunking through your code history.)

Improve this answer
4

I use git and mercurial but your question remember me the patch theory of darcs. You will have reading homework for this weekend.

PD: Don't ask me for the theory of patches, is very complex for me :)

Improve this answer
1
  • interesting stuff, bear in mind that SVN does merging by applying patches, but a full-on patch algorithm that applies both letter r and m to the same word will not give you the right result - you still need human intervention in this case.
    – gbjbaanb
    Commented Jul 29, 2011 at 22:29
2

It called Human Revision Control. (Human Merging Engine)

We use Seapine Surround and for the most part it does a good job of merging, but the only way to fix merge conflicts that the source control cannot do is through human intervention.

So, my advice is:

Try to merge quickly. One nightmare was having a branch that did not rejoin main line for almost 2 years. When it was merged, many conflicts needed to be resolved. One developer earned the nickname "merge master" after spending a great deal of time fixing merge issues.

Be careful with auto generated code from wizards etc. Sometime this can be a real pain to merge, espeically if two branches autogenerated changes on the same file.

Try to control development. If developer A is ripping apart code files X and Y, it doesn't make much sense for developer B to work on X and Y in a different branch. Part of the merge management is to try and control what is being modified to avoid the potential for merge conflicts.

This is not to say that 2 developers can't work on the same file in 2 different branches. If 1 developer adds method A and another addsmethod B, then the merge should happen painlessly.

In the end there are always going to be some conflicts that need human intervention. By keeping those to a minimum you will have the best merge results.

Improve this answer
1
  • 2
    IMHO Auto generated files shouldn't be in version control. Only the files that are used to generate them.
    – Calmarius
    Commented Jun 9, 2014 at 9:00
2

The perfect merge engine would understand the semantics of the file being merged: so it parses and understands the source code. I'm yet to see such merge engine/version control...

Most merge tools merge files as text. So I would never rely on them blindly, it's always good idea to review the changes before committing it to your branch.

We are using Perforce, which doesn't merge automatically. Whenever the source file changes relative to the common base, it will say the target file needs resolve even if there is no conflict. So I open the merge tool just to quickly step thought the hunks to check if they fit (and get a rough picture what other peers are doing), most often they will fit and accept the result.

I also subscribed to the change notifications of the mainline so I merge the changes to my branch as early as possible so I can avoid problems later.

Improve this answer
1

Erm...

When using mercurial (and git as well, I'm reasonably sure) you pick your merge engine, by default it's kdiff3 but you can use anything you like (beyond compare, p4merge etc.).

AFAIK the merge engine and VCS are often completely separate, kind of like your compiler and text editor. Take XML vs code for example, you're going to want different things to merge those, they don't work in the same way and so can't be merged in the same way.

If you're switching version control because you need a better merge tool you're doing it for the wrong reasons, you should only switch version control when the one you're using now doesn't fit your process well (or another one would allow you to use a better process).

Improve this answer
6
  • 1
    Every VCS has a built-in merge algorithm that it uses -- the merge tools you refer to only get used when there are conflicts that the internal engine cannot resolve. The question being asked is, which VCS merge algorithm is the "best", although I'm not sure that's a well-defined question. Some people define it as "produces the fewest conflicts needing resolution"; I'd say, gives the fewest errors.
    – ebneter
    Commented Jul 30, 2011 at 6:47
  • 1
    I'm pretty sure that mercurial actually uses it's diff tools behind the scenes, there's a setting so you can change it somewhere. All the diff tools I mentioned have a 3-way merge mode (not just a diff mode), and p4merge is definitely the tool perforce uses when it detects a collision. I think the VCS itself only has a collision detection algorithm (i.e. have you changed the same file in the same place), which is a precursor to merging.
    – Ed James
    Commented Jul 30, 2011 at 8:05
  • By default, Mercurial uses a simple three-way merge algorithm. However, yes, you can override that. You can override the built-in merge in most VCS tools, for that matter. However, AFAIK, all of them use some internal merge algorithm to look for conflicts, and that is really a key point here -- if your VCS's internal merge algorithm is too clever, it may not find a conflict where it should.
    – ebneter
    Commented Aug 1, 2011 at 20:10
  • In a DVCS I expect that whenever a branch merged then it would run any files that are edited in both branches through the main merge tool. You wouldn't need to look for a merge conflict, just assume there is one, if there isn't then you've not lost anything. I'd imagine the same applies to a standard VCS.
    – Ed James
    Commented Aug 1, 2011 at 20:35
  • What do you mean by "main merge tool?" The default algorithm, or the one you've specified? If you mean the latter, as fair as I know, none of them work that way. Every VCS I'm familiar with uses their internal algorithm to merge and only invokes the user-selected tool if there is a conflict. Note that some VCSs like git do allow you to choose among several built-in strategies, and some VCSs have fairly sophisticated internal algorithms -- but that leads to the problem I described in my answer.
    – ebneter
    Commented Aug 1, 2011 at 23:20
1

Conflicts are unavoidable

How well a VCS handles conflicts within a file is in my mind a bit overrated. For one thing, the best way to deal with such conflicts is to not have them in the first place. Factoring your software well and divvying out assignments with forethought will vastly reduce conflicts within a cluster of files (let alone within a file). Do a bad job such as tossing in one too many god classes, or a common configuration file that everyone has to use and everyone wants to muck with and you are asking for file-level conflicts.

For another, they all use pretty much the same (lousy) algorithm. An example: An alpha release of our project had a minor memory leak. It was more of a drip rather than a leak, and the leak stopped at the end of initialization time. Worthy of a fix, not worthy of a patch. One of our customers "fixed" the problem, putting the free in the wrong place. The problem was fixed in the next release. This customer merged the new release rather than doing a complete replacement (WTF?). There were no conflicts in the three-way merge; the calls to free were well-isolated from one another. So now the software is dropping core due to a double free.

What is being missed in the discussion is how hard / time-consuming / error-prone it is to merge your work back into the main line of the software.

In svn, you

  • Commit the changes to your branch.
  • Merge the trunk into your branch.
  • If you have a big project you might want to think of taking a coffee break or going to lunch.
  • Pray that you won't see any tree conflicts when you come back.
  • Commit the results of the merge into your branch.
  • Merge your branch into the trunk.
  • Take another coffee break.
  • Once again pray that you won't see any tree conflicts when you come back.
  • Commit your changes back into the trunk.
  • Close your door so as to avoid conflicts with your coworker who was trying to do the same thing.

That is far many non-atomic steps, far too many places where errors can creep in (tree conflicts are just nasty), and it takes far too much time. I've seen multiple projects that gave up on using branches with subversion thanks largely to the merge process being so time-consuming and error prone. I've seen even more projects switch from subversion altogether largely because of this.

Improve this answer
1

There's a small test suite called merge-this which compares revision control system against real world merge scenarios. For each scenario, it makes sure a VCS can do the following correctly:

  • merge the branch without conflicts
  • produce code that compiles
  • produce code that behaves correctly

Based on the number of passing tests on merge-this, it appears that there are two tiers of performance:

  1. Darcs, Git
  2. Bazaar, Mercurial

Depending on which programming languages you're trying to merge, the exact test results may matter. See the project's website for a detailed comparison table.

Improve this answer
1
0

I've used IBM/Rational ClearCase and it's multi-branch merging is just awesome. Runs rings around subversion. (No experience of Git or mercurial.)

Improve this answer
1
  • hg's merge is par or better than cc. I've used both.
    – Paul Nathan
    Commented Jul 31, 2011 at 16:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.