Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Future of Subversion

Posted by kdawson on from the had-a-good-run dept.

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.

7 of 173 comments (clear)

  1. Well *I'm* ugly and stupid... by Wulfstan · · Score: 5, Insightful

    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 :->
    1. Re:Well *I'm* ugly and stupid... by EricR86 · · Score: 5, Insightful

      Frankly, for corporate work, I don't understand why you would want the backup and integrity hassles of a distributed version control system.

      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.

    2. Re:Well *I'm* ugly and stupid... by Wulfstan · · Score: 5, Insightful

      I'm using the terms backup and integrity in slightly different ways than you are.

      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.

      --
      --- Nick, hard at work :->
    3. Re:Well *I'm* ugly and stupid... by EricR86 · · Score: 5, Insightful

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

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

      I don't want to be "pulling" fixes from engineers, I want engineers "pushing" fixes into a known-good integration environment.

      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.

      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 Again, in a centralized system, someone has to have the responsibility that all "fixes" have been made which isn't much different from a distributed model. And technically anyone is free to make changes to a project locally on their own machine. They just have to notify the "higher" person saying "Hey I've got a fix for so-and-so", and in a controlled manner they can decide whether or not to accept the changes into their own repository.

      I'm no expert on distributed revision control, so anyone please feel free to correct me.

  2. Linus has a big mouth... by gweihir · · Score: 5, Insightful

    ... 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.
  3. Don't knock it till you try it by burris · · Score: 5, Insightful

    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.

  4. Re:Distributed VCS can be used like this by this+great+guy · · 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:

    • 1. With any VCS (centralized or distributed), put the users' working directories on private NFS/Samba shares. This way everybody's work, committed or not, is on the file server which can be backed up.
    • 2. Use a DVCS. The users' private repos and working directories can remain on fast local storage on their workstations. A file server contains the main repo as well as private spaces that can be used by the users to periodically push to private repos, so they can be backed up without interfering with the main repo.

    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.