Subversion vs. Git: Myths and Facts

Number 2 makes me laugh: &quot;Branches are expensive in Subversion - False. A Myth.&quot;<p>Totally misses the point that the expense of branching and merging in Subversion is all in the UI&#x2F;UX. Not only is it horribly cumbersome, it&#x27;s also much easier to get it wrong, not obvious that you are getting it wrong, and harder to recover once you&#x27;ve discovered you&#x27;ve got it wrong.

So I cloned the WordPress git repo and noticed immediately that neither the size of the `.git` directory nor the total size (working copy + `.git` directory) was as large as the article claims.<p>Instead of 32,647 commits, the number at the time I cloned it was 37,304 (`git rev-list --all | wc -l`), or 34,165 reachable from HEAD (`git rev-list HEAD | wc -l`), yet the total size was 162M (`du -hs .`) -- a bit smaller than the 169.7M cited in the article.<p>Further, if I re-compress everything (`git gc --aggressive`) then the total size decreases to 117M. That is a sizable difference to begin with -- and doubly-so given that it represents more commits than either of the repositories in the original comparison.

This reads like an advertisement for svn more than anything. There&#x27;s nothing wrong with trying to dispell some myths about svn, but the author should be up front about it.

This article suffers from major bias and is pure conjecture from the authors perspective.<p>I could counter argue with many reasons why git&#x2F;hg&#x2F;perforce&#x2F;cvs is superior but it misses the core point about any VCS. It&#x27;s about team collaboration and different tools suit different teams.

Dispel all the myths you want, but until you dispel the &quot;SVN can&#x27;t do offline commits&quot;, I have no use for it. That&#x27;s the only reason I read the article, to find out that I&#x27;m behind the times and SVN finally caught up ten years later. Alas, it&#x27;s simply, &quot;see, SVN is just as good as git, and better in exactly one respect (huge monolithic repos)&quot;, except still severely lacking what is common use case for me.

With the CURRENT version of Subversion, do they allow you to do offline commits?<p>Specifically if I am taking the train into work, connectivity is spotty, with git I can commit as many times as needed against my local offline repository then push it once I am online.<p>That didn&#x27;t used to be true with Subversion, but it may have changed. Thus my question.

Does svn still force me to update before I commit (and possibly fuck up and destroy my changes) when there are conflicting changes with upstream?<p>Being able to commit first and then care about conflicts second is my biggest selling point for DVCS (git&#x2F;hg).

&quot;Due to historical reasons, Subversion doesn’t properly track file and folder renames (mostly because file renames rarely happened before refactorings were invented).&quot;

The &quot;Paid for by Apache Subversion&quot; is missing in the footer :)<p>More seriously, some interesting myth busting, but I still prefer a distributed model.

&gt; An outdated myth.<p>Don&#x27;t you mean an outdated <i>fact</i>, since it was true.<p>&gt; Certain workflow limitations exist.<p>Also true of SVN. I&#x27;d argue it is more true of SVN than Git, but whatever.<p>&gt; Git history is not safe<p>You gave so much leniency to subversion for half-truths earlier, but you&#x27;re going to come down on Git for this? `rebase` does not destroy history. `commit --amend` does not destroy history. `filter-branch` does not destroy history. The old commits are still there. You can easily find them with `reflog`. `reset --hard` doesn&#x27;t even add new commits, just changes where a branch pointer points.<p>As identified by others in this thread, this is really cherry-picking the issues and totally ignoring some major flaws and drawbacks specific to SVN that led to DVCS&#x27;s in the first place.<p>If it wasn&#x27;t already obvious that this was a biased piece, you include only negeative experiences with git in your &quot;further reading&quot; section.

This definitely feels like an advertisement for Subversion. It spins all of these comparisons against Git.

I recently worked with SVN after 6-7 years with git. Working with branches was a nightmare in comparison to git and felt incredibly cumbersome.

With the current version of git, have they already implemented Unicode support? Last time I checked, git treats UTF-16 text as binary.

&gt; Except for the case of storing a lot of binary files, when Subversion repositories could be significantly smaller than Git ones (because Subversion’s xdelta delta compression algorithm works both for binary and text files).<p>Does this still hold true now that GitHub handles large binary files? <a href="https:&#x2F;&#x2F;github.com&#x2F;blog&#x2F;1986-announcing-git-large-file-storage-lfs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;blog&#x2F;1986-announcing-git-large-file-stora...</a>

The &quot;fact&quot; about the sizes are total bullshit. Last time I checked, SVN repo was 3x larger (1,5Gb vs 4,5Gb) and a whole fucking lot slower.