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.

Git vs Subversion

[KiloByte]

While Git obviously has its strong sides, often quite overwhelming, there are cases when it sucks compared to SVN:
1. timestamps. Subversion doesn't do that by default, but it has good enough metadata support than timestamps can be hacked in easily. For Git, metastore is nearly worthless. If you store a program source, you risk just skewed builds -- for other types of data, lack of timestamps is often a deal breaker.
2. move tracking: trying to move a directory branch from one dir to another means you lose history. Rename tracking works only sometimes, often it will take a random file from somewhere else, etc.
3. large files. Take a 100MB binary file into SVN, change one byte, commit. Change one byte again. And again. Git will waste the freaking 100MB for every single commit.
4. partial checkouts. If there's a 5GB repository, you'll often want to check out just a single dir. With Git, there is no such option.
5. ease of use. I see that ordinary users, web monkeys and so on can learn SVN easily; with Git, even I had some troubles initially.

On the other hand, SVN used to have no merge tracking (I wonder what that "limited merge tracking" in 1.5 means...) which for distributed development of program sources is worse than points 1..5 together.

Re:Well *I'm* ugly and stupid...

[Anonymous Coward]

There's no reason you can't have a central "official" repository that everyone "pushes" their changes to. In fact, I bet most "corporate" users of DVCS do exactly this. You also get all the other benefits of DVCS that Subversion doesn't do or doesn't do well.

You shouldn't knock things you obviously don't know much about.

Re:Well *I'm* ugly and stupid...

[maxume]

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.

Re:Distributed VCS can be used like this

[Wulfstan]

"Valuable changes" doesn't only mean changes which are destined for HEAD or the equivalent. "Valuable changes" in my opinion is anything and everything that you are doing on a codebase.

I take your point - if you are responsible in how you use DVCS then I can see that it can be made to work. But in my environment I want all of the changes being made (however offensive or broken) to be centrally auditable and not stashed away in some private repository.

Re:Well *I'm* ugly and stupid...

[Anonymous Coward]

In distributed implementations in the past that I've been responsible for, the tool (in my case BitKeeper) allows a "push clone" where a developer can create a clone of their local workspace onto a remote system, in this case a common server.

That server was regularly backed up (daily deltas) with weekly off-site tape rotation.

The worst-case loss in the event of a total failure of a single computer is one developer's local changeset(s), but that's the exact same risk when working with a centralized system as well. A developer's uncommitted work can always be lost if precautions aren't taken.

Re:Well *I'm* ugly and stupid...

[burris]

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.

Well if you're an MSDN developer...

[IgLou]

If you are one of those MSDN shops where you went to subversion because VSS is weak, you can go with Team System. We were using VSS before and Team system is way better for version control plus it has defect tracking and a build agent. Also, they have caching server to aid distributed environments. Considering it's free (sort of) with your MSDN license (I think it's with their "team edition" licenses) it's tough to beat. It's tough to beat that, especially for larger shops. The only things I don't like in some ways is how it represents the branching and the source control permissions and that was comparatively minor problems. I work in Config Management/Build and so I don't know what Joe developer would like/dislike about it.

If you're not an MSDN shop then what to use is more problematic. I really liked subversion but that was years back. From what I recall for what it was it does well. The only product I was ever "wow'ed" with was Accurev. That product deals with branching like a breeze and I think they might have a defect tracking module now.

Re:Well *I'm* ugly and stupid...

[maxume]

Right, but with server only commits, people wanting to do experiments may not bother doing any version management if they don't want to hassle with creating a branch to hold the work. Cultural problems come up in both situations.

helloooo merge tracking

[icknay]

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 [collab.net]

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 [tigris.org]

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.

Re:SVN's weaknesses

[Just Some Guy]

The build manager can't merge the changes without those changes taking on his identity, that is, all identifying information about the originator of the changes is lost.

Since I'm sure you're not talking about what svn blame gives you, what do you mean exactly?

That is, it's not recommended to build one branch and merge changes from the trunk into it as you're incrementally changing things on that branch, noooo.

Umm, says who? Thanks exactly what we do. We have /trunk and /branches/devel. When one of us gets a particularly stable version of /branches/devel ready, we merge it to /trunk.

You have to keep polluting the repository with needless hair by making new branches every week, and sometimes, multiple ones per day.

Have to? No way. But since branches are basically free, why would you want to avoid them?

We use them for experimental "what-if" branches, like "I wonder what would happen if I ported our application from MySQL to SQLite". You copy "/branches/devel" to "/branches/sqlite" and hack away. If it works, merge your changes back to devel. If it bombs, just delete the branch./P

Re:Well *I'm* ugly and stupid...

[plague3106]

Well, it sounds like the concept of shelving; a kind of partial commit that only you can see, and if you like, can later make public. I don't believe you need distributed SC for that; there's nothing inherient that requires a local server running. I believe MS' Team Foundation Server already supports this. http://msdn.microsoft.com/en-us/library/ms181283(VS.80).aspx [microsoft.com]

Maybe it's not the same thing though. To me, the key difference would be running your own private SC server locally to handle the feature vs. not having any local server but the central server knows to "hide" it. At least that's how I would think a distributed source control system would work.

Re:I happen to need a centralized version ...

[Todd Knarr]

All version-control systems do that. It's not optional: you have to have meta-information about the checked-out files available, and there's no place in the files themselves to put that information. Now, you might want to look at the distinction between a working directory (with all the tracking files present, allowing the developer to check in and out, compare with different revisions in the tree, all the normal things) and an exported tree (created using for example the CVS "export" command, contains only the source files with none of the meta-data present (which means you can't check modifications of it back in)). My normal working method is to have a working directory for actual development, then once I've got everything checked in make an export tree if I need to package the source code up for builds.

Re:Distributed VCS can be used like this

[Chemisor]

> What worries me is that it encourages behaviour which leaves valuable changes sitting
> on a disk which may not be backed up. I see changes being made to a codebase like valuable
> little bits of gold which need to be kept somewhere nice and safe

As a developer, I'll tell you that not all changes are "little bits of gold". Sometimes I just want to try something out, and end up with little bits of crap. The way to think about local changes is the same way you think about non-committed changes to your Subversion repository. In Subversion, I will have plenty of changes sitting on my disk, they just won't be committed until I am satisfied with them. In git, I can commit as many times as I like to my local repository and push only the final version to the central branch. This way I can checkpoint my code with intermediate commits. This is extremely valuable, since those checkpoints might not even work at all, and I would never want them to break the main build, but I can still break up my task into little subtasks and redo or revise each one of them in turn. These subtasks are not backed up in your scenario either, and are much harder to manager there.

Re:we use SVN

[CastrTroy]

On IDE Integration

I use Visual Studio with SVN at work, and while it doesn't have IDE integration (AnkSVN sucked last time I tried), which would be optimal, I find that using TortoiseSVN to be pretty adequate, if not better than IDE intergration in a lot of ways (Don't have to open the IDE to do an update on your local copy). I think the thing that makes both IDE integration and TortoiseSVN great is to be able to use a nice GUI to manage you checkins and updates. I mean, the command line works, but this is one area where having a nice GUI can really help.

Re:we use SVN

[eddy]

> SVN is currently integrated with our IDEs (all 3), one of the main selling points in choosing a VCS.

Where I work we all use the cmdline, so IDE integration is a complete non-issue in selecting a SCM for some teams.

> IT loves being able to simply tgz the SVN directory

Pretty sure that's not the correct way to backup a Subversion repo, unless by 'simply' you mean that you first hot-backup.py the repo and then tar it up.

Re:we use SVN

[Anonymous Coward]

IT loves being able to simply tgz the SVN directory

If that's literally what they are doing, and they do it without shutting down access to the repository, then its being done wrong (what if someone commits during backup, for example). Hot backups are trivial in SVN, though (see repository dumping). FYI ;-)

Re:Git vs Subversion

[slipsuss]

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.

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

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

Re:Well *I'm* ugly and stupid...

[stoborrobots]

meanwhile, if you're using SVN on Unix/Linux boxes, you might want to check out svk [bestpractical.com]. All the advantages of a DVCS, but with the central repo being a (possibly pre-existing) standard svn server.

(I put the disclaimer about unix boxes in because the last time I had a colleague on a Mac running SVK, there were some minor issues around binary files and line ending munging... I don't know if they are resolved already or not...)