I have read lately classic book "Producing Open Source Software. How to Run a Successful Free Software Project" by Karl Fogel (2005). Among others, author advocates using version control system as a basis for running a project. In "Choosing a Version Contol System" he writes: As of this writing, the version control system of choice in the free software world is the Concurrent Versions System or CVS. Further on much of examples of managing project and managing volunteers revolves around the idea of "commit access", and it is assumed implicitely that version control system is centralized. It is understandable, as in 2005 there were (according to Linus) no good distributed version control systems (SCMs). Also Karl Fogel writes in preface that much of material came from the five years of working with the Subversion project, and Subversion is centralized SCM meant as "better CVS" and used itself as revision control system; any experience described had to be with centralized SCM. The distributed SCM is mentioned in footnote in section "Comitters" in Chapter 8, Managing Volunteers: http://producingoss.com/producingoss.html#ftn.id284130 [22] Note that the commit access means something a bit different in decentralized version control systems, where anyone can set up a repository that is linked into the project, and give themselves commit access to that repository. Nevertheless, the concept of commit access still applies: "commit access" is shorthand for "the right to make changes to the code that will ship in the group's next release of the software." In centralized version control systems, this means having direct commit access; in decentralized ones, it means having one's changes pulled into the main distribution by default. It is the same idea either way; the mechanics by which it is realized are not terribly important. I'm interested in your experience with managing projects using distributed SCM, or even better first centralized then distributed SCM: is the above difference the only one? Linus has said that fully distributed SCM improves forkability: "Re: If merging that is really fast forwarding creates new commit" Message-ID: <Pine.LNX.4.64.0611070841580.3667@xxxxxxxxxxx> http://permalink.gmane.org/gmane.comp.version-control.git/31078 Time for some purely philosophical arguments on why it's wrong to have "special people" encoded in the tools: I think that "forking" is what keeps people honest. The _biggest_ downside with CVS is actually that a central repository gets so much _political_ clout, that it's effectively impossible to fork the project: the maintainers of a central repo have huge powers over everybody else, and it's practically impossible for anybody else to say "you're wrong, and I'll show how wrong you are by competing fairly and being better". According to "Producting Open Source Software" it is very important feature for an OSS project. See section "Forkability" of Chapter 4, Social and Political Infrastructure (beginning of chapter): http://producingoss.com/producingoss.html#forkability The indispensable ingredient that binds developers together on a free software project, and makes them willing to compromise when necessary, is the code's _forkability_: the ability of anyone to take a copy of the source code and use it to start a competing project, known as a fork. The paradoxical thing is that the _possibility_ of forks is usually a much greater force in free software projects than actual forks, which are very rare. Because a fork is bad for everyone (for reasons examined in detail in the section called "Forks" in Chapter 8, Managing Volunteers, http://producingoss.com/producingoss.html#forks), the more serious the threat of a fork becomes, the more willing people are to compromise to avoid it. Besides that, what are the differences between managing project using centralized SCM and one using distributed SCM? What is equivalent of committers, giving full and partial commit access, revoking commit access? How good support for tagging and branching influences creating code and build procedure? Is distributed SCM better geared towards "benovolent dictator" model than "consensus-based democracy" model, as described in OSSbook? Thanks in advance for all responses -- Jakub Narebski ShadeHawk on #git Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html