Comment by spacemanaki | Hacker News Reader

Comment by spacemanaki | Hacker News Reader

Parent Full thread

I think there are some features where SVN is superior to Git (dealing with large binary files?) but I think you could basically use Git in the fashion you describe, and it would be a better experience than SVN. Just being able to quickly checkout old versions without touching the network is awesome.

On the other hand, as soon as you bring a bunch of people working on a project together, isn't the development inherently non-linear, and there's the possibility that you will need to deal with (implicit) branches? I guess if every person committed to the trunk frequently you wouldn't need to.

> So enough with the "This is better than this" mentality

I understand the sentiment, and the desire to avoid flamewars and endless bitching about tools, but no thanks. If I never have to deal with CVS telling me that every single file in my tree has a conflict in it again, I will be very pleased. If no one had a "This is better than this" mentality, we might not even have the choice of Git (or even SVN for that matter).

SVN is better than git for ANY binary files, really, because with no centralized repository it's rather hard for git to implement any kind of locking. Locking is pretty much essential for binary files, since most are not mergeable in any meaningful way. It's literally NO USE AT ALL to be forced to make somebody redo their recent work when there's a conflict :)

SVN's locking ain't so amazing, it must be said, because it's clearly not the way it's intended to work. But it's better than nothing, certainly, and TortoiseSVN on Windows has some nice features that make it work fairly well.

Another issue is the filling of your hard drive with crap - obviously git keeps the entire repository locally, and SVN keeps a previous revision (I think?), which is a bit useless for enormous hundreds-of-gigabytes repositories mostly filled with stuff that's not significantly further compressible. To add insult to injury, git then spits in your face by not letting you retrieve only part of the repository! - well, obviously the problem is that git just isn't designed for this kind of thing, not that its decisions are unreasonable. Shame, though... some kind of binaries-and-locking support would be nice. It would be great to be able to use git for everything.

I'm pretty sure that git does allow working with only part of the repository. You need to provide some specific options when cloning...

You're wrong.

You can create a git repository that has other git repositories in it (submodules) but you can't checkout an arbitrary subtree of a git repository. I spent a long amount of time searching for this, so I know.

Now, people have written scripts that will convert a directory to a git submodule by moving history around and stuff like that, but you need to check out the whole repository first.

Sorry, I meant "part of the repository" as "part of the timeline", not "part of the directory structure". You don't need to fetch the entire history.

I managed to persuade a multinational team of accountants to use SVN to manage their Excel spreadsheets - has worked remarkably well.

Your last point is a good one, but it's sort of like arguing over gentoo/ubuntu/centOS. At the end of the day who really cares - none of them are windows, so they're all good enough.

"gentoo/ubuntu/centOS. At the end of the day who really cares - none of them are windows, so they're all good enough."

That makes absolutely no sense whatsoever, unless it is a troll. Nothing can be "good enough" simply by virtue of not being something else.

That would make sense if we were talking about Git/Mercurial/Darcs/Bazaar opposite SVN, but in the context of SVN and Git, not so much. SVN is much, much closer to CVS than to Git.

Reply on news.ycombinator.com