Ian Bicking: the old part of his blog

Re: Distributed vs. Centralized Version Control

Well - centralized version control is a subset of distributed version control, since you can still upload (or "push") stuff from your branches to the project's central server. What distributed version control adds is the voluntarity of this action, and freedom to fork the project independently while keeping the history and the possibility to merge back in the future easily. (And some other bonuses like ability to work offline.)

So the question is whether this kind freedom is a good thing. For the forking issue, if you want to fork, you will do that anyway and I doubt you will care that much about how hard would that be. But at least you will retain the full history, and it will be possible to easily merge the projects back later, which I'd say makes the situation at least somewhat better than with centralized VCS.

The "voluntary publication" is probably less clear-cut, but I think it's better this way as well. How does this stuff usually go? If you are new developer, you decide "I need this thing to do X" or "this Y thing is bothering me". So you can either:

The bottom line is, I argue that the additional freedom distributed VCS gives you is a good thing and actually significantly lowers the barrier for new hacks by making it easier to do them and potentially reducing the bureaucracy.

Comment on Distributed vs. Centralized Version Control
by Petr Baudis

Comments:

Petr, it's what happens after you've worked on your modification in private and you decide to publish it to the world that's the interesting question.

You can make a patch and post it to Bugzilla, or you can publish your repo on your own server where the maintainers can pull from. Bugzilla isn't as attractive as some kind of anonymous micro-branch, which after all is basically what your patch is. Publishing your own repo is not stable over time. In reality, patches often wait many months for integration, and private repos are likely to move or go down, and you still have the problem of tracking the links to all the private repos.

It seems that the problem with turning anonymous patches into anonymous branches is that svn can't merge between repos (e.g. main and pending-patches), and people are uncomfortable adding anon branches to the main svn repo. Right?

# Stephen

Well, I argue that centralized version control systems ain't any better than decentralized ones here. You can make server-side anonymous branch with sensible decentralized VCSes - at least git and monotone can do that, I'm not that familiar with the others; but you can always just have parallel repositories at the server.

So this is NOT a problem with distributed VCSes.

# Petr Baudis

So the question is whether this kind freedom is a good thing. For the forking issue, if you want to fork, you will do that anyway and I doubt you will care that much about how hard would that be. But at least you will retain the full history
As of subversion 1.4.0 and its client/server support for "svnsync", you can indeed replicate a repository with nothing more than anonymous read access. Prior to 1.4.0, there were hacks to accomplish more or less the same thing, and you could always use rsync if you had shell access to the server.
and it will be possible to easily merge the projects back later, which I'd say makes the situation at least somewhat better than with centralized VCS.
That part of the problem, subversion does not solve.
# Peter Samuelson