28

Possible Duplicate:
I’m a Subversion geek, why should I consider or not consider Mercurial or Git or any other DVCS?

Every once in a while, you hear someone saying that distributed version control (Git, HG) is inherently better than centralized version control (like SVN) because merging is difficult and painful in SVN. The thing is, I've never had any trouble with merging in SVN, and since you only ever hear that claim being made by DVCS advocates, and not by actual SVN users, it tends to remind me of those obnoxious commercials on TV where they try to sell you something you don't need by having bumbling actors pretend that the thing you already have and works just fine is incredibly difficult to use.

And the use case that's invariably brought up is re-merging a branch, which again reminds me of those strawman product advertisements; if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place. (Of course it's difficult to do when you're doing something fundamentally wrong and silly!)

So, discounting the ridiculous strawman use case, what is there in SVN merging that is inherently more difficult than merging in a DVCS system?

Community
  • 1
Mason Wheeler
  • 82,151
  • 24
  • 234
  • 309
  • 6
    I am yet to work in an environment where they have months long branches being merged and they use distributed version control. The only places I have worked at that do such long lived branches used TFS/Subversion. I expect that such long lived branches would be difficult to merge with DVCSes too. – Oded Oct 26 '12 at 19:23
  • What do you mean by "if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place"? Why would you not remerge a branch back into trunk? – David Peterman Oct 26 '12 at 19:30
  • @David: Why *would* you remerge a branch back into the trunk? Have you ever seen a tree (as in real-life thing that grows in the ground) where a branch grows back into its trunk? You start doing that, you break the branching metaphor completely, and the complexity goes through the roof. You ever work with a DVCS project that does that a lot? I have, and you practically need a degree in graph theory to make sense of the project history! – Mason Wheeler Oct 26 '12 at 19:32
  • 2
    so trunk is just a "starting point"? i'm all for thinking about things from a different perspective, but never merging back into the heart of your development seems inherently wrong to me – David Peterman Oct 26 '12 at 19:35
  • 14
    @MasonWheeler I'm puzzled. What do you use a VCS for, then? I've seen and read that one (of the many) recommended practices is to have feature branches. Merging back to trunk is mandatory in that case. Or did I misunderstand something? (yes, the tree metaphor breaks, but it wasn't all that useful to begin with IMO) – Andres F. Oct 26 '12 at 19:36
  • 2
    @Andres: Not sure where you read that, but I always understood branches to be for versioning. As in, "this is the 3.0 branch, this is the 3.1 branch, this is the 4.0 branch, and Trunk is current development, which is currently 4.1. When we begin working on 4.2, it will become Trunk and we'll move 4.1 off into a branch." – Mason Wheeler Oct 26 '12 at 19:42
  • 10
    @MasonWheeler: I think you're taking the tree analogy a bit too literally. – whatsisname Oct 26 '12 at 19:43
  • @MasonWheeler at some point, 3.0, or whatever, needs to become the current development – David Peterman Oct 26 '12 at 19:48
  • @MasonWheeler [A Successful Git Branching Model](http://nvie.com/posts/a-successful-git-branching-model/). Where I work we do something similar. We even use feature branches on SVN. This implies that merging back to trunk is a very common operation. – Andres F. Oct 26 '12 at 19:50
  • @David: Then you check out the 3.0 branch (either into a clean VM or with the SVN Switch command) and work on it. I don't see what you're getting at, why this is supposed to be something problematic. – Mason Wheeler Oct 26 '12 at 19:53
  • 6
    Related: [Is there a difference between merges in svn compared to git or mercurial?](http://programmers.stackexchange.com/questions/129890/is-there-a-difference-between-merges-in-svn-compared-to-git-or-mercurial?rq=1), [How and/or why is merging in Git better than in SVN?](http://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn), [Really, a concrete example that merging in git is easier than svn?](http://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn), – yannis Oct 26 '12 at 19:54
  • @MasonWheeler I was under the impression that versions are supposed to be marked with tags rather than a new branch. – axblount Oct 26 '12 at 19:56
  • (cont...) [I'm a Subversion geek, why should I consider or not consider Mercurial or Git or any other DVCS?](http://programmers.stackexchange.com/questions/87133/were-subversion-geeks-and-we-want-to-know-the-benefits-of-mercurial?rq=1), [We're Subversion Geeks and we want to know the benefits of Mercurial](http://programmers.stackexchange.com/questions/87133/were-subversion-geeks-and-we-want-to-know-the-benefits-of-mercurial?rq=1) – yannis Oct 26 '12 at 19:56
  • @Axblount: AFAIK in SVN, tags and branches are the same thing. – Mason Wheeler Oct 26 '12 at 19:59
  • 1
    @MasonWheeler, you do realize that some of us have to support multiple versions in the field at once? Rather than fix the bug separately in all the branches and the trunk, we fix in a branch and merge. – Charles E. Grant Oct 26 '12 at 20:00
  • 8
    @MasonWheeler how many different development environments do you have experience of, if you've never heard of merging back to trunk? Some shops have stable trunk and experimental branches, in which case cherry picking successful featurs back to stable is a regular event. – itsbruce Oct 26 '12 at 20:01
  • 1
    @Charles: Yes, I do that too. I currently have 12 VMs for different versions (branches) of the project I'm part of at work. When I have to fix a bug in an older version, I fix the bug, then merge *that commit* into the branches for newer versions. But that's now re-merging an entire branch, which is what I'm talking about here. – Mason Wheeler Oct 26 '12 at 20:05
  • 1
    @itsbruce: I didn't say I'd never heard of it, I said it's doing it wrong, partially based on personal experience with projects that *do* do it that way and seeing how much extra, unnecessary complexity it adds. – Mason Wheeler Oct 26 '12 at 20:06
  • 4
    I've never used Git, but I was under the impression that merging is better because of a better auto-merge algorithm, not because of anything inherent in distributed source control. – ConditionRacer Oct 26 '12 at 20:07
  • Also see: http://stackoverflow.com/q/1410722/109941 – Jim G. Oct 26 '12 at 20:42
  • 2
    Based solely on the question and a few comments, there's nothing difficult about merging with SVN... if you never merge. – David Peterman Oct 26 '12 at 20:26

6 Answers6

48

if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place. (Of course it's difficult to do when you're doing something fundamentally wrong and silly!)

And therein lies the source of your confusion and the whole problem in general.

You say that merging branches is "fundamentally wrong and silly". Well, that's exactly the problem: you're thinking of branches as things that shouldn't be merged. Why? Because you're an SVN user who knows that merging branches is hard. Therefore, you never do it, and you encourage others to not do it. You have been trained to avoid merging; you've developed techniques that you use to avoid merging.

I'm a Mercurial user. Even on my own projects, where I'm the only developer, I merge branches all the time. I have a release branch, which I put a fix into. Well, I merge that back into the main-line so that the fix goes there.

If I were using SVN, I would adopt a completely different structure of the codebase. Why? Because SVN makes merges hard, and therefore you develop idioms and techniques to avoid doing complex merges.

DVCS's make complex merges easy because they are the default state. Everything is a branch, more or less, in a DVCS. So the entire structure of them is built from the ground up to make merging easier. This allows you to develop a workflow that uses merging on a daily basis, rather than the SVN workflow where you never use merging.

The simple fact is this: you should approach a DVCS in a different way than SVN. You should use the proper idioms for these very different kinds of version control systems. In SVN, you adopt idioms that don't involve merging because merges are hard. In DVCS's, you adopt idioms that frequently use merges because they're no big deal.

Right tool for the right job.

The thing is, the merge-focused workflow is a lot nicer and easier to use than the SVN-style workflow where you don't merge things. It's easier to see when something from the release branch was brought into the dev branch. It's easier to see the various interplay between branches. It's easy to create test branches for things, then clip them off if the test doesn't work. And so on.

Really, Joel explains this a lot better than I can. You should have a good read of that.

Yay295
  • 107
  • 1
  • 3
Nicol Bolas
  • 11,813
  • 4
  • 37
  • 46
  • 2
    On the contrary, I've never been "trained to" avoid merging branches. It's just something that honestly never occurred to me in the first place until I started hearing DVCS people talk about it, and my immediate reaction was (and still is) "what, are you crazy or something?" – Mason Wheeler Oct 26 '12 at 20:51
  • 15
    @Mason: How is that not training? You were trained to use SVN in an SVN style. And the SVN style is to *not* use merging. Thus, you were trained to not use or even *consider* merging things. That's why it never occurred to you; because you used a system that makes it difficult. – Nicol Bolas Oct 26 '12 at 20:53
  • 5
    There's a big difference between "not trained to" and "trained not to." – Mason Wheeler Oct 26 '12 at 20:53
  • 1
    And I've read Joel's article. It covers the same tired old ground of assuming the concept of merging branches, which still doesn't make any sense. – Mason Wheeler Oct 26 '12 at 20:54
  • 8
    @MasonWheeler: No, there isn't. If you are not properly taught how to do something, then you are implicitly trained to not do it. It isn't in your repertoire of idioms you can employ to solve a problem. Therefore, you *cannot* use it to solve problems. The effect is no different from being told not to merge, because even if you wanted to, you don't know how. The way you offhandedly dismiss a good argument as "the same tired old ground" is evidence of this. You don't think of merging as a tool; you think of it as the exception or something unusual. Something to be *questioned* rather than used. – Nicol Bolas Oct 26 '12 at 20:56
  • 2
    I never said that merging is something to be questioned. Merging is very useful, when used properly. What I said is that *re-merging an entire branch* is doing it wrong, and if people have trouble with that, it's not SVN's fault; it's because *they're doing it wrong*. (And what exactly is wrong with "questioning rather than using" anyway? The way you say that, almost make it sound like you think anyone who disagrees should just shut up and drink the Kool-Aid.) – Mason Wheeler Oct 26 '12 at 21:08
  • 10
    @MasonWheeler: Who are you to decide "*they're doing it wrong*"? You don't use DVCSs, so you have no experience with the DVCS workflow. You have no idea whether it is helpful to programmers or not, as you have no experience with it. So what authority do you have to say that it's "wrong" just because SVN doesn't allow it? It's like saying that classes, virtual functions, and templates are wrong because C doesn't have them. – Nicol Bolas Oct 26 '12 at 21:13
  • 1
    Again, you're making incorrect assumptions. I *do* use DVCSs, and I have plenty of experience with the workflow. (Which I clearly stated in the question!) I use SVN at work, but I've contributed a handful of useful features to open-source projects that run on HG, so I'm well aware of the system, of how it works, and of the unnecessary headaches and added complexity that this workflow introduces. – Mason Wheeler Oct 26 '12 at 21:16
  • 2
    @MasonWheeler: It clearly doesn't induce headaches in many others though. You haven't actually provided any rationale for why "*they're doing it wrong*". Simply stating that doesn't make it true. I can't think of a reason why re-merging branches is *generally* wrong, though I can think of cases where it would get annoying, as well as cases where it'd be very useful, and not at all problematic. – naught101 Jan 06 '15 at 00:11
  • 1
    @naught101: It turns your history from a tree (simple) into a graph (complicated) and makes history harder to understand. Also, it completely breaks the "branching" metaphor. Have you ever seen a tree (real-life plant made of wood) where a branch splits off and then rejoins later on? I know I haven't! – Mason Wheeler Jan 06 '15 at 01:33
  • 3
    @MasonWheeler: [like this? :P](https://upload.wikimedia.org/wikipedia/commons/b/b8/Neadle.jpg). SVN branching and merging does the same thing - the metaphor is already broken. I don't really see how [something like this](http://kentnguyen.com/wp-content/uploads/2012/01/git_merge_often.png) is that hard to understand, especially if it includes some sensible commit comments.. – naught101 Jan 06 '15 at 01:49
  • 2
    I reckon Joel Spolsky article has it right. SVN causes brain damage. This is not a poke at you Mason, just me admitting that I was brain damaged for a very long time. I avoided git like the plague because it looked hard. I didn't understand it. Then I started using git and I was confused as hell. I wanted to go back to SVN. When using git, you'll eventually get that "aha" moment and understand why in general it is so much better. Unicorns will frollock in your garden and rainbows will color your sky. All will be good. My advice is to give git a good solid effort. It will be worth it I promise. – n4rzul Feb 08 '16 at 09:19
  • @MasonWheeler It looks like the arguer here was only interested in shutting you up. I'm interested in hearing how your merging works. For instance, if you have two branches, one for ongoing development, and one for production, how do you get code from one to the other without regularly merging one branch to the other? Or perhaps that two-branch paradigm is already missing what you are thinking? – lmat - Reinstate Monica Apr 21 '16 at 19:18
  • @LimitedAtonement You get code from one to the other by merging *commits* from one branch to the other. This is a pretty common workflow when working on a commercial project that has multiple active versions: you check a fix in to v1, then merge that commit forward: from v1 into v2, and then from v2 to v3. That's completely different from merging one branch into another. – Mason Wheeler Apr 21 '16 at 19:23
  • 3
    @MasonWheeler But imagine another situation: in the development branch, I implement a larger feature, say, we new accept Paypal. That might be 45 commits? But not all together, there are bug fixes and other enhancements in there that have already made it to production. Should I go back and find all the paypal commits and merge them into the released code one by one? – lmat - Reinstate Monica Apr 22 '16 at 01:10
25

It's because svn lacked the proper data structures to accurately determine the latest common ancestor of the two branches. That's not a big deal for a branch that is only merged once, but can cause a lot of erroneous merge conflicts in situations where several branches are merged multiple times.

I don't follow svn very closely, but my understanding is those particular technical issues have been fixed in recent versions. However, it wasn't fixed early enough to dispel the myth, and people who tried DVCS for the merges have stuck with it for other reasons.

Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
23

There is nothing too difficult about SVN merging... anymore... if you follow the right philosophy

What I see in most other answers seems to come from people who haven't used SVN in a while. As someone accurately mentions: "it wasn't fixed early enough to dispel the myth".

From my current experience of using SVN 1.6 to 1.8 on a legacy project I inherited recently, SVN has gone a long way towards making merging a much easier thing. It is not foolproof, though, and I think it does not easily suffer users deviating from the intended use.

While I knew SVN quite well and had also tried Mercurial for personal projects in the meantime, I had never done a lot of branching in SVN prior to this project. There was quite a bit of trial and error and I got a lot of unexpected merge conflicts when I started.

Ultimately, though, I realized that everytime I got one (or some other issue), it was because I hadn't done things properly (aka "the SVN way" -- arguably, the proper version control way). I believe this is where the difficulty lies: you cannot do whatever you want in an unorganized way and expect SVN to work perfectly, especially with merges. Merges require rigorous discipline from the user(s) before they show their true power.

Here are things I've noticed are strong recommendations, if not requirements, for a clean use of merges:

  • Use a recent version of SVN (1.6 and up in my opinion). More and more automation and checks are done for you.
  • Use the default "trunk, branches, tags" structure and apply its philosophy (don't commit to tags). SVN won't check anything for you. If you use a tag as a branch (that's the state I found that project repository in), it can still work, but you need to be consistent.
  • Know what branches are and when to create them. Same with tags.
  • Keep side branches up-to-date with their source branch (usually trunk, but you can branch out from any branch technically). This is mandatory IF you want SVN to do auto-merges. SVN 1.8 actually prevents you from auto-merging if things are not up-to-date, and also if you have pending modifications in your working copy (this behavior seems to have disappeared again in 1.8.5).
  • Do "proper" commits. They should only contain modifications on a very specific concept. As much as possible, they should contain a small amount of change. You do not want to have a single commit contain modifications about two independant bugs for example. If you have already fixed both and they're in the same file, you should store away the changes of one bug so you can commit just the changes of the other first, then commit the second set of changes. Note that TortoiseSVN allows this easily through "Restore after commit".
    • Doing so makes it possible to revert a specific independant set of changes AND makes it possible to only merge such a set into another branch. Yes, SVN allows you to merge cherry-picked revisions.
  • If you ever use sub-branches (branching off trunk, then branching off that new branch), respect the hierarchy. If you update the sub-branch with the trunk or vice versa, you're in for some pain. Merges should be cascaded down or up the hierarchy.
    • After a few months of experimenting, I can vouch that this might be the most important part. Tried creating two sub-branches from the same trunk and then merging bits between the sub-branches, or sometimes between sub-sub-branches from either side. This can trip up SVN (or the user). It can work OK if you're merging specific revisions. Auto-merge may have trouble with it.
    • I have had trouble specifically when synchronizing sub-branch A with trunk, and then trying to merge something from sub-branch A into sub-branch B. SVN seems to think the "synchronize from trunk" revision should legitimately be merged into sub-branch B and this leads to a mass of conflicts.
  • As much as possible, merge from the root of the branch. Otherwise, SVN will only keep track of the merges done for the sub-folder and when you do try to auto-merge from the root, you may get warnings about missing unmerged revisions. It's fixable by simply merging these from the root, but best avoid the confusion.
  • Be careful which branch you commit to. If you use Switch to have your working copy point to various branches through time, be sure where you're committing to.
    • It's especially bad if you really didn't want the change in that branch. I'm still not clear on that one, but depending on how you get rid of it / transfer it into the right branch (reverting, merging), you can get something messy. It's fixable, but you'll either have to merge revision by revision to avoid or immediately solve potential conflicts, or you'll have to fix a possibly more complex conflict after the auto-merge.
  • Do not keep branches untouched for too long. Actually, it's not a matter of time but of how many revisions were committed to the branch and the trunk and how much changed in these. Merges between two branches, 3-way merges, always get compared to most recent common revision between the branches. The more changes in-between, the more change the automatic merging will fail. This is, of course, much worse if you changed the structure of your code in the meantime (moved or renamed files).

If you don't follow the above, you're quite likely to get conflicts. They're always solvable, but not terribly fun to spend time on.

Oh, one more thing about merging where, from all I've read and tried, SVN really sucks: deleted/moved/renamed files/folders. Apparently, SVN still cannot deal with a file being renamed, deleted or moved in one branch, and its original version modified in another branch... and then merging these together. It just won't know where the file went in one way, and will "forget" the changes in the other way. One change is obviously unsolvable (you either delete or change the file, can't do both), but applying changes to moved/renamed files should work and it doesn't. Hopefully this gets fixed soon.

So, all in all, is SVN merging easy? I guess not. Not in a carefree way, for sure. Is it bad? I don't think so. It only spits back in your face when you use it the wrong way and don't think enough about what you're doing.

Based on this, I can see why people might prefer Mercurial (for example) as it's a little more lenient about these things from my experience and had everything automated from the get-go (at least from the early versions I started with). SVN has caught up quite a bit, though, so it's not worthy of so much bashing anymore.

leokhorn
  • 614
  • 5
  • 12
  • Tree conflicts - yes, SVN has difficulty with these, though TBH so do every other SCM. Git has some heuristics to try and figure out if files that have been renamed or moved are the same, but it doesn't (cannot!) always get it right. I think SVN should put some effort into making resolving these conflicts easier to understand. – gbjbaanb Jul 20 '14 at 18:22
  • @gbjbaanb: It does offer "Repair Move" as Mercurial does, though it doesn't offer heuristics. You need to tell it which Deleted and Added files are, in fact, the same. Definitely room for improvement. – leokhorn Jul 21 '14 at 08:22
  • All of this sounds great when you are the only person working on the project ... But if you have a good sized team and they are all using it the "SVN way" (which nobody seems to agree on exactly what that is) merges are still a PITA. The fact is svn doesn't really support the branching workflow that well. The "SVN way" would be to not even create branches and use a waterfall SDLC. All that being said, I've had issues with Git merges in the past on large projects with several people people working on it. But, they seemed to still be a lot less painful. – ryoung Aug 27 '15 at 14:43
  • My experience is that if you are working with people who don't care about how the version control system works, SVN is way easier to use on a day to day basis. I've worked only on a few DVCS teams but invariably some substantial number of the team do not have good revision control behavior and it pollutes the repository for everyone. In Subversion, the untrained generally stay away from branches so they get the "experts" to do it for them and they are managed appropriately. Granted, this experience is mine alone and I'd prefer to only work with programmers who knew how their tools worked... – dash-tom-bang Jun 13 '18 at 01:55
5

The internal data models are fundamentally different.

Fundamentally, in SVN, when you look at the history of a branch, you only see what has happened in that branch. So when you merge from branch B to branch A, the history of branch A will contain one large commit containing all the changes made explicitly to B since it was branched.

In the first versions of SVN, if you had to merge branch B into branch A once more, you had to manually specify which revision range of branch B you wanted to merge in order to avoid merging the same revisions twice. The clever developer would of course use a commit message like 'Merged in B:1234'.

SVN 1.5 "fixed" this. But it did not change how merges are applied fundamentally. It merely added some extra metadata to branch A, letting SVN know that revision 1234 had been merged in, allowing SVN to automatically choose the correct revision range.

But this solution is basically a workaround for a data model that fundamentally doesn't support track what has been merged.

Merging two branches is a relatively simple example. But imaging this more complex scenario

  1. Create branch A from trunk, and make a few commits here
  2. Create branch B from A and make a few commits here
  3. Make a few commits in trunk and A
  4. Merge B into trunk
  5. Merge A into B
  6. Merge A into trunk
  7. Merge B into trunk (this shouldn't actually do anything)

Handling this correctly using the metadata model becomes extremely complex (I don't know if SVN does indeed handle this scenario correctly, and I don't feel inclined to test it out).

Handling this scenario in git is extremely simple.

In git, every time you commit, the internal object representing that commit contains a reference to the previous head. When you merge in a branch, the commit contains references to the previous head of all the branches being merged (you can merge more than one branch at a time in git)

Therefore, when you examine the history of a single commit in git, you can see all history, you can see when it was branched, when it was merged, and you can see the history of both branches between the branching and the merging.

Thus when merging in a branch that has been partly merged, it is extremely simple to determine what has been merged already, and what has not.

I have no experience with Mercurial, but I suspect that its internal workings are similar to git.

So fundamentally, for SVN, it was a design goal to make branching cheap. But in git, it was a design goal to make merging cheap.

Lastly, last time I used SVN, it was not able to handle merges, where a file was renamed in one branch, and modified in another.

Pete
  • 8,916
  • 3
  • 41
  • 53
1

I've done a fair bit of SVN merging -- including having long running development and release branches. By and large I survived. Merging is always tricky, but with DCVS the downside is not horribly bad -- everything is local so just update to a known good revision and keep going. Whereas with SVN alot happened on the server side so recovery was ugly -- usually it involved wiping out the local copy then checking out a new clean branch to try it again. Wasn't bad in my case -- a gigabit connection to the SVN box helps. But we had some contractors who had lots of trouble with this as they were on slow connections so anything took forever, including merges.

Wyatt Barnett
  • 20,685
  • 50
  • 69
  • extrapolating on the slow connection thing, working from an offsite remote server makes for lousy dropped connection errors too when making large updates >< Not fun at all. – jxramos Nov 17 '15 at 22:51
-1

Yes, I do that too. I currently have 12 VMs for different versions (branches) of the project I'm part of at work. When I have to fix a bug in an older version, I fix the bug, then merge that commit into the branches for newer versions. But that's now re-merging an entire branch, which is what I'm talking about here.

Here lies one of the very nice things about git. It's not inherit about DVCS, it's just something git excels at. You can merge specific revisions from any branch into another branch. It basically just takes the diff and applies it to the other branch, but does tracking and is much more automatic.

So, if you have branch 2.0 and branch 3.0 and discover a bug in 2.0, you can then fix it in 2.0 and take the set of revisions which resolve it and merge only those revisions into the 3.0 branch. I don't believe SVN has any way to do this other than manually taking the diffs for each revision and applying them

Of course, the auto-merge algorithm also appears to work a lot smoother and git was built from the ground up on the "make a branch for all the things" model, so branching is just really smooth and easy in it. It just seems natural to branch often with how lightweight it's branches are

Earlz
  • 22,658
  • 7
  • 46
  • 60
  • Also, I'd imagine that mercurial has similar functionality – Earlz Oct 26 '12 at 20:40
  • 2
    Actually, you can do the exact same thing in SVN. I do it all the time. The SVN Merge command can pull a revision (or range of revisions) from a different branch and apply it to your working copy, and then you commit it. – Mason Wheeler Oct 26 '12 at 20:40
  • 2
    @MasonWheeler Keep in mind that a lot of the anti-svn sentiment was directed to versions prior to 1.5 (when svn got merge tracking). And of course a lot of it is just pointless fanboyism... – yannis Oct 26 '12 at 20:42
  • 3
    @MasonWheeler see also http://stackoverflow.com/a/4215199/69742 That post boils down to DVCS keeps track of **change-sets** not **versions**. Change-sets are inherently easy to take and merge... versions not so much because they require context – Earlz Oct 26 '12 at 20:44
  • @MasonWheeler oh and this one: http://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn – Earlz Oct 26 '12 at 20:47
  • This is actually an advantage of SVN over Git. SVN can track cherry-picks in the data model (since it tracks merges as a set of merged revisions), whereas Git can track only full merges (since each commit has a pointer to a list of parent commits, with multiple parent commits for a fully merged branch). `git cherry-pick -x` will include cherry-pick information in the commit message, but it won't be strongly typed in the data model the way that full merges are. – Max Nanasy Jan 22 '15 at 02:21