Slashdot Mirror
The Future of Subversion
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.
I run the IT systems for my small software company and frankly Subversion is a great tool for the job. I don't *want* a distributed VC system because I don't want the hassle of trying to ensure that everyone's modifications to the code tree are backed up correctly and stored safely somewhere. I want it in a central spot I can back up and manage without my employees having to worry about it.
:-)
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
--- Nick, hard at work
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.
... and is primarily focussed on kernel development. Some would even say it is the only thing he knows how to do. That is fine, but it does not make him an authority on version control systems for other types of projects. Kernel development has very specific needs, not mirrored by other projects. Personally I find SVN perfectly adequate for small teams, and not only for program source code, but also for texts.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You do realize that a distributed VCS can perfectly be used like a centralized VCS, don't you ? Declare any repository as the "central" one and decide that everybody should push/pull to/from it. That's their power: discributed VCS don't force you into a specific workflow, you choose how you want to use them.
Seems to me that most of the people promoting DVCS have used them and have seen the light. Once you use a DVCS on a project you don't want to go back to the bad old way of doing things.
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.
...getting all the other IT people in the office to use it. Even better? Getting them recognize why version control is so useful in the first place. :-D
-Rob
Biblical fiscal responsibility
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. If that directory was an independent piece, it should be in a separate repository since it's logically independent. If that directory is part of a larger whole, you shouldn't be allowed to work with just that one piece. (IMO) If I want to modify a 5GB webpage, why would I want to checkout unrelated pieces? And having every subpage in a separate repository would be counterproductive.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
As a programmer, what pisses me off most about subversion is... well just check out their codebase and look around a bit. Yeah, it works and it does 90% of what people want it to, but the code is a giant piece of shit. That svn has been developed as a total hack job and they seemingly have spent no effort over time trying to clean it up, as a programmer, offends me. I don't know how anybody can have confidence in svn when they can't even do simple changes to it.
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).
What I don't see mentioned very often, if at all, is the implicit assumption in distributed systems such as git, that a single person has ultimate integration responsibility and authority in order to form the official/mainline release. That is, given a single tree that is considered the main one from which all others ultimately derive (Linus' tree in the Linux case), there is absolutely no way for tools such as git to allow collaborative maintenance of that tree. In the end, the owner of that tree must perform all checkins to the tree, and must resolve all merge conflicts themself. This is a dual problem in that it wastes the time of a potentially talented developer (e.g. Linus) doing the mundane work of merging and integration, and the additional problem that if this mainline tree owner is not an expert in some particular area of the code, they are likely to make mistakes when resolving conflicts or performing other integration tasks.
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.
Cyrano de Maniac
I personally use Tortoise but the IDEs tend to not be change-aware unless I'm using the integrated tool.
Often wrong but never in doubt.
I am Jack9.
Everyone knows me.