Hacker News Reader

Comment by stevenjgarner | Hacker News Reader

What was the relationship or connection with Apache Subversion, if any? I remember using SVN for about 5 years before GIT.

View on HN

The article has a one liner Linus didn't like it. But if you google it you will come across this Linus quote: "Subversion has been the most pointless project ever started. Subversion used to say CVS done right: with that slogan there is nowhere you can go. There is no way to do CVS right."

Just watch the Linus Google talk. It's all there.

The article mentions that merging in svn was not as easy as what BK did and what git needed. It allowed merges but they were “big deals” where git makes merges very easy and common.

I remember projects where out of 50 people only 1-2 were capable and trusted to do merges. And that was a tedious and boring job so the joke was that you never wanted anyone to know you could merge a code base for release.

I suspect this is a myth. I used svn for years and don't remember merging being problematic. In fact I remember it being better (less need to manually merge) than today's git. What svn couldn't support well is: zillions of branches. So branch-happy workflows would kill the server. Today's PR-style would probably work ok since it mirrors how we typically worked with svn -- small frequent commits to trunk. Branches only used for maintenance on past releases.

You are remembering correctly. Branching on svn was painful; on git it's basically free.

rebasing of chains of check-ins is a pita in svn, and with git taking over the world, the svn book is no longer getting the love it needs so the de facto reference documentation is no longer fully up to date with the tool.

The thing that CVS/SVN didn't like much was people working on the same area of the code at the same time.

Arguably git doesn't like it much as well, but it can branch easier.

The real thing needed was the decentralization, CVS/SVN weren't setup to allow every copy to be a master copy on equal footing (and even now most people do NOT use git that way, they setup main or master and let GitHub be the central authority).

It can be slow. As in: 20+ minutes slow.

It's possible to only commit part of a merge.

It's possible to accidentally include additional changes after a merge.

The article talks about Torvalds disliking CVS and Subversion but never making himself clear about the reasons, and later suggests that the most important "not fully articulated" reason was speed.

But I think a more important reason for him was that he felt that CVS and SVN implicitly came with a development model where a small group of people has official commit privileges, while he very strongly wants a model without that.

See for example what he says here: https://www.tag1consulting.com/blog/interview-linus-torvalds... (search for "commit bit").

svn doesn't support loosely distributed operation. You need a single central server and all contributors need accounts on that server. That server ends up being costly to provide for projects of non trivial size. Git "won" because it didn't have those two problems.

SVN enforces in code the reality of "who has control" whereas git allows that to be more lax. If Linus were to go insane tonight one of the other kernel maintainer's git would become the "main" without needed anything official done.

The article mentions that Subversion existed at the time Linus chose Bitkeeper. As I understand it, the development goal of Subversion was to be CVS without the problems.

Subversion was so bad I missed CVS.

I liked subversion much better than cvs as it was less buggy and was more integrated with Apache for web-based vcs.

Reply on news.ycombinator.com