views:

101

answers:

2

Seems like in SVN, when you do a merge, there won't be a revision checked in by you. All your "commits" should only have code that is changed by you.

But in Mercurial, that's not the case. Your "merge" commits are committed by you, but they usually contain changes that are made by other people. And if that commit triggered an error in the automated test, then it may be the "merge" that broke the code base, meaning that the other changes didn't work with yours or vice versa? (but the other changes may not have revealed the error because (1) it may not have gone that far in the test. (2) the test are batched together -- and if test 102 took 1 hour to run and there are 3 pushes within that hour, then only the last pushed version is tested)

Is this the behavior the same as Git as well?

So you really have to look at the test itself to see what is causing it and fix it... but who should look at it -- you or your team member?

initial encounter of this behavior feels kind of weird...

+3  A: 

The merge will be committed by whoever does it. But you can bisect the tree and then blame the person that caused the issue. Also if you have idea's of a couple of people who are responsible you should tell them to look at it. If you wrote your tests right they should be giving you some idea of what is wrong where. If their features can't be resolved to both work then you'll have to be diplomatic and make some decisions.

xenoterracide
A: 
Jakub Narębski
maybe you haven't used SVN or CVS before? I think in those system, a merge is not a separate commit.
動靜能量
In those version control systems (CVS and Subversion prior to version 1.5) merge was a separate revision, but it didn't remember that it was a merge, i.e. that it came from merging two lines of development (e.g. `cvs update -j ... -j ...` creates a commit, IIRC).
Jakub Narębski