Christoph Heindl wrote:

...

As a side note, and I'm sure I'm opening a can of worms by even saying this... I find working on projects that do not use distributed source control to be really irritating nowadays.

Could you explain why? What kind of projects (organizational structure).

Well, the organizational structure of the project doesn't matter at all in my answer to the question. I will describe to you what I did with the Boost library in order to explain. I wanted to generate a whole ton of small random numbers quickly and found the smallint distribution. When I looked at the code, I was certain I could make something a lot faster that was very specific to my need, so I did, tested it and discovered that it was indeed much faster. Then I realized that by carefully using templates I could make it work for a much more general case. Now I want to make something that's a library module. I morph my special case into a more general case as a proof of concept. When that works, I then consider how to integrate the library module into Boost because that's where it belongs. There are lots of different versions of Boost that have been released and are installed on the various systems I work on. Not only that, but regardless of whether or not Boost ever accepts my changes I want to keep them locally so I will always be able to have a version of Boost with my changes. If I simply check out one of the tags for a version of Boost I have, I can certainly make my changes there, but I can never check them in or effectively track them against Boost itself as it moves forward. I could check out trunk, but trunk does not correspond to any version of Boost installed on my system and means I would be testing all kinds of changes that may or may not be ready for use. I'm not interested in being a Boost tester. And again, I really couldn't check my changes in or effectively integrate them with later versions of Boost. I eventually settle on doing an svn export of several successive versions of Boost and checking each into Mercurial. This is complicated by the need to undo Subversion's keyword replacement with a small perl script. And actually converting the Boost Subversion tree to Mercurial isn't very feasible because Subversion's idea of branching is so dissimilar. For example, there are a few cases of a tag being removed and replaced with a fresh copy of trunk, and this is very hard to model in any other source control system. Once I've done this conversion, things are pretty smooth. I can check in all my changes to my local Mercurial clone. I can play around with things, do code cleanup and various other things while still being able to track my source. I can also do development on my desktop and laptop and move changes smoothly between them even though the changes are checked in when the laptop may not be connected to the Internet. Later I discover Boost 1.44 has been released, so I repeat the process I used before to convert 1.44.0.beta1 and 1.44.0 to Mercurial revisions. Then I use Mercurial's merge feature to merge my changes back in. Poof, I have a version of Boost that has my changes, and I can publish a patch against Boost 1.44 as opposed to 1.43 if need be. If Boost had used a distributed version control system from the very beginning, that previous 6 paragraphs could've been condensed down to a couple of paragraphs. And future merges with Boost would generally be pretty trivial unless the random library changed significantly. This is true of any project I want to make a change to. I do not want to have to interact especially with the community for a one off change to a project I'm not really interested in becoming a regular contributor to. A centralized source system makes it hard to make changes except on active branches which frequently contain changes I'm not interested in testing. It makes it hard to track my changes locally regardless of the decisions of the community running the project. And it makes it hard to contribute a change back to the community when I don't want to become a full member, which in turn raises a barrier to entry to me being inexorably sucked into a community I didn't think I was going to participate in. All of these are regardless of the organizational structure of a project. They have everything to do with my ability to control and use the source code I download. Simply put, distributed source control is what fits the Open Source development model. I do not consider this an opinion so much as a flat statement of fact. The ability to fork is absolutely central to Open Source. It's harder to fork when you lose the history and ability to track changes against the original because a project's history and ability to track your changes to it is as important as a dump of the source code at a moment in time, if not more so. Distributed source control avoids these problems and makes forking easier, almost trivial. Distributed source control therefor fits the Open Source model better. In my opinion, distributed source control is the best fit for almost any development. But that's just my opinion, and I don't have nearly as much in the way of hard logical argument to back that up. I just know that I've used source control for nearly (and I'm rather embarassed that the word 'nearly' is there, but a 17 yr old in 1988 isn't likely to have heard of source control) as long as I've been a professional programmer. And distributed source control systems are the first source control systems I've used where I didn't feel like I was spending a lot of time fighting the source control system because it didn't work the way I needed it to. Discipline does not always require pain. -- A word is nothing more or less than the series of historical connotations given to it. That's HOW we derive meaning, and to claim that there is an arbitrary meaning of words above and beyond the way people use them is a blatant misunderstanding of the nature of language. -- Anonymous blogger -- Eric Hopper (hopper@omnifarious.org http://www.omnifarious.org/~hopper)--