Ian Bicking: the old part of his blog

Re: Centralized vs. Decentralized 2

I'll be really original, and suggest that what this really means is that you need to check out _my_ favorite system ;-)

In this case, Monotone. The interesting point relative to your post is that monotone, from some points of view, is quite close to what you describe. Most of the distributed VCSes have branches thare are not just distributed, but scattered -- each meaningful branch lives in a particular location, these meaningful locations can be on different hosts, you have to know which host each branch lives on and be able to connect to it, etc.

In monotone, OTOH, no repository is more equal than any other one; the basic network operation is just "send them the facts I know but they don't, get fetch the facts that they know that I don't" -- so one way to think of it is as a centralized VCS where that center is made a little more diffuse. You can still commit while on an airplane, and it becomes completely trivial to do things like set up load-balancing hot-backup repos, if your server goes down anyone can step in for it, etc., but in the usual case everything is in the same place. Think of it less "no-one knows what's going on", more "no central point of failure, many more 9s of robustness than achievable by any other method".

New developers generally cannot push to a project's main server, because of exactly the sort of issues you mention -- we'd really rather not become the next big warez distribution network -- but they can push to their own server, and if a developer pulls from that server the changes will end up in the central server the next time they sync. Apparently this sort of thing is called a "gossip network", and has some rather nice properties this way. Of course, this is a really high-level hand-wavy description...

(It also, uh, contrary to comments on the last post, has never used OpenSSL's libraries, and has supported tag and branch based checkout for eons. No local tags, though, hadn't encountered that idea before. Interesting idea.)

I think you were missing the point just a bit in the last post; the advantages of DVCSes aren't so much "oo, distributedness!" as lots and lots of things like this -- increased robustness, better merging, workflow improvements (no update-before-commit requirement, for instance; frees one from the tyranny of the cowboy who keeps breaking mainline), cooperation across organizational and trust boundaries, that sort of thing. Distribution is one nice feature, but hardly defines a VCS by itself; the particular issues you listed are real ones, but not necessarily the relevant ones.

DVCSes _do_ also make it possible and even easy to fork. There are people who want to make it hard to fork. (I don't know if you're one of them.) I can understand where they're coming from, but I do outright disagree with the position; forking is an important freedom, and I honestly think it's wrong for tools to try and enforce otherwise. OTOH, this certainly doesn't mean they should make it easy to accidentally drift out of sync and neglect to inform other contributors of work ongoing...

Comment on Centralized vs. Decentralized 2
by Nathaniel Smith

Comments:

"It also, uh, contrary to comments on the last post, has never used OpenSSL's libraries, and has supported tag and branch based checkout for eons"

My bad. Sorry. :(

# Chad Walstrom

Don't forget that distributed systems make it easier to recover from a fork. It's just a merge, after all.

I don't think they have any effect on how easy it is to fork in the first place; tools like cvsps and tailor make it trivial to pull history out of one repository and into another.

# Bryan O'Sullivan