Hi On Thursday, 1 May 2007, Johannes Schindelin wrote: > On Mon, 30 Apr 2007, Jakub Narebski wrote: > >> Linus has said that fully distributed SCM improves forkability: >> >> [...] >> >> 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: [...] >> >> According to "Producting Open Source Software" it is very important >> feature for an OSS project. >> >> [...] >> >> 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. > > This is a lousy argument, IMHO. > > Why are forks bad? They are not. But if you "learnt" that merges are hard, > they are. > > It is a pity that so many people were trained in CVS, and keep thinking > some of the lectures were true, when they are no longer. > > Forks are good. In fact, we all "forked" with CVS as soon as we began > hacking. Everybody who claims to never have started over from a fresh > checkout, or from an "update -C"ed state, is probably lying, or a bad > developer. Thinking about it, I believe that the difference between > forking and branching is philosophical, not technical. You can always > merge a fork. IIRC Compiz and Beryl (fork of Compiz) plan to be merged. Both projects use git as SCM. We will see how this "merge a fork" will work. In "Producting Open Source Software" Karl Fogel gives an example of GCC/EGCS fork, which resulted in "fast forward" merge (EGCS which was fork of GCC, became next version of GCC). Similar example is XFree86/X.Org fork; Linux distributions went from packaging XFree86 to packaging X.Org. But for example GNU Emacs / XEmacs fork will never be merged, I think. So not always you can merge a fork - you can try, unless codebase diverged too much. >> Is distributed SCM better geared towards "benovolent dictator" >> model than "consensus-based democracy" model, as described in >> OSSbook? > > Not at all. I think the best example is kernel.org, where you find > tons of forks. IMHO it is really helping the benevolent dictator cave > into the consensus-based model, since forks can be preferred at any > time. Hey, even switching from one to another upstream is just a > git-pull away! What is or is not a fork is a bit blurry in the world of distributed version control systems. Is a clone of repository a fork? I think that everybody would agree that it is not. Is for example *-mm tree a fork? I'd say not. But I'd say that Beryl is a fork of Compiz... -- 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