edit this page - page history - about editing

My understanding of SVN and Git

SVN / Git

Based on the short white paper Git: from the bottom up, I've interpreted 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 branch 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 branch, in Git you just take the top commit; in Subversion, you replay through all the changesets from the root.

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. However, because it's considering each commit individually rather than just the top two commits (as in the case of merge), it produces better conflict resolution.

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.


Git seems great if you want to spend most of your time acting as a version control repository administrator, and you want lots of powerful functionality.

The critical concept (a commit being either a changeset or a repository snapshot) does not preclude a version control system from being centralised or distributed, so why isn't there a distributed version control system based around changesets?
Categories: Git | Subversion
edit this page - what links to here? - page history - top
Last edited by jevon jevon 37 months ago