Live data from Hacker News

Why Subversion is better than Git

subversion.wandisco.com

21–30 of 47 posts

Re: Why Subversion is better than Git

#21
post #11

They've ignored Git's superior branching scheme though. Once you use Git for a while and get a hang of branches, you won't want to go back to the Subversion way of doing it.

FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard. Having said that, branching seems pretty simple in svn if you really like having them.

Maybe I'm Doing It Wrong, but when I want to tag a release (or create a branch) in subversion, I have to make a copy of the entire codebase. When I want to tag a release in git, it just creates a pointer to a revision. It's far less annoying for the next person who needs to checkout the code.

Re: Why Subversion is better than Git

#23
post #11

They've ignored Git's superior branching scheme though. Once you use Git for a while and get a hang of branches, you won't want to go back to the Subversion way of doing it.

FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard. Having said that, branching seems pretty simple in svn if you really like having them.

The problem is that svn makes branching easy, but merging very hard. This provides an incentive to postpone merges which of course makes them even harder once the excuses run out and they have to be done. Distributed SCMs recognize that branching is necessary, but actually provide the tools to make merging easy. Once merging is easy, branching doesn't look bad any more.

Re: Why Subversion is better than Git

#24
I always hated the way svn left its .svn cruft all over the place. Glad to see they're trying to get away from it with version 1.7 but it's the same kind of glad as seeing someone try to make an iPod killer.

Re: Why Subversion is better than Git

#25
post #8

He seems to be saying that svn is better than git because _some_ git users have a central repository they work against, and because they are planning on adding some features that might to some extent allow them to mimic a few things git already can do. That's just about the weakest argument for svn over git I've ever heard. Then the went on to use the word "enterprise" about 10 times in 30 seconds. Not convincing.

As an "enterprise" SVN user, I have to say I hate SVN "in the enterprise". Who the hell would want to rely on one repository in one location for all their writes? Not to mention delays in syncing changes read-only upstream creating confusion and loss in productivity for remote devs.

The HTTP method seems to be one of the most common uses in the "enterprise" because of its flexibility, but it's also the most buggy (in my experience). I know 'wandisco' makes its money off fixing all the typical "enterprise" problems with SVN, but we don't pay for 'wandisco' so we don't have the luxury of a proprietary fix for an open-source problem.

I have not used git. But the fact that it is distributed makes me want to try it a whole lot more.

Re: Why Subversion is better than Git

#26
post #11

They've ignored Git's superior branching scheme though. Once you use Git for a while and get a hang of branches, you won't want to go back to the Subversion way of doing it.

FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard. Having said that, branching seems pretty simple in svn if you really like having them.

Branching in Subversion is easy, it's the merging part that's difficult. That's because branches in Subversion are just copied folders that it tries to keep in sync with some magic "glued on" metadata attributes. (At least they were the last time I checked.)

In Git, branches are an inherent part of the repository graph structure. So the relationships of branches and merges are very low level and stable and work quite reliably in all situations.

Because of this I trust Git more for branching/merging.

Re: Why Subversion is better than Git

#27
post #11

Earlier quoted context omitted.

FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard. Having said that, branching seems pretty simple in svn if you really like having them.

The problem is that svn makes branching easy, but merging very hard. This provides an incentive to postpone merges which of course makes them even harder once the excuses run out and they have to be done. Distributed SCMs recognize that branching is necessary, but actually provide the tools to make merging easy. Once merging is easy, branching doesn't look bad any more.

It still looks bad to me. I want 1 codebase, developed linearly.

Definitely I can see the appeal of branches for software you ship, where you need to bug fix an old version and release a patched ver etc, but I can't really see the need for web based software, which I think is pretty usually developed linearly without much mess.

I much prefer doing branches in the source code (If that makes sense).

For example say you have a widget and you want to try a different strategy, create a newWidget in the source, make it so you can swap it in and out of the runtime maybe for testing. Keep developing it, until you're sure it's cool. When cool, replace widget with newWidget. If it doesn't work out, just delete it.

Re: Why Subversion is better than Git

#28
post #11

They've ignored Git's superior branching scheme though. Once you use Git for a while and get a hang of branches, you won't want to go back to the Subversion way of doing it.

FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard. Having said that, branching seems pretty simple in svn if you really like having them.

I used to think like you back when using svn... Now I think that when using svn, branching causes a mess and for that reason is bad... But, it's amazingly convenient and simple to use with git

Re: Why Subversion is better than Git

#29
post #27

Earlier quoted context omitted.

The problem is that svn makes branching easy, but merging very hard. This provides an incentive to postpone merges which of course makes them even harder once the excuses run out and they have to be done. Distributed SCMs recognize that branching is necessary, but actually provide the tools to make merging easy. Once merging is easy, branching doesn't look bad any more.

It still looks bad to me. I want 1 codebase, developed linearly. Definitely I can see the appeal of branches for software you ship, where you need to bug fix an old version and release a patched ver etc, but I can't really see the need for web based software, which I think is pretty usually developed linearly without much mess. I much prefer doing branches in the source code (If that makes sense). For example say you…

I use branches in Hecl to play around with experimental features. These are things that I want to keep around for a while, hack on, but that are not ready to be in Hecl proper. If I had to wait for a yes/no on those features to go on with other things, it would slow things down.

Re: Why Subversion is better than Git

#30
post #28
post #11

Earlier quoted context omitted.

FWIW, I'm of the school of thought that branching is bad, causes mess, and should be hard. Having said that, branching seems pretty simple in svn if you really like having them.

I used to think like you back when using svn... Now I think that when using svn, branching causes a mess and for that reason is bad... But, it's amazingly convenient and simple to use with git

I didn't mean that I believe branches in svn are a mess. I mean that the concept of using branches IMHO is messy and should be avoided. I just don't like that workflow at all. I don't think it's good for productivity.
Post reply on HN