Subversion vs. Git: Myths and Facts | Hacker News Reader

Subversion vs. Git: Myths and Facts

svnvsgit.com

2 pointsrusk7 comments

This is hardly an unbiased post... which is fine, people can write what they want to write, but it makes it easy to dismiss the entire article as simply being the work of an “svn fanboy”.

It also has some inaccuracies: git can be extended to support large repositories; Microsoft has OS tooling that enables them to keep the entire Windows codebase in a single git repo, using a “copy-on-access” model, which seems to be equivalent to SVN’s offering. And things like git-lfs help with large binaries. As for the “larger teams” argument, if all you’re looking for is consistency of single files, SVN’s model seems to be equivalent to pulling before a push... which is what you do anyways (Maybe I’m missing something here?).

As for the CLI, I consider that separate from the interesting discussion. There are good CLI wrappers for git (gitless, etc), and also GUI wrappers. I’m sure similar wrappers exist for SVN, but it’s besides the point.

This may be the first website I've seen that has absolutely no information about the identity of the writer or the purpose of the company behind the .com domain, assuming there is one. Strange.

having worked with both svn and git (and cvs, perforce, teamware), and having integrated svn/git/cvs/perforce clients into a production application, I have to say that switching to git was the most enjoyable experience.

yes, git commands have weird names. yes, git is puzzled by renames. yes, merging might be a problem.

but svn is just too damn slow! svn is "cvs done right". there is no way to do a cvs right: file-oriented change control must be replaced by a snapshot-based change control (and it was, in git).

now if I could only version directories and attributes in a platform-independent way...

Sorry, I just can't let your second to last remark pass: SVN is snapshot based.

Until 1.7 (?) they used .svn/ in each directory. They since switched to a different storage arrangement. I don't know how good or bad it is now. Early on I've seen situations where the workspace got corrupted to the point where I needed to wipe it out and do a clean check out.

Yeah I don't know, I haven't used SVN in a while, but one thing I certainly did miss when moving to git is that SVN has a revision number for the entire repository [x], which was very handy for build identifiers and the like.

[x] any change to any file or property increments the overall revision number so you can always retrieve the entire state of the repo at any particular point in time.

While obviously biased, I have at least learned that svn seems to have easier merge experience than it used to.

Reply on news.ycombinator.com