6

I've one question about general DVCS, including Git and Hg.

In both Git and Hg merge tracking is done at the "commit" level instead of the "file/directory" level.

One of the "side effects" is that you can't easily do a "partial merge":

  • You've modified 30 files in your branch "feature_branch_x"
  • You want to merge ONLY the files under (let's say) /kernel/gui

With "item based merge tracking" (Perforce, ClearCase, Plastic SCM <= 3.0) you can just select a few files to merge, then checkin, then later repeat the merge and the pending files will show up.

With Hg, Git: once you merge (there're ways to keep files out without being merged) the "tracking" is set and if you repeat the merge no candidates to merge are left.

My question is how do you feel about it??

Are there cases where you feel "partial merge" is mandatory? Can you live without it? (merge with commit/cset level tracking is much faster).

DISCLAIMER: I work for Plastic SCM and we've moved to "cset" level tracking in 4.0, but we're wondering whether it could be a good idea to stay with "item level merge tracking" or even allow both.

mare
  • 13,033
  • 24
  • 102
  • 191
pablo
  • 6,392
  • 4
  • 42
  • 62
  • @bialix, allowing both is a dream, but a nightmare to code. Ok, it is doable, but then on installation you'd have to decide if you'll be using one or the other. What do you think? – pablo Sep 07 '11 at 14:31

5 Answers5

4

My feeling is that wanting to do a partial merge of a branch is a sign that too much was put in one branch in the first place. The correct way to deal with that situation is to split the branch into two branches, thereby correcting the original error, not compounding the error by trying to keep track of a partial merge. I would favor an SCM feature that made splitting a branch easier to do.

Karl Bielefeldt
  • 47,314
  • 10
  • 60
  • 94
  • branch splitting is actually the option we're considering. "Problem" is that it can be "complex" in some scenarios (in many scenarios I'd say). It would be something like "hey, move all my changes under /src/kernel to a new branch and get them out of game_ui branch". My feeling is that "game_ui" will ALSO need the changes, so it is not as easy as "splitting" (unfortunately). Item based merge tracking does all this by default (something git and hg simply can't) and this is how we used to work but we changed the whole thing in 4.0 to get extra merging speed... – pablo Sep 06 '11 at 18:24
  • The "get them out of game_ui" part could be optional. I'm envisioning more creating two new branches without altering the original. That way you have the choice of 3 branches to merge: split 1, split 2, or both, which could be helpful if `game_ui` has already been shared or merged into other branches. If you merge one of the splits, then later merge the combined `game_ui` into the same branch, it will have the same end effect as merging both splits. You can always delete whichever of the 3 branches you no longer need. – Karl Bielefeldt Sep 06 '11 at 18:47
  • @Karl... looks like a good idea indeed... ;) Wonder if we can make it in plastic scm 4.0. We already have a pretty advance merge there (better than 3.0 imho, but scm game is difficult). – pablo Sep 06 '11 at 19:09
  • @pablo Don't sacrifice usability for speed — see my updated answer. – Ondrej Tucny Sep 07 '11 at 21:16
3

This whole-tree merge of mercurial and Git comes from the philosophy of both to track only the state of a whole tree. Neither Mercurial nor Git can store in their metadata that there was a partial merge, since both SCM track the parents of the merge, and the resulting tree. The advantage of this kind of view is that it is much less likely to get the repo in an unstable state by committing half-baked merges.

Think of a situation where files where moved from one subdir into another, and also this paths are coded into a source file. Now when you merge the files in a subdirectory only, the files get correctly moved during the merge, but the references in the source files are still pointing to the old directory. When you now commit this partial merge, you have a defunct state in the VCS. You would need to somehow mark the final merge commit as the completing one (I don't know if Plastic SCM has such a semantic), to prevent others to check out such a work-in-progress state.

Of course it is nasty to merge branches which are diverted over a long time. In the DVCS world this monster-merges are tried to be mitigated to merge early and continuously diverting branches (say one is a feature branch, and a stable one, it is a good idea to often merge stable->feature). Also git has the ability to track merge conflict solutions (called rerere), which helps to mitigate merge pains when you try to do the same merge several times (like when to "practice" the merge before the final finish).

Rudi
  • 19,366
  • 3
  • 55
  • 77
  • Thanks Rudi. While you give me plenty of reasons, I still have people asking for: just merge a few files from a branch. Per-item merge tracking was king here... Telling them they're wrong doesn't really help... ;), specially when they're moving their old code into a new SCM. – pablo Sep 06 '11 at 18:14
2

Pablo, here's a real world case supporting item-level merge: let's have the main M branch a customer branch C. The branch C was forked a while ago, possibly weeks or months ago, and M evolved significantly meanwhile. Now you need to do a hot fix for the customer and hence modify code in C. Also, you need to introduce the change in M.

Our workflow would be to do full, proper fix in M, test M and deliver a new general-purpose release of the product. Then I'd need to merge relevant parts of the fix into C to be able to provide a custom build to the customer affected by the problem. Hence I need to transfer some changes from M into C. Such operation will have the following aspects:

  • some files are merged “as is”,
  • some files are merged manually, but it's very important to know that a merge occured,
  • files merged from M need not be from the latest changeset recorder in M, they may span several changesets.

So, to able to track such operation when inspecting the repository's history, 'data (code) flows' between files shall be recorded on a file-by-file case. The resulting 'merge changeset' would consist of 1:1 automatic merges as well as manually adjusted merges.

UPDATE: Speed vs. usability tradeoff: As I understand your product you bet on features like really good merge. And I bet most users won't care of superspeed — but they do will care of a really good merge.

About a decade ago adding 1000 files into ClearCase took 10 minutes. It took 1 minute to add them into Subversion. That's why we chose Subversion over ClearCase. However, if it took ClearCase 2 minutes we would — most likely — choose ClearCase because of it's then-better features.

If I get good, working features that support real world commercial software development scenarios I won't care whether it will be 50 % faster or slower than my current VCS (Subversion). But, on the other hand, if you provide poor features and/or something that's a usability blocker in comparison to other VCS tools users won't switch.

To conclude on changeset-level vs. item-level merge: stick to freedom — and that's, at least from my point of view, item-level merge.

Ondrej Tucny
  • 27,626
  • 6
  • 70
  • 90
  • wow! Your speed vs usability point of view is really worth keeping in mind. Look, 4.0 merge is not only about speed. Now we're able to deal with stuff that was simply not doable (at least not easily doable before). Sample: * branch1: mv /kernel/render.c /engine/render.c * branch2: mv /kernel/render.c /graphics/renderer.c Now plastic 4 detects it and helps you solving it. It is a nightmare with almost all other SCMs out there. We call it "divergent move" Same is true for "evil twins", "move/delete" and many other conflicts. The new merge also implements "recursive merge" for better resolution – pablo Sep 07 '11 at 22:46
  • What if you'd keep your current algorithm (sounds impressive), but at the end, just before actually merging changes in individual files, apply a user-defined “filer” which indicates what files shall be merged? When selecting the files to be finally included in merge operation you don't have to follow user's will 100%, but also include / exclude files based on what you know about the history of operations in that two branches. In fact the user's will won't be 100% just because of the mere fact they don't remember all operations. – Ondrej Tucny Sep 08 '11 at 06:38
  • Hi Ondrej. Not sure I understand: the thing is: if you merge 3 out of the 5 candidates and decide to checkin (in 4.0 terms, not doable now in the beta), the branch is marked as "merged" and there's no way to merge again. Merge tracking is about not repeating merges, so you need to trust the "marks" you set on the "version graph". So, next time you "try to merge" there's no "easy" way to see if the files were merged or not. – pablo Sep 09 '11 at 10:05
  • 1
    I see… I was missing this point. I would say this is serious problem from my point of view, because what I believe is generally needed is good traceablity of changes (auditing in fact) done in the past. There shall be no “blackbox” functionality whatsoever. – Ondrej Tucny Sep 09 '11 at 11:31
  • every major new dvcs is implementing per-cset merge tracking instead... While I see your point, I'm struggling to find the right solution. – pablo Sep 09 '11 at 16:46
1

from Merge some files now and some later:

consider commits to be made up of sub-commits with changes to only one file each, and then support file-based operations. it's clear that people don't know at branch/commit-time what they will want to merge in the future, and this would solve that. git could be a content AND file tracker.

Community
  • 1
  • 1
user1441998
  • 459
  • 4
  • 14
0

IMHO the SCM that got branch/merge most "right" for this was PRCS, which supported painless partial merges with full per-item history. It allowed you to have things like per-platform branches and merge between them without fear of platform-specific changes "bleeding" into the other branch. The algorithm it used is described here;

http://prcs.sourceforge.net/merge.html

The thing I most miss is on merges where the basis and both branches differed, it would do a three-way-merge per file and the first time it would prompt you for "yours", "theirs", or "merge" and it would remember your response as the default for the next merge.

When I was using it I found branch/merge so painless and intuitive I used them all the time and it never felt complicated. For some reason branch/merge with hg and git have never felt quite so painless.

Donovan Baarda
  • 411
  • 4
  • 5