view page source - page history - about editing

Revision History: My understanding of SVN and Git

This is revision 444 of the page My understanding of SVN and Git, as it appeared on Tue, 08 Apr 2014 20:38:22 -0700.
SVN / Git

Based on the short white paper Git: from the bottom up, I think I can personally understand the differences between Subversion and Git as:


This is critical, and explains why Git struggles to merge without conflicts (it has no idea of changes - only top-level repository snapshots) without using advanced functionality like rerere (which isn't turned on by default) or using custom merge strategies.


This means Git can only be considered as a tree of repository snapshots, whereas Subversion can be considered a tree of repository changesets. To get the HEAD of a repository, in Git you just take the top commit; in Subversion, you replay through all the changesets.

For a long time, Subversion did not store enough information about merged parents in metadata, which is why it had a bit of history about being terrible to merge. It now stores plenty of metadata now (and this metadata is revisioned too).


I think this means there's almost no difference between git merge A into B, and git merge B into A - they do the same thing - but in the first case, we have A and C as tree heads, and in the second base, B and C.

This also means that a Git merge only considers the two top commits (repository snapshots) of each branch, which is why merge conflicts are so massive and requires you to re-edit whole files. Whereas Subversion considers the combination of all change sets, and only requires editing of conflicting individual diffs.


It looks like this is great as long as the commits aren't related, otherwise you'll have endless conflicts for every conflicting commit in both branches, because snapshots can only be compared in terms of files (rather than changes). Which is my experience too.

The closest concept in Subversion for a rebase would be branching the target branch into a new branch, and then merging in all changesets from a different branch. This is identical to a Subversion merge, which is why the concept doesn't make sense.


I guess this is because there's no concept of /trunk in Git, so there's no where to place a /tags.
Categories: Git | Subversion

view page source - what links to here? - page history - top
Last edited by jevon jevon 61 months ago