To make an embarrassing story short:

  1. The merge scenario from the previous post doesn't work the way I said it works in any DVCS it was tried on. I talked about the case of "merging merges" - when two people resolve the same conflict independently in different clones, and then someone pulls from both clones. More specifically, I mentioned the case where the conflict was between two similar patches, and each of the two people took a different patch when resolving the conflict. I claimed BitKeeper would then remove both patches in the final merge. Well, I'm still sure it did work that way for me once (an older version of bk?.. some specifics I didn't notice?..) But bk 4 works differently; it seems to take the later conflict resolution (throwing away one of the patches in my scenario, but not both). Mercurial reportedly takes the earlier resolution, throwing away the other patch. Git and Bazaar reportedly require user intervention, possibly preventing damage by automerges at the cost of, well, requiring user intervention. bk and hg do manage to create a working version in my specific scenario, but of course throwing away one of the conflict resolutions isn't always safe that way, it's only safe in my scenario where both resolutions are basically equivalent. Anyway, while "merging merges" is specific to DVCS, no contemporary one seems to screw you nearly as badly as I described; "most vexing merge", oh, c'mon. Also, it would be easy to guess that they all deal with this scenario differently, because this whole business of merging is heuristical, what are the chances for different heuristics to do the same thing? And in general it's awfully lame to publish stuff first and check it later. I suck.
  2. And the overall excited mood of that article sucked, too, 'cause, like, c'mon, everybody knows that automerges can cut your fingers off, big deal, calm down. I mean, the worst merge-related bugs I dealt with came from automerges that any kind of version control system would allow. Two changes done in different files, that kind of thing. Coding in a "merge-friendly" way is something few people do, and it isn't that easy. For example, you basically must never change semantics of definitions. If your function didn't lock that semaphore, and now it does, then a call added in another branch, which was completely safe, can now cause a deadlock. So what are you going to do, modify the function name each time you change its "observable semantics"? Is everybody really that anal-retentive about it? I doubt that. But we all live with automerges because it's cheaper to deal with their occasional damage than with the constant damage of manual merges, which take lots of time and are intolerably boring, thus very error prone. Which is why I prefer distributed systems and their better ability to merge long-living branches due to detailed recording of change history, even though long-living branches are extremely harmful. Harmful as they are, they will occasionally flourish, and then you need strong automerge, not manual merge, to end their evil lives. But anyway, who cares about the preferences of a person who doesn't even bother to check his own trivially testable claims?



#1 Entity on 07.16.08 at 4:13 pm

Don't mind me if i blow my foot off here, and start a hord of angry programmers on my ass.

I just see programmers for some reason or another just love this stuff, the debate about auto merging or manual merging. The more so the former group about auto merging different branch versions. Where if you ask any average user they don't really care about auto merging, its always assumed to them that if you have two out of date files you have to manual merge the two.

I'm of the former group, I see unless your concurrently working on the same document in real time your going to have manual merge the different branches. Now the next problem is that most programmer don't like have to be modifying the source code real time with another human being because of the obvious you have no idea what state the code is in when you hit compile. So were back at square one, and everyone wants their own snap-shot of the code to work with.

#2 Wayne on 03.31.09 at 4:26 am

BTW current versions of BitKeeper detect this situation properly and highlight to the user the conflicting merge resolutions.

#3 bfish.xaedalus.net » A tech blog recommendation on 04.28.10 at 5:47 pm

[...] an evil of distributed revision control systems (and a retraction, but still worth a [...]

#4 Andreas Krey on 07.10.10 at 11:59 am

Just for the record: The ability to perform merges-of-merges isn't a specific property of DVCSes. The exact same scenario can be tested in centralized VCS (provided they have working merge tracking). It's just that a) the independent merges are far less likely in central VCS because everyone sees the other merge, and b) DVCS have better merge tracking and heuristics, quite apart but not coincidential from being D.

Leave a Comment