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 ...
[ message continues ]

Hi,


Back then, it was. I ran all my projects on CVS. Then came along Git. I 
tried to keep up with it, but had to quit for day-job reasons. When I came 

In my experience, the offline mode has been a huge advantage. For example, 
in one project I work together with people from three different countries, 
some of them traveling quite a bit. I sold Git solely on the 
transportability. One of them was so happy that he switched over most of 
his projects, too.

BTW that is the common way I see: once people get hooked, they not only 
convert their existing projects to Git, but they use cvsimport a lot more, 
and they start to manage configuration settings, documents, pictures, etc. 
with Git, because it gives rise an easy backup mechanism.

Another difference between central and distributed operation I see is the 
workflow. With Git, you can commit much more often. For example, when 
working with Sourceforge's CVS (which _was_ comparable with the speed of 
corporate SourceSafe repos), I would always think about committing (and 
having a coffee), or rather combine these changes with the next ones.

Obviously, committing more often leads to a much nicer repository 
structure, making it much easier to get into the code for new developers. 
It also makes it easier to get at bugs. And because it is so much faster, 
you can actually do a "git diff" before committing, to make sure that you 

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 ...
[ message continues ]

There's a confusion going on here between a "fork" meaning a branch in
the SCM sense of the word, and a "Project Fork" where there are two
camps competing for developers and users.  So for example, having
kerenl developers develop using branches which are then merged into
the -mm tree and then into Linus tree --- Good.  In the
suspend-to-disk world, where we have *three* separate implementations,
with two in the mainline tree, and one very popular one, suspend2,
with features that niether of the in-mainline implementations have,
and with Pavel constantly casting aspersions at Nigel because he's
splitting the development effort --- Not So Good.

I prefer to use the term "branch" to talk about a SCM and development
series, and to use the term "fork" to talk about the political/project
issues.  So for example, even though Ingo Molnar's CONFIG_PREEMPT_RT
patchset has been a very long-running thing, it is constantly getting
rebased against the kernel, and there is no expectation that this
would replace the mainline kernel.  That makes a code branch, and not
a fork.

So my suggestion is to let branches be branches, and to reserve fork
for when there is an attempt to compete for developer and user
attention.  That is more or less the general understanding of the two
terms, and trying to confuse the two only leads to confusion and a
general muddying of the waters.

Regards,

					- Ted
-

[ message continues ]

Hi,


So you agree! I said that it is a philosophical, and not a technical 

But why! Because Pavel is just ignoring reality. I always wondered why the 
work of Nigel was never considered for inclusion, even if it was clearly 
superiour from a usability view point.

And if it is usable, but not clean, then clean it up. Instead, Pavel seems 
to never even have considering casting his planet sized ego aside and 
admit that his work is just not up to par with Nigel's, and start to 
clean up suspend2.

So in that case, I am even _more_ happy that forking is so easy, because I 
did not _have_ to suffer all that much from people who cannot enter my 
flat because their head does not fit through the door, but I could just 
happily use suspend2 and be fine.

BTW the same goes for Reiser4, which is quite fast and flexible, and I do 

I refuse to get involved in such a sophistic (not to be confused with 
sophisticated) discussion.

I am _only_ interested in the technical side. Philosophical discussions, 
while fun when not taken too seriously, _can_ take all the fun out for me 
when the participants get too religious about their beliefs. So please, 
keep me out of them.

Ciao,
Dscho

-

[ message continues ]

Hi


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

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
-

[ message continues ]

The egcs fork was a total disaster, and a big part of that was CVS and the 
tight control of the gcc tree. 

It took _years_ for people to get so fed up with the gcc maintenance that 
the egcs tree happened at all, and it was a prime example of how *painful* 
CVS makes this, and how it allowed the gcc maintainers to do a really bad 
job, and ignore a whole lot of major problems simply because the whole gcc 
setup was so hard to get into.

So yes, the egcs fork is a great example. It was not only a required (and 
very good) fork, but it is _also_ an example of a setup where all the 
infrastructure made the fork take a lot longer to materialize and be a lot 

In all honesty, I don't think any tools would help there. Git can make 
merging easier, but it cannot solve the fundamental differences in 
personality and it can't help with ten years of differences. Git tries to 
make merging easy by making it happen all the time, and thus the git 
merge capability really depend on changing the *model*. But git cannot 
really help you all that much if you have a decade of split, and the 
codebases just don't look similar any more..

(Not entirely true: git obviously does make merging easier, since people 
have piped up to say that they imported branches from SVN just to merge 
them in git and push the result back to SVN. So git _does_ help on the 
pure technical side too, but I think the even more important part is how 
git tries to encourage the model to be that one or both sides just merge 

Well, the -mm tree is a fork, but perhaps the difference is that the 
_intention_ is to merge back.

We've had "real forks" in the kernel community too. Vendor branches for a 
while tended to be real forks - not because the vendors didn't want to 
merge back, but simply because they didn't have the capability and 
commitment to do so. That's changed, partly because 2.4->2.6 was so 
painful for some of them.

And the VM people have had real forks. The -aa tree wasa real fork in the 
2.4.x ...
[ message continues ]

Well, I actually personally suspect that the original Linux method of 
"patches + tar-balls" is a perfectly valid method of source control 
management, and in many ways preferable over CVS.

So no, I don't think using a version control system should be the _basis_ 
of running a project. Version control comes pretty far down the list, long 
long after "good taste" and "willingness to do things rather than talk 
about them", the latter of which tends to kill more hypothetical projects 
than even CVS has ever done.

The _basis_ of an open source project is a good manager, a good idea, and 
a realization that what matters most is _using_ the end result, rather 
than the idea or discussions or "cool features".

The SCM becomes relevant only once you are far enough along that tar-balls 
and patches really don't work, and that might well take years.

[ I'm really serious: I think a lot of the good practices that the kernel 
  project has gotten is exactly because of the "patches rule" mentality. 

  We now use real revision control, but I really *really* believe that 
  pushing patches around is a much better way of managing stuff than with 
  CVS or any other centralized model, because in the centralized model it 
  always ends up being about the "core team". In contrast, even if there 
  is a core team, if they just push patches around and discuss them as 
  such, non-core-team members are automatically basically all equal.

  And avoiding the politics, and avoiding the "five people are special" 
  mentality is a *lot* more important than the limited and broken tracking 
  capabilities that CVS brings to the table.

  So maybe I'm just in denial, but I really believe that the fact that the 
  kernel was basically maintained _without_ an SCM for a decade was 

Karl Fogel is wrong. 

It's an understandable mistake to do, since commit access is so important 
in a centralized environment, and he probably has never used anything else 
(even decentralized SCM's are often ...
[ message continues ]

Actually Karl Fogel wrote in "Producting Open Source Software" that he
recommends and uses 'soft' partial commit access; it means that committing
is restricted to a part of project for some by a guideline, but is not
enforced by the tool (by SCM).

P.S. I recommend actually reading the book (at http://producingoss.com)
instead of relying on my understanding of it.

-- 
Jakub Narebski
ShadeHawk on #git
Poland
-

[ message continues ]

Oh, absolutely. Except that really does require a lot of trust up front, 
which is the problem with commit access to begin with - you automatically 
have a very clear (and *big*) difference between insiders and outsiders, 
and there is no "gradual" way to move from one to the other.

So yes, for practical reasons, "commit access" really is almost always an 
all-or-nothing thing for most centralized setups, because nothing else 
really works. And when it isn't, it's just a horrible horrible pain in the 
*ss.

What people do instead of commit access is to set up triggers to notify 
people about certain subsystems being modified. Which is a good idea, but 

It actually looks like a fine book, even though I think Karl is totally 
off in not seeing the big difference between centralized and distributed. 

I saw it at the local Borders, and considered buying it. I didn't even 
realize that it apparently is downloadable too.

And it talks about a lot of other things than just SCM's.

			Linus
-

[ message continues ]