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.
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.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
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.
Nerd rage is the funniest rage.
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.
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
Dewey, what part of this looks like authorities should be involved?