Why Subversion is better than Git

http://subversion.wandisco.com/component/content/article/1/40.html

by jameseh • 16 years ago

20 46 16 years ago

subversion.wandisco.com

kennu2• 16 years ago

Somehow I get the feeling that he's getting bored with Subversion even himself and ready to move on to Git ;-)

unwind• 16 years ago

"Most people were using CVS or other proprietary version control systems"?

DannoHung3• 16 years ago

Think he meant to put pauses around proprietary: "Most people were using CVS or other, proprietary, version control systems"

timthorn• 16 years ago

Perhaps that should read, "Most people were using CVS or other, proprietary, version control systems"?

DannoHung3• 16 years ago

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.

axod8• 16 years ago

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.

lurch_mojoff2• 16 years ago

I believe that by "superior branching", DannoHung actually ment superior merging. That is something at which SVN is far, far behind DVCSs in general and GIT in particular.

Also, my experience, as non-representative as it is, has shown that cheap branching with efficient merging results in much less of a mess than everybody playing in the same sandbox and inevitably kicking everybody else's sand castles.

MrMatt• 16 years ago

Branching was a pain for me when using SVN - far too much hassle to keep on top of it all; All branches are visible to everyone and merging between them was slow.

With Git, branching is simple and really fast. It can also be done in such a way as to prevent your own personal development and feature branches from making it back into the central repo.

I've also found that cherry picking commits between branches and squishing small commits help me maintain the cleanliness of our repos (At no point in the history of our central repo is there half of a new feature or fix).

grogers• 16 years ago

Except that in subversion, branching is a great way to lose revision history. I think this is partly fixed with the merge tracking features in the more recent subversion, but in git it is simple - it just works like you'd expect.

natrius• 16 years ago

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.

jedbrown• 16 years ago

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.

kennu2• 16 years ago

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.

gommm• 16 years ago

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

cdavid4• 16 years ago

There are many situations where branches are the standard, conventional way of doings things: release managements, legacy development. Making branch hard does not make much sense - svn (with maybe cvs) are the only systems which make branch almost unusable. Every other system (including proprietary, non distributed ones) handle branch correctly.

Git made popular the use of branches for almost everything, but branches have been used way before DVCS became popular. It just happened to be that besides cvs/svn, all the non peculiar open source systems are DVCS, but working merge caps and branch managements are not specific to DVCS (but DVCS would be unusable without it).

sunchild• 16 years ago

Subversion is better than Git because many people use Git in a centralized manner? Wouldn't that make Git better, since it offers more options?

mru• 16 years ago

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.

peterwwillis• 16 years ago

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.

cdavid4• 16 years ago

The whole centralized vs distributed debate does not make much sense anyway, the choice of words is very poor. You almost always want to work on a common repository when working with other people - but the whole point of DVCS is that this common repository can be different for different usages (release vs development vs documentation vs testing ...). Something like subversion makes it very difficult to have several full fledge, synchronized repositories. Once you have a way to easily replicate live repo on the fly, you have already almost everything needed for a DVCS.

Also, something which is often overlooked: subversion was very poor even before DVCS came to light. It was only good at making sure everybody could work on the same snapshot. Branch management was inexistent not so long ago, no usable merge capabilities, awful interface to compare branches, etc... Just using git as a client to svn repository through git-svn already brings many advantages. Git-svn has saved me countless hours already compared to straight svn when working on public projects, especially for release management. svn log, blame, diff are slow to the point of being useless once you need to compare past revisions.

acg• 16 years ago

Came across as excuses as why the subversion design was so inflexible and how it's going to change.

Painting a picture that distributed version control systems learnt from subversion is rubbish. These technologies were developed over the same period: bitkeeper's development started some time in 1997.

j_baker• 16 years ago

I'll give them this: they certainly have their work cut out for them. If they can make me want to go back to SVN, they'll have performed a miracle.

nickyp• 16 years ago

Wow, that's 4 minutes of my life I won't get back, and I'm a subversion (and git) user ;-(

oomkiller• 16 years ago

I don't think there is anything they can do to get me to switch back. Out of every VCS I've tried, Git seems to be the most flexible and advanced.

mseebach• 16 years ago

Not for nothing, but Wandisco sells $1000/seat software that makes Subversion distributed (i.e. more like Git).

I checked it out about three years ago (before Git was on my radar) when the company I worked for brought on some offshore developers, and they were on a slow and unstable internet connection.

philjackson• 16 years ago

Is there a transcript of this anywhere?

drtse4• 16 years ago

Improving subversion borrowing some "distributed feature" from git&co? I'm not sure of how many would care... The thing that make svn a "toy" scm is the branching model/facilities(e.g. merge) and this is the area that seriously needs to be improved. Do you want to bring svn "to the enterprise"? Start offering what other enterprise scms offer, take clearcase for example, it has its issues but the branch/merge facilities are great.

machrider• 16 years ago

I literally thought this video was a joke for the first couple minutes. But then it wasn't very funny, and I realized "holy crap, this guy is serious." I don't know what else to say.

bozmac• 16 years ago

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.

cmallen• 16 years ago

This is marketing trash. Life is too short, don't watch.

rnicholson• 16 years ago

He also talks about the upcoming changes in Subversion, such as Working Copy Next Generation (WC-NG), which he believes will cause a number of Git users to convert back to Subversion.

If I've already left for git (or other dvcs) why would I come back just for "working copy"? I moved on from Subversion for much more than that...

vgurgov• 16 years ago

Haha this dude is so awesome :)

We are better cause... we are just better! Everybody knows that! And we gonna have these useless features from git soon too!

Why Subversion is better than Git

Related Stories