On 5/29/07, Doug Kirk
OTOH, I work for companies, and they really value their assets, especially software assets. So they *want* centralized stuff, so they can ensure they have consistent backups (in the U.S.A. there is a lot of regulation under Sarbanes-Oxley that requires this stuff). Right now we're using ClearCase, which I abhor because it's so heavyweight...but it is centralized control.
Interestingly, using a decentralized version control does not rule out the possibility of centralized control and development. For example, darcs itself has a very centralized development even though the tool allows decentralization. The advantage is that people working on, for example, a feature branch can easily share patches via cherry picking. When the feature branch is ready to be merged darcs handles this in a way superior to svn[1] by doing the merge almost completely transparently. We're currently developing a feature branch at work under svn and every merge is a book keeping headache and at least one day of lost development time. In this respect, svn seems primitive, tedious and error-prone. Just check the svn red bean book for details on merging in svn. We have learned you need to manually track version numbers so you don't merge things twice. Perhaps my argument is more about svn vs. darcs, but those are the two version control systems I know best. [1] I will happily concede that darcs is not currently perfect in it's automated merging, especially in the case of conflicting patches. Just ask the ghc developers if this is a problem for them. But, that is also why there is a summer of code project this year to fix the problem. With a fair bit of retooling, darcs will handle this case better in the future and I'm confident this will become a problem of the past. Jason