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.
A DVCS can still be used to commit to a server.
The big difference is that a DVCS adds a local workspace. I can check something out from the centralized server(with a DVCS, I pull the server tree to my local tree), mess around, make a branch, see what it does, decide it was stupid and throw the whole thing away, or I can decide it was a good idea and then commit it to the centralized server(by pushing my tree up to the central tree). The only real difference is that a check out is called a pull and a commit is called a push.
Separating change management from committing to the repository is not necessarily a bad thing. It may be undesirable in many situations, but it can also be handy.
Nerd rage is the funniest rage.
I have worked with almost all of them. Some of them for extended periods of time with developers I sat next to in the office who committed to a central repository but also with distributed teams (distributed teams usually push changes frequently to a shared "central" repo, btw.) That includes Codeville, Git, Monotone, Darcs, and Mercurial. Really, they are all essentially the same and the differences are mostly in implementation and flexibility, especially WRT merge algorithms.
A few months ago I switched to git. Git seems like the winner - it's fast, modular, and many people are hacking on it and have written many cool tools (most of which are "built-in" git "commands.") However, its Windows support lags behind the other front-runner Mercurial. Darcs is mostly used by Haskell hackers, Monotone never seemed to really take off, and Codeville has died on the vine.
The good thing is you can switch because there are migration tools for almost every one and the histories tend to be isomorphic.
This probably should have been in the summary -- merge tracking is being added in 1.5, so bouncing changes from one branch to another is now easy. This is a huge feature, and something as I recall Linus specifically complained about in his talk.
http://blogs.open.collab.net/svn/2007/09/what-subversion.html
BTW, they did a really nice job of mapping out the use cases and whatnot before implementing the feature. I guess source control people are natural planners.
http://subversion.tigris.org/merge-tracking/requirements.html
Anyway, I'm sure the world will continue to have need for both distributed and client/server source control systems, and Subversion is a nice example of the latter.
I'm shocked you say this -- for years I've heard nothing but compliments about how readable, well organized, well documented, and stylistically consistent Subversion's codebase is. There's a whole HACKING guide that explains the styles -- both semantic and syntactic. It's something we're quite proud of.
.svn/ metadata centralized in one place, the way DVCS systems do. It will also likely make the "extra copy" of files be an optional thing, as many have asked. And svn 1.5 fixes the 'svn mv * foo/' wildcard expansion behavior.
:-)
.svn/ areas and extra cached copies of files was deliberate, and considered a feature. Just because we can't write 100 lines of code and "magically" make it behave in opposite ways doesn't mean it's a bad codebase. Even the *best* codebases are based on certain foundational assumptions -- some things are abstracted, some aren't. The things you complain about weren't switches we thought we'd ever need to flip, so we put the abstractions in other places.
As a matter of fact, a guy doing a demo at an Apple Developer conference once used the svn codebase as 'something big to compile' when demonstrating the XCode IDE. When we asked why he used svn, he said that it was "the only open source codebase he'd ever seen which compiles with no warnings."
If you have specific criticisms about the codebase, we'd like to hear. Instead, your post just seems to be about how your personal wish-list of features has never been added, and therefore "the codebase must be really bad." I'm not sensing any logic to this conclusion.
svn 1.6 is going to likely have
The fact is: we haven't added your pet features yet because we've been too busy working on other big fish, like FSFS, svnserve, locking, svnsync, SASL support, changelists, interactive conflict resolution, and oh yeah... automatic tracking of merges.
The working copy code was designed in a specific way -- the scattered