12

I'm looking for concrete sample merges that will work in git, but will result in a conflict in SVN. In addition to that, samples of hard/painful SVN merges that you never tried in Git would also be fine.

There are mainly four categories of merges I could identify in relation to my question:

  1. big bang merges
  2. rename/move related merges
  3. created directories/identical files in both branches
  4. criss cross merges

Did I miss any scenarios here?

Finding samples for 1-3 is trivial (Find a sample for 2 in the comments, 3 as part of my answer and 1 is nearly any rebase). Has anybody a sample (that doesn't look to academic) for a successful criss cross merge, which will fail in SVN?

Community
  • 1
  • 1
mheinzerling
  • 1,035
  • 1
  • 10
  • 31
  • 1
    Would http://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn?rq=1 help or be a good starting point? – VonC Feb 15 '13 at 07:39
  • @VonC I guess I have read "all" questions to this topic here ;) I'm totally aware of the theory behind git and SVN. But I'm looking for a concrete sample. I can't believe that I'm the first one who has to convince his colleagues this way. Somebody definitely created such samples already. The samples should really be of the kind: do x, do y, do z -> Conflict in SVN/Fine in git. A long talk about DAGs and Trees is nothing for an "elevator pitch" :) – mheinzerling Feb 15 '13 at 08:20
  • http://stackoverflow.com/questions/2475831/merging-hg-git-vs-svn?lq=1 might have one or two – VonC Feb 15 '13 at 08:26
  • Thanks for your effort, but as I said finding rename/move related examples is trivial. Just create a class. Rename in one branch. Add a method in the other branch. Merge -> Git/Fine vs. SVN/Conflict. – mheinzerling Feb 15 '13 at 08:35
  • Ok, I will follow this question with interest then ;) – VonC Feb 15 '13 at 08:42
  • It makes sense to describe SVN workflow which is compared and define SVN version to filter out limitations of old SVN versions which are usually pop up. – maxim1000 Feb 15 '13 at 10:08
  • @maxim1000 I don't get it?? – mheinzerling Feb 15 '13 at 21:21
  • @mnhg, I just saw much of negative feedback about SVN based on features of its old versions or some assumptions that there is only "trunk-only" workflow in SVN. Such things mask real limitations of SVN. But it seems to not be the case for this topic. – maxim1000 Feb 16 '13 at 05:58
  • 2
    Probably the reason you're not finding a lot on this topic is that, by itself, the difference between SVN and Git "merges resulting in conflicts" isn't all that compelling. You're looking at like 0.01% of the real reason to switch to Git. – Ryan Stewart Feb 19 '13 at 05:45
  • 1
    @RyanStewart Everybody heard about merging in git is easier than in SVN and I guess that's why everybody want to see such sample. Personally the visualisation of the history/branches would be enough for me to migrate to Git :) But all the small benefits in it own seems to be to small to justify a migration. Do convince management you need more than many small nice feature. What is the killer feature from your point of view? – mheinzerling Feb 19 '13 at 06:38
  • 2
    @mnhg killer feature? rebase: ie: let's apply my your dev on top of my dev. And that is how git started: as a patch manager for Linus to apply hundreds of patches he received every day. Efficient Merging is a natural consequence of that. Migrate just for merging is missing the point: you migrate because of the flexibility to integrate code from others through rebasing plus merge: http://stackoverflow.com/a/804178/6309 (plus all the other advantages of off-line commits, bisect, and so on) Origin: (2009) http://gitster.livejournal.com/35628.html – VonC Feb 20 '13 at 07:20
  • (... and (2012) http://typicalprogrammer.com/?p=143 (tongue in cheek)) – VonC Feb 20 '13 at 07:25
  • @Vonc +1 for the reference to the original mailing list post – mheinzerling Feb 20 '13 at 09:32
  • I work with SVN daily and we have 3 branches at any time. Work mainly on one and merge to two others. I really don't see any problems with merging. So I would be interested in seeing when SVN doesn't work the way Source control system should. – Piotr Perak Feb 23 '13 at 10:42

3 Answers3

6

Surely it's worth mentioning the octopus merge strategy?

Generally it's quite difficult finding concrete examples of octopus merges with the maximum 8 branches (the minimum is 3).

example octopus merge

However, to answer your question perhaps a bit more precisely I don't think providing a contrived 'this works in Git but not in SVN' example will win you any battles with your colleagues/management.

I think it is difficult - and I'm speaking from my own experience transitioning from SVN to Git after moving company - to appreciate the true power of Git without good knowledge of the underlying 'nuts and bolts' of both tools. I'm not sure if Linus himself could present a winning 'elevator pitch' to somebody (a typical person in the street) ignorant of the inner workings of Git vs SVN.

Some may disagree with this view but my adoption of Git came from well-respected people saying it was the best tool for source control; I trusted them and they've been proven to be correct as I've learnt more about how Git works internally and from its highly productive workflow.

My lasting memories from using SVN are resolving merge conflicts on a daily basis. I used to think that was a normal part of developing software but it doesn't have to be.

ben.snape
  • 1,495
  • 10
  • 21
  • Most of the SVN users I know prevent branching at any costs. Telling them that you can merge multiple non-conflicting branches at once is useless :) They are happy as it is. As one of my last arguments I just need another nice sample they might also run into. (Of course I skip all the other arguments in my question, but please don't assume that I just want to throw the example on their desk and convince them without other words.) – mheinzerling Feb 20 '13 at 05:49
  • Octopus merge is git-specific, not SVN weakness – Lazy Badger Mar 06 '13 at 06:05
  • It's a weakness if it doesn't have it, so I disagree. – ben.snape Apr 17 '14 at 09:40
4

Found an article with a nice sample. The "team b" branch is only created to show the tree conflict with creating the same directory in two branches. Here is an overview: Wall sample

mheinzerling
  • 1,035
  • 1
  • 10
  • 31
  • 1
    Please, don't refer on "Monkey with grenade" samples: Subversion has representative set of *real* weakness, no needs to demonstrate **utterly degenerated** cases – Lazy Badger Feb 16 '13 at 08:18
  • @LazyBadger Feel free to add some as a seperate answer! (Btw. there are many monkeys out there :) ) – mheinzerling Feb 16 '13 at 09:31
  • 2
    Just came to my mint: A monkey with an SVN-grenade would die, the same monkey with a git-grenade would survive. This means that the sample didn't seem to be that bad... – mheinzerling Feb 16 '13 at 13:38
3

Well, real sample of strange and bad merge caught and registered in real-world

  1. File added in branch
  2. Through two merges (branch -> trunk -> another branch) file appeared in another branch
  3. File edited in branch-target
  4. Merge branch to trunk failed after it with "Tree conflict" for file in question

r9 | Badger | 2013-03-06 11:42:34 +0600 (Ср, 06 мар 2013) | 1 line Changed paths: M /branches/B2/src/add.txt

B2 changes in add.txt
------------------------------------------------------------------------
r8 | Badger | 2013-03-06 11:35:45 +0600 (Ср, 06 мар 2013) | 2 lines
Changed paths:
   M /branches/B2
   M /branches/B2/core.txt
   A /branches/B2/src/add.txt (from /trunk/src/add.txt:7)

Merge from trunk to B2
------------------------------------------------------------------------
r6 | Badger | 2013-03-06 11:31:36 +0600 (Ср, 06 мар 2013) | 1 line
Changed paths:
   M /trunk
   M /trunk/core.txt
   A /trunk/src/add.txt (from /branches/B1/src/add.txt:5)

Merge from B1 to trunk
------------------------------------------------------------------------
r5 | Badger | 2013-03-06 11:28:58 +0600 (Ср, 06 мар 2013) | 1 line
Changed paths:
   M /branches/B1/core.txt
   A /branches/B1/src/add.txt

B1 changes
------------------------------------------------------------------------

Merge attempt from b2 to trunk (expected result - merge changes for src/add.txt into trunk version of existing file)

>svn merge --dry-run file:///Z:/Repo/branches/B2
--- Merging r4 through r9 into '.':
   C src\add.txt
 G   .
Summary of conflicts:
  Tree conflicts: 1
Community
  • 1
  • 1
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110