2

After reading How and/or why is merging in Git better than in SVN? I still don't get it. Let's say I have multiple versions I'm maintaining (I need to maintain them all, all in production):

  • v1.0
  • v1.1
  • v1.2
  • v1.3
  • v1.4

Now I commit a bugfix to v1.0 (and I need this bug fix in all next versions).

Now in both git and svn I have to perform the following logical operations

  1. x=1
  2. merge into next branch v1.(x)
  3. check everything is ok (tests, build) for v1.(x)
  4. x++ goto (2) until at last branch

What is the major benefit of using git for that (or gerrit)? The logical operations of merge into next branch, commit, test are the same! So what is different? (If it's just minor merge algorithm improvements, it does not matter to me too much. I have a rather nice automatic merge resolve conflicts in Subversion. Also I don't mind checking out branch v1.1 to do the merge in subversion because I have some utility that does that for me so I invest no time in it).

Community
  • 1
  • 1
Jas
  • 14,493
  • 27
  • 97
  • 148
  • 2
    possible duplicate of [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) – antlersoft Apr 26 '12 at 20:07
  • This question is unlikely to product a constructive answer beyond the very thorough one included with the referenced question. – antlersoft Apr 26 '12 at 20:08
  • hi i described a specific scenario, i don't think the thorough one included with the original question answers it, if it is can you tell me how it is? (i don't see a solution there). – Jas Apr 26 '12 at 20:11

3 Answers3

5

Because git doesn't store deltas like other version control systems do, it stores the full content of each file in each commit (in a very compressed and efficient way, but to keep the things simple, just keep in mind that It doesn't store deltas, sorry to repeat but this is why most professionals new to git get so confused).

And when it has to merge, makes a three way merge between last state/snapshot of each branch and a common base ancestor instead of trying to apply the deltas/diffs (with changed contexts) of the last 100 commits of one branch into another.

Way simpler approach, and it's way more effective, it doesn't leave the user with 100 conflicts.

KurzedMetal
  • 12,540
  • 6
  • 39
  • 65
  • thanks for the clear answer. I just did a test with svn, i had trunk with test.txt with content test test test and a branch from trunk 1.0. now i changed in trunk test test test to be test vest test and then changed in my 1.0 branch to content test aest test and then to test vest test, then i did merge if what you said is true that would mean i would need to get a conflict from trying to merge first revision from test to aest, however i got no conflict and all was merged fine. – Jas Apr 27 '12 at 11:11
  • That's funny but I've heard the opposite opinion: git (in contrast to subversion) stores deltas :) – AntonK Jun 27 '12 at 09:47
  • Actually i'm not that sure about subversion, i'd bet it store deltas but i may be wrong, but i'm **100% sure that git doesn't store deltas**. AFAIK, in git, different portions of the files are [packed, compressed and hashed](http://www.kernel.org/pub/software/scm/git/docs/git-repack.html) and multiple of these packed objects represent the files that are added to commits (so, files in commits are a list of packed objects that can be reused in other commits, thus store is pretty efficient despite "storing" full files, no data is duplicated). – KurzedMetal Jun 27 '12 at 11:42
  • 1
    @AntonK It seems [subversion does store deltas](http://stackoverflow.com/a/127777/236871) – KurzedMetal Jun 27 '12 at 11:48
  • 1
    http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.diskspace.deltas – bahrep Feb 08 '13 at 21:17
  • @KurzedMetal does that mean that git's local diskspace requirements are much higher than SVN? And it grows exponentially over time? – Slav Nov 25 '14 at 17:11
  • Why do you think it would grow exponentially over time? Check this [wiki page about Space Requirements from the Git project](https://git.wiki.kernel.org/index.php/GitSvnComparison#Smaller_Space_Requirements). It uses as example a 12Gb Mozilla repository and the whole history consumed 30 times less in Git than SVN. – KurzedMetal Nov 25 '14 at 17:36
  • Side note: SVN may have better storage efficiency for big binaries with small modifications (image and video editing) unless something changed in the last years. I never used Git for other stuff than source code and small fixed binaries. – KurzedMetal Nov 25 '14 at 17:52
3

I think this point can be demonstrated when comparing the blame feature of SVN and Git. My company uses SVN (and I'm disgruntled about it). Our developers do not do their own merging so code is always merged by a different person. I'm often asked "Who changed that line and why?". So I perform an svn blame. If that line came in through a merge from another branch, the commit shown is that of the merge not of who edited the line. So I have to find that branch and attempt a blame on it. In the example above, if you started tracking at v1.4, you could waste half a day getting all the way back to v1.0 to find the change.

Git blame always gives you the commit of the person who made the change as that's what we're trying to find out. This is much better for accountability.

I think that is what's meant above by "svn has no concept of merges and branches". It only sees the commit made when the merge happened and can't trace the history back further than that in order to do a proper blame.

DigMachine
  • 31
  • 1
0

Although what you do looks same, the difference is that git is able to natively track what you're merging where for all of such steps. So when you update "v1.4", your can see that the bugfix was originally done against v1.0, then merged to v1.1 (and by whom and how), then to v1.2, v1.3, and finally v1.4.

svn has no concept of merges and branches by itself, the final product in v1.4 would be simply another tree revision that happens to change contents "branches/v1.4" directory. Recent svn releases have tried to address this problem by somehow tracking that a given revision actually merges changes from another branch, but that is something built into it later and it does not work very well.

The other important difference is that when I measured how long the process you've mentioned takes with one simple changes in two branches we had (they were quite different by that time) it took half an hour with svn/svnmerge and 11 minutes with git*. A lot of this probably has to do with the fact that svn needs to fetch all history information from remote server, and git has everything in local and native (=efficient) data structures.

(*This was the whole workflow w/ running tests etc. By itself, the time difference of svn merge and git merge commands was 1.5 minutes vs. <1 sec.)

che
  • 12,097
  • 7
  • 42
  • 71