[danudey]

SVN was more straightforward to use, but that straightforwardness lost a lot in terms of fidelity.

The fact that it was easy to clone a subdirectory was nice; the fact that branches were just subdirectories also was not nice. The fact that tags were mutable since they were also just subdirectories... the fact that every operation you ever did required going to the server (commit, log, checkout, everything) made it a pain if you were on a slow link.

I can't count the number of times I was inspecting SVN history and had to just 'svn log > /tmp/svn.log' so I would have the whole log locally rather than having to hit the server each time I wanted to refine a grep.

[Zardoz84]

git-svn did wonders when we had the code base on subversion

[danudey]

git-svn is good for interacting with an SVN repository using git, but if you want to do a full-on migration there's a lot more to do.

I ended up using KDE's SVN migration tool, which was extremely featureful and versatile, as it was designed for the case of moving a massive, complex SVN repository into multiple separate Git repositories, filtering files/directories, importing tags/branches/etc. Saved me a ton of time.

My favourite part was at the end when we migrated the biggest, most important repo, a lot of the original SVN commits were imported from CVS, meaning we had a direct CVS-to-SVN-to-Git migration keeping all of the original metadata from the CVS commits (such as it was). The data purist in me rejoiced.

https://github.com/svn-all-fast-export/svn2git

[WorldMaker]

Also, for a lot of SVN history running it required such a specific Apache webserver setup that it was at times complex to configure correctly and made it comparatively expensive to find SVN repository hosts. SVN seemed cheap mostly only if you had cheap labor for infrastructure. Very few hosts got to "forge scale" like SourceForge did with CVS or GitHub would eventually/"quickly" do with git.