Joel is wrong. Subversion does not equal leeches. | Hacker News Reader

Joel is wrong. Subversion does not equal leeches.

blog.beanstalkapp.com

23 pointsahoyhere31 comments

I don't see the part in this post where he supports the title/thesis of the post. He clearly states

DVCS provides a much smarter workflow for merging and sharing code.

Just because it doesn't have a gui as sexy or user friendly as versions doesn't mean the technology isn't better which is the point of Joels quote

If you are using Subversion, stop it. Just stop. Subversion = Leeches. Mercurial and Git = Antibiotics. We have better technology now.

The technology is better, just as antibiotics are better. However sometimes the need still arises for leeches.

Aside: Both these posts are self serving posts about competing products. Beanstalk vs. Kiln.

well yeah but the gains from switching from svn or even cvs to a dvc system are far less than the gains from going from no version control to any.

The thing that pisses me off is people switching, with virtually no good reason, to the current trendy one. Probably because Joel says it's cool. Just pick one, use it religiously, and get on with writing some code.

> Just because it doesn't have a gui as sexy or user friendly as versions [...]

Subversion's killer-app GUI is Tortoise, and Mercurial has a similar tool, too: TortoiseHg. (http://tortoisehg.bitbucket.org/)

So I don't think this is really a GUI problem.

No Joel, is right. The Beanstalk goal mentioned in the linked article "Bring version control into the development process for those who don’t use it" is better served by Git, Mercurial, BZ. All of which make easier for two developers (a small sub-team) to share code without needing a server provisioned.

> without needing a server provisioned.

or they could use beanstalk, i suppose?

Yes, but with git, mercurial and bzr you can sink with a USB key on a train (w/o wifi or cellular network).

Subversion doesn't require a server either. You can create a repository anywhere.

The difference is that you can't do anything without that repository - branching, merging, stashing, diffing, commiting, etc.

In Git, every copy of the code is a repository. If you and a friend are on a train working on code hosted in an SVN repository, you have to jump through hoops without internet access. With Git, you can clone your branch onto a USB key, and then the other person can pull your changeset from that repo. Once you have internet access, either one of you can push the relevant changes to the origin server, or anywhere else for that matter.

You can create an SVN repo anywhere, but everyone has to use the same one. With Git, anyone can use any repo, and they can all interact.

I hesitate to say this because I actually have an anti-subversion rant in the works, but I think he makes a good point here.

For any develop who is at all serious about their craft, it's absolutely insane to go on using a crippled tool like subversion. However if you have a team of talentless monkey coders mixed with a generous helping of non-technical asset producers (designers, copywriters, etc), then modern VCS won't really give you any compelling benefit, so you are likely better off taking the better tooling.

In the long run Subversion would be better off if they just rewrote it on top of git plumbing, but barring that, it's not necessarily true that everyone has much to gain from modern VCSes.

I tried to like Subversion for quite a long while (any improvement on CVS would be good). In the end the main differences from CVS were. 1: a repository that (at the time) you could not delete "oops I checked in a DVD" from. 2: an Eclipse module that broke during most Eclipse updates.

When svnmerge.py inevitably yaks all over yet another branch we're trying to merge to a release candidate after a rebase or two, I'm only barely capable of figuring out how it got confused and how best to recover, and the rest of my team (experienced developers all) isn't even as good at it as I am. I hear 1.5 with merge tracking isn't that much better.

svn is an extremely leaky abstraction, and just not a reliable enough tool to unleash on the people you're describing. Fortunately we're switching Real Soon Now(tm).

Just because there are no shiny GUIs to git yet (are there? I don't know)? Otherwise git seems to be easier to use to me. For one thing, it doesn't pollute every directory with .svn folders.

I suppose you can use subversion standalone? It's been too long since I used it. Anyway, with git just type "git init" and you are ready to go.

gitx, gitg, giggle.. I use gitg on my Ubuntu and gitx on my Mac. Love both, though I use them less. Command line ftw!

I've found Gity to be pretty slick.

http://macendeavor.com/gity/

Not a GUI, but tig* is a fairly sexy repository browser in ncurses.

* http://jonas.nitro.dk/tig/

A friend recommended a fork of GitX:

http://github.com/brotherbard/gitx/downloads

there's tortoisegit, but just having a GUI oftentimes doesn't seem to be enough for people trying to wrap their mental hardware around the core concepts of git, I've seen devs using tortoisegit just unable to understand the difference between git and subversion and consequently mashing their code / losing changes very easily etc.

Not good devs, mind you, but you go to war with the army you have.

> If we tried to accomplish the first goal (Bring version control into the development process for those who don’t use it.) with Git or Mercurial, most people would have been lost. With the lack of any decent GUI clients, a difficult mental model, and a less proven (read: newer) system this would have been near impossible.

According to github.com/home:

> Join 224,000 coders with over 733,000 repositories

Also, in a recent blog post, they said they're clocking about 109k commits per day.

I'm not sure where beanstalk is there, but that's a few times larger than google code (which also bet on subversion).

I think you miss the point here. It's not about betting on one or the other, it's about having options depending on your team or project.

I use SVN on a 2 person academic project. It works great, I've never had any problems or complaints. Is there some compelling reason to switch to a distributed VCS?

Sheer speed.

Perhaps my project is too small to encounter performance issues (only have ~15k lines of code), but SVN has always been perfectly snappy.

I like running with only one leg; it works well. But I'm too stubborn to try with 2, even if professional athletes keep telling me it is better for many reasons.

IE6 works well for me by the way. And I play piano without black keys, it works well for me. Oh, and you know what, I always study the night before my exam, it works well for me.

But what exactly is better?

Branching

At the beginning you're are not even conscious that you can, but once you've discovered the power it gives you, you will branch twice a day just because you can (and more if you need).

The two stage commit approach of git is interesting but not fundamental IMHO. "stash" is really cool.

The kind of features git gives me makes me use it even when I code alone.

I skipped over SVN on my way to Git from CVS, but I've heard the handling of branches in SVN isn't much better than CVS, and there it is absolutely horrible.

So, if you don't use branches it is understandable why you are happy with SVN. If you want branches, you'll need Git something like it (HG).

Branches work just fine in SVN. Merging isn't great, but it is much better with merge tracking in recent versions of SVN.

Yep, we don't use branches. Maybe that's the reason everyone seems to have such (otherwise mystifyingly) negative opinions of SVN.

For me it was the other way around. Using git made me want to use branches.

an entirely different audience appeared that we never expected: Designers. [...] who use Beanstalk for binary files

That. (And this: http://news.ycombinator.com/item?id=1201559 )

Not begrudging the coders kudos for a solution to their problem. But studiously ignoring wider application seems a bit short-sighted.

[... crickets ... a day later, back at the ranch: ]

http://www.reddit.com/r/programming/comments/biv72/why_git_a...

As a game developer, my repository is many gigabytes in size - consisting mostly of binary data. Perforce handles it like a champ; it scales incredibly well, even to the near-ridiculous volumes of data I need to build my projects.

And first hit on a quick search: It is well known that Google uses Perforce as its internal source management system (it has a source license).

So, obviously, it should be prescribed that everybody and his dog use a DVCS good at merging changes on text files, which solves the problem of the subset of people that:

1 - Hop around like rabbits, carrying their copy of the whole repository, and previously had to mail each other patches.

2 - Only work on text files, code with barely any non-text documentation, like top-dog kernel developers.

Good going.

Reply on news.ycombinator.com