5 ms·

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

hibbelig 4y ago
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.
- throwaway892238 4y ago
  Subversion was so bad I missed CVS.
  - prepend 4y ago
    I liked subversion much better than cvs as it was less buggy and was more integrated with Apache for web-based vcs.
stonemetal12 4y ago
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."
- kyberias 4y ago
  Just watch the Linus Google talk. It's all there.
mjw1007 4y ago
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-linux-and-git https://www.tag1consulting.com/blog/interview-linus-torvalds... (search for "commit bit").
- dboreham 4y ago
  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.
- bombcar 4y ago
  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.
prepend 4y ago
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.
- dboreham 4y ago
  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.
  - olddustytrail 4y ago
    You are remembering correctly. Branching on svn was painful; on git it's basically free.
  - froh 4y ago
    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.
  - bombcar 4y ago
    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).
  - Forge36 4y ago

hibbelig 4y ago

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.

throwaway892238 4y ago
Subversion was so bad I missed CVS.
- prepend 4y ago
  I liked subversion much better than cvs as it was less buggy and was more integrated with Apache for web-based vcs.

stonemetal12 4y ago

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."

kyberias 4y ago
Just watch the Linus Google talk. It's all there.

mjw1007 4y ago

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-linux-and-git https://www.tag1consulting.com/blog/interview-linus-torvalds... (search for "commit bit").

dboreham 4y ago
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.
bombcar 4y ago
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.

prepend 4y ago

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.

dboreham 4y ago
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.
- olddustytrail 4y ago
  You are remembering correctly. Branching on svn was painful; on git it's basically free.
- froh 4y ago
  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.
- bombcar 4y ago
  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).
- Forge36 4y ago