Name a use case where svn is more suited than git is. I for one can't think of a single one. At most they might be equivalent. More likely git will be one of:
* faster
* more featureful
I am very interested in these use cases where svn would be better though. I haven't heard anyone actually share one but they talk about them a lot.
1. Dealing with large art/graphics/asset repositories. Having every artist with a private 50GB+ repository is unmanageable (especially when the artists can't be bothered to understand why add->commit->push is necessary).
2. Dealing with SOX compliance with regard to shipping software. You are required to keep a lot of redundant compiled files around.
To me the only good reasons to use SVN at this point are cultural. For example, your project can't afford the time to make the switch, or your organization has some useful tools built around SVN that would cost time and money to replace.
Like I said earlier, "because I want to" is a also valid reason, just not a good one.
@axod, Git repos take up way less space on disk than SVN because its compression and diffing is much better than SVN's. This is one of the first things you read in most Git FAQ's. If you're not aware of that, it indicates you've barely given Git a serious look. If you haven't given it a serious look, I don't understand why you are arguing against it so passionately. I'm guessing you dislike the (admittedly annoying) hype around Git more than Git itself.
Put some videos in svn and in git. update them 100 times to different videos each time.
The git repos now has 100 separate sets of video files, which will compress poorly.
The svn checkout has one set of videos.
The svn local checkout is likely to be far smaller than the git one.
Is the above true, or false. If false, why?
You're right though, I dislike the hype and the suggestion that it in some way matters. Sure, use revision control, but is it really going to speed up your software dev moving to something else? maybe, maybe not. Is it going to impact the chances of success for your startup? probably not.
Yeah, you're right that in this case SVN would have a smaller checkout size. So if this is something that you need then SVN would be a clear winner here in terms of disk storage.
However, with the more typical usage pattern of a repository of mostly code and perhaps a handful of smallish binary files, Git is almost always going to have a smaller checkout size despite including the version history.
I also think in this case the difference is like being shot in the stomach, or being shot in the knee. Both SVN and Git are going to give you serious pain.
In the name of science I'm converting the Mibbit repos from svn to git to see what the size difference actually is on a typical repos (I don't have videos in there ;)
Be interesting to see if svn is really that inefficient...
I think the fact that SVN adds almost 100 megs of crap to your checkout does suck. But yeah, I don't think it's a deal breaker. I switched to Git for the features; the smaller "checkout" sizes was just an additional benefit.
Thanks for posting your results, I think it's very cool that you are not a Git fan but took the time to really look into it.
Hm, only Subversion so far has good and "easy" GUI integration over all platforms. GIT's only failing on Windows, or Mercurial's on the Mac. For a multi-level of expertise, multi-platform, multi-disciplinary team (front-end, back-end, flash developers) working on Macs, Windows and Linux boxes, it seems to me SVN is still the path of least resistance. Much as I hate it.
From my understanding, git has the entire repository locally. There's obviously going to be some instances where this isn't possible or desirable. For example, small netbook or mobile device with small storage or slow net connection, wants to participate in large project with massive repository history.
* faster * more featureful
I am very interested in these use cases where svn would be better though. I haven't heard anyone actually share one but they talk about them a lot.