
Subversion vs. Git: Myths and Facts - rusk
https://svnvsgit.com/
======
jakear
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.

------
chmaynard
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.

------
java-man
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...

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

~~~
java-man
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.

~~~
rusk
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.

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

