The Future of Subversion 173
sciurus0 writes "As the open source version control system Subversion nears its 1.5 release, one of its developers asks, what is the project's future? On the one hand, the number of public Subversion DAV servers is still growing quadratically. On the other hand, open source developers are increasingly switching to distributed version control systems like Git and Mercurial. Is there still a need for centralized version control in some environments, or is Linus Torvalds right that all who use it are 'ugly and stupid'?" The comments on the blog post have high S/N.
Well *I'm* ugly and stupid... (Score:5, Insightful)
Basically Subversion is not suited for development with a diverse population of loosely connected individuals, each with their own private branches. Frankly, for corporate work, I don't understand why you would want the backup and integrity hassles of a distributed version control system. But maybe that's because I'm ugly and stupid
Re:Well *I'm* ugly and stupid... (Score:4, Insightful)
Re:Well *I'm* ugly and stupid... (Score:4, Insightful)
subversion is good for small projects, or larger projects with limited number of developers.
Once you get into the hundreds and thousands of developers working on the same project though you need to think a bit differently in terms of needs of the individual developer, and the group as a whole.
Re:Well *I'm* ugly and stupid... (Score:5, Insightful)
Correct me if I'm wrong, but isn't this the major selling point of distributed revision control? The idea being that since it is a distributed repository, everyone has a "backup" of someone else's repository (depending where they got their code from). No distributed copy is necessarily considered more important than another. However in a corporate environment I would imagine it works out quite well since there's an inherent hierarchy. Those "higher up" can pull changes from those "below". Those "higher" repositories you could (and probably should) backup.
As far as integrity goes I think one of the main goals of both Mecurial and Git was to protecting against corruption (using a SHA1 hash). You're much more likely to get corruption through CVS and SVN, which is awful considering it's in a central location.
Depends on the environment (Score:5, Insightful)
If you're in a highly-distributed development environment like Linux, where the developers are spread across multiple continents and have very little shared infrastructure and a high need to work independently of each other (either because of preference or because they don't want their work stalled by another undersea cable cut half a world away), then yes using a centralized VCS like Subversion is stupid. But if you're a developer on a project where all the developers are in a common location sharing common infrastructure, often literally within speaking distance of each other, then a decentralized VCS like Git is stupid. It's harder to maintain and, in that situation, yields none of the offsetting benefits.
Analogy: a fleet of Chevy vans vs. a freight train. The vans are far more flexible, they can travel any route needed whereas the freight train's limited to fixed tracks, and their smaller size and lower cost each let you buy a lot of them and dedicate each one to just a few deliveries in a particular area without a lot of overhead. You can fan the vans out all over the city, sending just what you need where it's needed and rerouting each one to adapt to changes without upsetting the others. But if your only delivery each day is 1000 tons of a single product from one warehouse to another 600 miles away, you're better off with that one big freight train.
Re:Well *I'm* ugly and stupid... (Score:5, Insightful)
By backup - I mean a tape or location where I know I can look to find the "good" copy that contains the official tree of code that represents what is going into my product. What you are describing is copies of repositories sitting in various locations that isn't really the same as a backup. It's also a bit upside-down - I don't want to be "pulling" fixes from engineers, I want engineers "pushing" fixes into a known-good integration environment.
By integrity - I mean ensuring that you have all of the fixes you want to have from everyone who should be making changes on a project. NOT file corruption.
Linus has a big mouth... (Score:5, Insightful)
Distributed VCS can be used like this (Score:4, Insightful)
Re:Distributed VCS can be used like this (Score:2, Insightful)
Yes, if you are disciplined about how you use it then I'm sure you can use it like any centralised VC. It is a tool - it is not evil - it just encourages what I see as risky behaviour in my particular environment. But I can fully understand that in other contexts it may be useful.
Re:Well *I'm* ugly and stupid... (Score:2, Insightful)
Look - it's a tool - you can use it responsibly or use it irresponsibly - with the right set of rules and processes I'm sure it can be made to work. Local checkins are what really get my goat
Re:Well *I'm* ugly and stupid... (Score:5, Insightful)
In a distributed environment usually there's someone's (or a group's) repository that's considered more important than others. In a software setting this could be a Lead Engineer's/QA/Certification's repository. Depending on what your definition of the "good" repository is, you would take the copy from the right place. It opens up in terms of flexibility what code you actually want to get to work with. The upcoming released version of your software from QA, the next-generation stuff that developers are working on, or maybe a new feature that you here so-and-so is working on...
But you have someone who needs to approve a change to a central repository that everyone shares. Right? That person would probably want to examine those changes before they're committed. The only difference between distributed and centralized, in this case, is that it's a required step. Everyone is responsible for their own repository.
I'm no expert on distributed revision control, so anyone please feel free to correct me.
Re:Distributed VCS can be used like this (Score:3, Insightful)
Huh ? If you don't push to the main repo, nobody sees your commits. Don't you think this is sufficient to remember DVCS users they need to push regularly ?
Re:Linus has a big mouth... (Score:4, Insightful)
He's an excellent assembly hacker, a fast learner, and at least a majority of the time a nice guy, so most people overlook it.
Don't knock it till you try it (Score:5, Insightful)
Most of the people knocking DVCS or saying they can't see the benefits haven't actually used them on any projects. They have built up a framework in their minds of How Things Should Work, but unfortunately that model was defined by the limitations of their tools.
Re:Well *I'm* ugly and stupid... (Score:1, Insightful)
no, that's the WORST thing about it in a corporate environment. See, if I've paid you $5000 a month to write software, I don't mind it written on a laptop on the beach as long as you check it into the central repository. I seriously do mind if you write it on your laptop on the beach, check it in to your local repository and then get your laptop stolen (or covered in margeritas). This is such a deal-breaker that I would say 'no beach coding' to all developers and make them sit in cubicles instead. Now if they could check code into the central, secure, backed-up repository then I'm fine with whereever they want to code.
Now branching... that's another story and is possibly why this article should be talking about the differences between MS Team Foundation System and Clearcase.
My goal regarding the future of Subversion... (Score:4, Insightful)
Re:Git vs Subversion (Score:5, Insightful)
To commit a change to the Linux kernel, you do need to build the whole thing. That's a monolothic thing.
To commit a change to a webpage, a graphical project, a set of biochem data, you don't need that. Do you need to check out the countless megs of Wesnoth to update your changes to a campaign? That's a modular thing.
Re:Git vs Subversion (Score:2, Insightful)
They've been working for years to do simple things like just updating their folder structure so it doesn't leave ".svn" folders everywhere. Or just providing an option to not store a second copy of your 2 gig repository just so you can do restore to Head (and that's all) without asking the svn server which is probably over in the closet on the gigabit ethernet anyway. They can't do this with their current code... it's so bad that they are trying to scrap the local store code entirely.
... and then there are the even simpler things like why tf can't I say "svn mv *.[ch] newfolder/" or any of the other commands that you have to use shell scripting to accomplish? That kind of thing should be simple. There are a lot of these kinds of problems in svn that never gets fixed (despite having a guy at google that is apparently paid to hack on svn).
Re:Distributed VCS can be used like this (Score:5, Insightful)
How do you force your cvs/svn users to commit ? You can't, you expect them to be responsible and do it. This isn't much different from a DVCS.
What if a user wants his work to be backed up but doesn't want to commit because his changes are not ready to be published ? A centralized VCS forces them to commit with the side-effect of making their unfinished work immediately visible in the central repo, while a DVCS lets them commit to a private repo that you can back up independently.
Your backup requirements can be solved 2 different ways:
Besides, in this debate, you are completely ignoring the other major advantages of DVCS over centralized ones: scalability, no single point of failure, possibility to work offline and have full access to all of the features of your VCS, usually faster than centralized VCS, low-cost branching/merging, etc.
Code integration assumptions (Score:4, Insightful)
Contrast this with a centralized source model where all developers have the ability to check in to the tree, optionally coupled with a peer review process, enforced either through convention or through mechanisms in the tools. Under this model each developer is responsible for their own integration and merging efforts, not wasting the time of a centralized authority. Not only is the central authority freed from routine tree maintenance work, but each developer can make the best and wisest decisions regarding the particular area of the codebase in which they are an expert, and not have to become involved in areas they have little experience with. Granted, for larger projects there is still a need for some management of checkin authorization, particularly to avoid conflicts during large tree merge operations and the like, but it's more of a coordination role than an authorization role.
This second model is what my employer uses, and our homegrown source control system is well-tailored to it (it actually has capabilities for more centralized control, but they are by and large unused). Perhaps this is unusual, as my experience with other employers is minimal, and mostly took the form of "copy your code into this directory once in a while" (i.e. "Source control? Why would we need that?"). However, given adequately diligent and intelligent developers, I have to say it works marvelously.
Re:we use SVN (Score:3, Insightful)
Re:Code integration assumptions (Score:3, Insightful)