I'll second your suggestion that centralized version control systems have advantages for small projects. I use SVN for most of my personal projects, because no one else is contributing. (Only one branch. In fact, I have never branched in SVN.) The simplicity is a major benefit.
The main downside is how condescending some Git users can be to SVN users. When I mention I use SVN, I often hear nonsense like "Oh, you must not understand tree structures." Actually, I do, and I see that they have no benefit for certain things I'm working on.
The one thing I'd like is the ability to commit without an internet connection, which distributed systems can easily do. But this hasn't been enough of an issue to motivate a switch.
And Subversion, being centralized, allows you to opt-in to a "lock, change, commit" workflow, on a file-per-file basis, or on basis of file-type. Which is great for binary files, as pretty much any binary file such as Excel sheets or Photoshop documents or even PNG assets can't be easily merged, so Git's "work independently, then merge later" workflow can never work with those files.
At least git stores its local copy of the repository compressed -- svn keeps a second uncompressed copy of the current revision, to be able to run a diff. So neither are great for large binaries, although at least subversion will only grab the latest.
But use of compression and binary deltas does mean that (for regular text-based code) a git checkout including all history can be smaller than a subversion checkout with just the latest version.
I don't find the maintenance burdensome. I keep my software up to date, including Git, so this isn't an argument against SVN. And I run a weekly backup script that first checks the integrity of the repositories. (This check was motivated by a hard drive failure which caused a small amount of data loss. Git probably would have helped in this case, but now I think I'm good.) I haven't done much anything else specifically for SVN in the past 5 years.
To be fair, most of my issues were with Apache, not SVN itself. The most egregious thing I remember was that Apache changed configuration directives twice during the time I maintained it in a way that broke my SVN server, but there were plenty of other papercuts.
This was also during SVN's heydey. I'm sure it's much more stable now. ;-)
My recollections of using Subversion, a few years ago, are mainly about terrible performance and frequent unrecoverable damage to working copies and repositories. "Atomic" commits appeared to be named for their ability to leave a radioactive wasteland behind them.
And of course, a policy of not branching because it's difficult and dangerous doesn't mean taking advantage of simplicity.
Managing branches is a pain with subversion compared to git, sure. But dangerous?
There are major projects out there still using subversion. GCC
for example. They have lots of branches. As for performance... well, svn is way better than CVS.
Sounds to me like you didn't know what you were doing with SVN. If I complain that Git caused some problems, Git users are likely (and often justified) to tell me that I was using Git wrong. But it's rare that the same reasoning is extended towards SVN by many Git users.
The worst I've had with SVN was a broken working copy, which is usually easily fixed. With Git, problems like that occur much more frequently. In the past 6 months I likely have completely wiped my local Git repository for a particular project alone more times than I've ever had to fix a broken SVN working copy. My experience is closer to the famous XKCD comic:
Now, perhaps you could argue that I don't understand Git well enough, and I wouldn't necessarily argue against that. I think Git has a terrible and confusing UI compared against other distributed systems. (And the simplicity of SVN makes its UI good, I think.)
As for performance, again, I use SVN with small projects, so performance hasn't been an issue. To be honest, I probably save time compared against Git from not having to type as much with SVN!
And I don't branch in SVN because I don't want to, not because it's difficult or dangerous. Branching would provide no benefit in my case. If I wanted to branch, I'd switch to a distributed system. My experience talking to some Git people is that they often branch as a habit without considering what could be gained from branching.
If network failures can leave working copies in pieces, in an unknown state, it isn't a matter of knowing what one's doing. Out of the box, Git and similar modern VCS systems offer better safety, and better auditing whenever something goes wrong.
> My experience talking to some Git people is that they often branch as a habit without considering what could be gained from branching.
There's just never a reason to not branch. It keeps ideas, efforts, tasks separated really nicely and has essentially no cost to doing so. It lets me have a completely different environment to try things out, wreck, and abandon things without ever touching the branches that are important. When I'm done, a simple merge brings it all in at once.
> It lets me have a completely different environment to try things out, wreck, and abandon things without ever touching the branches that are important.
These are all completely valid reasons to branch. They also don't apply to most of my projects. And for the ones they do apply for, I use Git.
My small projects tend to be relatively simple, and often contain a lot that's not code. (Some contain almost no code at all.) For example, I've had people recommend branching to keep track of different versions of the same paper they're writing. But this immediately struck me as a waste of time. I'll be submitting only one version of the paper. Why keep multiple internal versions?
I am not convinced by the argument that I can have a branch for each person I ask to read the paper. Merging in the handwritten changes they provide me is not hard. Branching would just be extra work in this case.
It can be nice to try different organizational structures sometimes, but I've found it easier to simply have a different TeX file in that case. (Or better yet, multiple TeX files for each part, and then a set of master TeX files that organize the paper differently.)
If someone has a good argument for distributed version control in this use case, I'd be happy to hear it.
> I use SVN for most of my personal projects, because no one else is contributing. (Only one branch. In fact, I have never branched in SVN.)
Same here, I have used the SVN + Trac combination for my personal projects for almost 12 years now, it isn’t broken for me so why should I ever think of fixing it?
In both CVS and Svn you can just check out from a local directory. For a couple years I used CVS for my private local repos where CVSROOT was sth. like /my/cvsroot. Same is possible with Svn too.
The SVN documentation (used to) warn that concurrent access in this configuration could lead to data loss. Even though I'm the only human who accessed my repository I did use scripts, so I always avoided this setup because of that.
I resisted moving from SVN to Git for my personal projects for a long time, mainly because I was too lazy. But conflicts or repos getting into an inconsistent state that required fixing was too regular an occurrence, and eventually I snapped.
I agree that the mental model with SVN is much simpler that Git, and I used SVN on Windows with AnhkSVN and TortoiseSVN, so maybe it works better on Linux
The main downside is how condescending some Git users can be to SVN users. When I mention I use SVN, I often hear nonsense like "Oh, you must not understand tree structures." Actually, I do, and I see that they have no benefit for certain things I'm working on.
The one thing I'd like is the ability to commit without an internet connection, which distributed systems can easily do. But this hasn't been enough of an issue to motivate a switch.