6 ms·

Why Subversion does not suck

45 points by asinglenet 18y ago

The Subversion Sucks meme is popular on the Internet. However, if we imagine a world without Subversion and other centralized version control systems, it's easy to see why Subversion does not suck, is not fading away, and in fact, has a rapidly growing user base.

tome 18y ago
In a world without Subversion, Subversion would be built out of Git. In a world without Git, Monotone, Darcs etc. ... well that's where we were 5 years ago, and it sucked.
- axod 18y ago
  Did it really suck? I was using subversion in a team of around 15, 5 years ago, and all in all it worked pretty well. It was rare that there would be any issue or that subversion got in the way. Maybe git is better... maybe it doesn't matter enough to bother changing. But you have to admit these types of things are more about what is "in fashion" than what is better suited to a particular task. Things go in big cycles. For a few years centralization is excellent, offers massive benefits, then suddenly distributed is excellent offers massive benefits etc etc As the post hinted, I wouldn't be surprised if 5 years from now git is pronounced as a terrible idea, and the trend setters go back to something more like svn.
  - tome 18y ago
    It sucked because we didn't have the possibility of distributed version control, even if we really wanted it. Some people and some projects prefer centralized. That's fine. But you can't build a distributed version control system out of a centralized one.
    - kragen 18y ago
      svk? Also BitKeeper was built on SCCS, and ClearCase MultiSite was built on ClearCase.
  - gcv 18y ago
    I'm very happy that Subversion works for you. For me, it just blew up on an update, which corrupted the fragile .svn directories it litters all over the working copy. "svn cleanup" couldn't repair the damage. This sort of thing happens on a regular basis. Git, on the other hand? No problems.
    - axod 18y ago
      "This sort of thing happens on a regular basis." Seriously? I don't remember ever seeing that, perhaps it's restricted to a certain O/S or version.
  - jbjohns 18y ago
    The issue with SVN is simply the work flow it forces you into. I can't tell you how many times I've looked at someone's repo and see .bak files everywhere. I know right away why they're doing this because I did it myself when I used CVS/SVN. DVCS's let you branch off, experiment, and if it works out you can push everything into the main tree with the history included.
- deleted 18y ago
  [deleted]
- tome 18y ago
  I should perhaps clarify. "It" is having Subversion, CVS and no distributed VCS. I didn't mean "It" to refer to Subversion.
moonpolysoft 18y ago
"Even designers can use it." Why does everyone assume that designers are stupid luddites who can't wrap their heads around complex systems? UI design is full of nuance and complexity. It's insulting to designers to assume they cannot deal with DVCS.
- silentbicycle 18y ago
  The issue isn't that designers are stupid, it's that, since they tend to have a better design sense (the good ones, at least!), they're generally less forgiving of ugly, needlessly hacked-together systems than people who spend most of their time immersed in them. Designers are often helpful for a reality check. People should listen to them more! (There is also nothing about DCVSs that necessitates a bad UI, of course.)
  - mechanical_fish 18y ago
    they're generally less forgiving of ugly, needlessly hacked-together systems... Huh? Am I the only one who finds Subversion to be very confusing, at the conceptual level, compared to git? All that file-by-file history tracking, just waiting to trip you up when you try to move a file around? The fact that branching in SVN is hopelessly entangled with the concept of copying directories around in some remote repository? Here's the canonical example from the SVN book: svn copy http://svn.example.com/repos/calc/trunk \ http://svn.example.com/repos/calc/branches/my-calc-branch \ -m "Creating a private branch of /calc/trunk." I guess I must be the only one who prefers: git clone git://github.com/mechfish/calc cd calc git branch my-calc-branch git checkout my-calc-branch # ... fiddle around, then when it's time to go back to master ... git checkout master # note: no need to cd anywhere I suppose that one downside of this is that all your coworkers don't get to automatically see the my-calc-branch on their centralized server. (How terrible it is that your every whim isn't being automatically published to the world!) Instead, when you want to push changes, you have to say something like this: git push origin my-calc-branch:refs/heads/my-calc-branch Or you have to set this up a bit in advance: git config branch.my-calc-branch.remote origin git config branch.my-calc-branch.merge refs/heads/my-calc-branch After which you can just do git checkout my-calc-branch git push Whenever you want to push up the changes to my-calc-branch. This sort of incantation is not great, but that doesn't mean it can't or won't be improved, and it's not that big a price to pay. The biggest problem with SVN is that getting started with it is so hard. As a git user, if I have a directory and I want it under version control, I do this: cd my-directory git init git add * git commit -m "Initial commit" Done. Put this in a droplet script and your great-grandpa could do it. (He'd have to read some blogs to figure out what to do next, but at least it's a start. And even if all he knew how to do was this: cd my-directory git commit -a -m "I committed today" and he did it every now and then, that would be great! Like a tiny, hidden, aperiodic, directory-specific version of Apple's Time Machine. His industrious great-granddaughter could use these snapshots to clean up after his PHP experiments...) As an SVN user, you need to find a hosted repository, get admin permission on it, set up the canonical directory structure -- being very careful to heed these words from the SVN book (you did read the SVN book, right?): While Subversion's flexibility allows you to lay out your repository in any way that you choose, we recommend that you create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies. ... and then import your project, being sure to get it imported into /trunk and not into /trunk's parent. Then you have to check it out -- being sure to check out /trunk, or at least to do all your work in /trunk, lest you screw yourself up or confuse yourself. So I assume that by "ugly, needlessly hacked-together systems" you mean "systems that make you use the command line". The only reason Subversion seems at all simple to non-geeks (to the extent that it does, which isn't much of an extent) is that the authors of tools like TortoiseSVN and Versions have sweated bucketloads of blood to design beautiful interfaces which hide all this cruft from the end users. DVCS will get there. Give it time.
scott_s 18y ago
The author sets up a false dichotomy: Subersion or git. But those are two different models of source control: centralized and distributed. If you want to use centralized source control, the choice is more likely to be cvs or Subversion. The popular notion isn't that Subversion sucks, but that it's pointless. The claim I hear is that it's a reinvention of cvs, but it doesn't actually improve much. Personally, I had to learn cvs, it's simple enough for my needs, and I see no reason to switch to something that's fundamentally the same thing. I think most cvs users are in a similar situation as me. We know Subversion is better, but those benefits seem marginal and not worth the effort to switch.
- ConradHex 18y ago
  Subversion, in my experience, is worth the effort of switching from cvs. It's a breeze to set up, and it's a lot cleaner than cvs.
  - mpk 18y ago
    I have a lot to say about version control, but I won't get into the details here. However, on the 'switch from CVS to SVN', I'll comment and say that SVN is far superior to CVS. The whole 'changes committed to the repo up the entire repo version' alone make this worthwhile. SVN is also less arcane in its usage. SVN has better tools for, well, everything. SVN integrates well with all major IDEs (mine being VIM, but also Monodevelop and Eclipse). The switch from CVS to SVN also made our releases much easier to manage (merging branches is fairly trivial and tagging is a no-brainer). If you're using CVS in a company, do yourself a favour and switch to SVN. The basic concepts are the same, so re-educating developers takes all of 5 minutes.
biohacker42 18y ago
This is a terrible argument. Easy when it comes at the cost of features is another way to say it's OK to be ignorant. It's one thing to make things as easy as they can be. It's one thing to not complicate things unnecessarily. But it's a whole'nother thing to make things easy at the cost of features and power. Anyone can make anything easy if they are allowed to cut enough features.
- silentbicycle 18y ago
  Is declining to use something significantly complicated by features you know you will never need ignorant?
mtoledo 18y ago
Curious, we use assembla on our team and our designer uses git (assembla's git) without any problems. It's great if people want to have the choice for subversion, tho. Some people just prefer the tools they are used to instead of learning new, more powerful ones. But to use that as argument that svn doesn't suck is not a very strong point.
- mtoledo 18y ago
  Though, when I showed him the article, he agreed with it.. so maybe he's right. :-D
mhartl 18y ago
Branching and merging suck in Subversion. Offline commits suck in Subversion. Does that mean Subversion sucks? Depends on whether you want good branching and merging and offline commits. I do; therefore, for me, Subversion sucks. QED.
- thorax 18y ago
  For what it's worth, they've improved branching and merging (on the backend) not long ago. Of course it's not inherent to the platform like most DVCS.
blasdel 18y ago
Subversion isn't even better than CVS across the board: it's slower, wastes a lot of space, is way less stable, and doesn't have independent implementations.
jonursenbach 18y ago
Here's an idea. Instead of throwing around "Subversion sux", "Git is the new hotness", how about we all just use what works for us and the projects we're working on.
- atlei 18y ago
  Agree ! Having gone from nothing to Subversion, I think Subversion is great (with TortoiseSVN, at least). Are there better tools ? Is Git better ? Maybe, but different tools for different uses. For me personally, Subversion does not suck, and I don't need a "better" tool. It works, and gets the job done for me !
- kingnothing 18y ago
  It's helpful for me to see these articles pop up since I don't currently use a revision control system such as subversion or git. Granted, I'm not looking for one at the moment, either, but it does plant seeds in the back of my mind for when I do need one.
globalrev 18y ago
All I know is is that Git i supereasy to use for a beginner for 1-man-projects if you get the right help or tutorial. Preferrably start a repo at github and you will be waled through how to create a repo(not that there is much to it). git init git add . git commit -m "blah" git push origin master git branch name git checkout easy-peasy
bayareaguy 18y ago
For the stuff I do I find both svn and git get the job done. The only thing that I regularly experience that sucks about svn compared to git is the speed of checking out a working copy. Even when using tiny local file:// repositories svn checkouts on my OSX laptop often take several seconds where similar git operations are instantaneous.

45 points by asinglenet 18y ago

tome 18y ago

In a world without Subversion, Subversion would be built out of Git. In a world without Git, Monotone, Darcs etc. ... well that's where we were 5 years ago, and it sucked.

axod 18y ago
Did it really suck? I was using subversion in a team of around 15, 5 years ago, and all in all it worked pretty well. It was rare that there would be any issue or that subversion got in the way. Maybe git is better... maybe it doesn't matter enough to bother changing. But you have to admit these types of things are more about what is "in fashion" than what is better suited to a particular task. Things go in big cycles. For a few years centralization is excellent, offers massive benefits, then suddenly distributed is excellent offers massive benefits etc etc As the post hinted, I wouldn't be surprised if 5 years from now git is pronounced as a terrible idea, and the trend setters go back to something more like svn.
- tome 18y ago
  It sucked because we didn't have the possibility of distributed version control, even if we really wanted it. Some people and some projects prefer centralized. That's fine. But you can't build a distributed version control system out of a centralized one.
  - kragen 18y ago
    svk? Also BitKeeper was built on SCCS, and ClearCase MultiSite was built on ClearCase.
- gcv 18y ago
  I'm very happy that Subversion works for you. For me, it just blew up on an update, which corrupted the fragile .svn directories it litters all over the working copy. "svn cleanup" couldn't repair the damage. This sort of thing happens on a regular basis. Git, on the other hand? No problems.
  - axod 18y ago
    "This sort of thing happens on a regular basis." Seriously? I don't remember ever seeing that, perhaps it's restricted to a certain O/S or version.
- jbjohns 18y ago
  The issue with SVN is simply the work flow it forces you into. I can't tell you how many times I've looked at someone's repo and see .bak files everywhere. I know right away why they're doing this because I did it myself when I used CVS/SVN. DVCS's let you branch off, experiment, and if it works out you can push everything into the main tree with the history included.
deleted 18y ago
[deleted]
tome 18y ago
I should perhaps clarify. "It" is having Subversion, CVS and no distributed VCS. I didn't mean "It" to refer to Subversion.

moonpolysoft 18y ago

"Even designers can use it." Why does everyone assume that designers are stupid luddites who can't wrap their heads around complex systems? UI design is full of nuance and complexity. It's insulting to designers to assume they cannot deal with DVCS.

silentbicycle 18y ago
The issue isn't that designers are stupid, it's that, since they tend to have a better design sense (the good ones, at least!), they're generally less forgiving of ugly, needlessly hacked-together systems than people who spend most of their time immersed in them. Designers are often helpful for a reality check. People should listen to them more! (There is also nothing about DCVSs that necessitates a bad UI, of course.)
- mechanical_fish 18y ago
  they're generally less forgiving of ugly, needlessly hacked-together systems... Huh? Am I the only one who finds Subversion to be very confusing, at the conceptual level, compared to git? All that file-by-file history tracking, just waiting to trip you up when you try to move a file around? The fact that branching in SVN is hopelessly entangled with the concept of copying directories around in some remote repository? Here's the canonical example from the SVN book: svn copy http://svn.example.com/repos/calc/trunk \ http://svn.example.com/repos/calc/branches/my-calc-branch \ -m "Creating a private branch of /calc/trunk." I guess I must be the only one who prefers: git clone git://github.com/mechfish/calc cd calc git branch my-calc-branch git checkout my-calc-branch # ... fiddle around, then when it's time to go back to master ... git checkout master # note: no need to cd anywhere I suppose that one downside of this is that all your coworkers don't get to automatically see the my-calc-branch on their centralized server. (How terrible it is that your every whim isn't being automatically published to the world!) Instead, when you want to push changes, you have to say something like this: git push origin my-calc-branch:refs/heads/my-calc-branch Or you have to set this up a bit in advance: git config branch.my-calc-branch.remote origin git config branch.my-calc-branch.merge refs/heads/my-calc-branch After which you can just do git checkout my-calc-branch git push Whenever you want to push up the changes to my-calc-branch. This sort of incantation is not great, but that doesn't mean it can't or won't be improved, and it's not that big a price to pay. The biggest problem with SVN is that getting started with it is so hard. As a git user, if I have a directory and I want it under version control, I do this: cd my-directory git init git add * git commit -m "Initial commit" Done. Put this in a droplet script and your great-grandpa could do it. (He'd have to read some blogs to figure out what to do next, but at least it's a start. And even if all he knew how to do was this: cd my-directory git commit -a -m "I committed today" and he did it every now and then, that would be great! Like a tiny, hidden, aperiodic, directory-specific version of Apple's Time Machine. His industrious great-granddaughter could use these snapshots to clean up after his PHP experiments...) As an SVN user, you need to find a hosted repository, get admin permission on it, set up the canonical directory structure -- being very careful to heed these words from the SVN book (you did read the SVN book, right?): While Subversion's flexibility allows you to lay out your repository in any way that you choose, we recommend that you create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies. ... and then import your project, being sure to get it imported into /trunk and not into /trunk's parent. Then you have to check it out -- being sure to check out /trunk, or at least to do all your work in /trunk, lest you screw yourself up or confuse yourself. So I assume that by "ugly, needlessly hacked-together systems" you mean "systems that make you use the command line". The only reason Subversion seems at all simple to non-geeks (to the extent that it does, which isn't much of an extent) is that the authors of tools like TortoiseSVN and Versions have sweated bucketloads of blood to design beautiful interfaces which hide all this cruft from the end users. DVCS will get there. Give it time.

scott_s 18y ago

The author sets up a false dichotomy: Subersion or git. But those are two different models of source control: centralized and distributed. If you want to use centralized source control, the choice is more likely to be cvs or Subversion. The popular notion isn't that Subversion sucks, but that it's pointless. The claim I hear is that it's a reinvention of cvs, but it doesn't actually improve much. Personally, I had to learn cvs, it's simple enough for my needs, and I see no reason to switch to something that's fundamentally the same thing. I think most cvs users are in a similar situation as me. We know Subversion is better, but those benefits seem marginal and not worth the effort to switch.

ConradHex 18y ago
Subversion, in my experience, is worth the effort of switching from cvs. It's a breeze to set up, and it's a lot cleaner than cvs.
- mpk 18y ago
  I have a lot to say about version control, but I won't get into the details here. However, on the 'switch from CVS to SVN', I'll comment and say that SVN is far superior to CVS. The whole 'changes committed to the repo up the entire repo version' alone make this worthwhile. SVN is also less arcane in its usage. SVN has better tools for, well, everything. SVN integrates well with all major IDEs (mine being VIM, but also Monodevelop and Eclipse). The switch from CVS to SVN also made our releases much easier to manage (merging branches is fairly trivial and tagging is a no-brainer). If you're using CVS in a company, do yourself a favour and switch to SVN. The basic concepts are the same, so re-educating developers takes all of 5 minutes.

biohacker42 18y ago

This is a terrible argument. Easy when it comes at the cost of features is another way to say it's OK to be ignorant. It's one thing to make things as easy as they can be. It's one thing to not complicate things unnecessarily. But it's a whole'nother thing to make things easy at the cost of features and power. Anyone can make anything easy if they are allowed to cut enough features.

silentbicycle 18y ago
Is declining to use something significantly complicated by features you know you will never need ignorant?

mtoledo 18y ago

Curious, we use assembla on our team and our designer uses git (assembla's git) without any problems. It's great if people want to have the choice for subversion, tho. Some people just prefer the tools they are used to instead of learning new, more powerful ones. But to use that as argument that svn doesn't suck is not a very strong point.

mtoledo 18y ago
Though, when I showed him the article, he agreed with it.. so maybe he's right. :-D

mhartl 18y ago

Branching and merging suck in Subversion. Offline commits suck in Subversion. Does that mean Subversion sucks? Depends on whether you want good branching and merging and offline commits. I do; therefore, for me, Subversion sucks. QED.

thorax 18y ago
For what it's worth, they've improved branching and merging (on the backend) not long ago. Of course it's not inherent to the platform like most DVCS.

blasdel 18y ago

Subversion isn't even better than CVS across the board: it's slower, wastes a lot of space, is way less stable, and doesn't have independent implementations.

jonursenbach 18y ago

Here's an idea. Instead of throwing around "Subversion sux", "Git is the new hotness", how about we all just use what works for us and the projects we're working on.

atlei 18y ago
Agree ! Having gone from nothing to Subversion, I think Subversion is great (with TortoiseSVN, at least). Are there better tools ? Is Git better ? Maybe, but different tools for different uses. For me personally, Subversion does not suck, and I don't need a "better" tool. It works, and gets the job done for me !
kingnothing 18y ago
It's helpful for me to see these articles pop up since I don't currently use a revision control system such as subversion or git. Granted, I'm not looking for one at the moment, either, but it does plant seeds in the back of my mind for when I do need one.

globalrev 18y ago

All I know is is that Git i supereasy to use for a beginner for 1-man-projects if you get the right help or tutorial. Preferrably start a repo at github and you will be waled through how to create a repo(not that there is much to it). git init git add . git commit -m "blah" git push origin master git branch name git checkout easy-peasy

bayareaguy 18y ago

For the stuff I do I find both svn and git get the job done. The only thing that I regularly experience that sucks about svn compared to git is the speed of checking out a working copy. Even when using tiny local file:// repositories svn checkouts on my OSX laptop often take several seconds where similar git operations are instantaneous.