Re: [PATCH updated]: How to be a kernel driver maintainer

[Linus Torvalds]

On Mon, 9 Jan 2006, Arjan van de Ven wrote:
> 
> > Obviously, they have to do their work, and their development on
> > something that isn't in Linus tree. If they are doing this work, they
> > need to make sure that when they diff for patches, that they merge
> > changes before diffing. The only way this is close to automatic is with
> > git. Any other method requires manually merging.
> 
> not correct. quilt is a very excellent counter example of that.

Yes. Anything that keeps a nice patch series that you can merge as a nice 
patch series works fine.

For example, Al Viro used to use (still uses?) RCS to maintain his 
work-in-progress. That worked fine, because he had a process where he 
would just extract them as patches.

The reason CVS doesn't work well is partly because CVS just sucks at so 
many levels, and because people start using it as more than a "series of 
patches" repository. People might cherry-pick one or two changes from a 
CVS, but it quickly becomes totally impossible to do anything sane at all, 
or even to cherry-pick more than a few patches, because after a while 
you've lost the ability to pick out individual changes.

Something like quilt works fine, because individual patches never get lost 
in other patches (they might get merged with another patch on purpose, but 
that's a separate issue). Anything that understands the notion of 
changesets and can be taught to re-order them should be able to work the 
same way.

So the important thing is to have _some_ proper linear changeset history, 
preferably one where you can re-order them (so that if you cherry-pick a 
set of changesets, you can mark them as having been merged, and keep the 
_rest_ as a linear changeset history).

CVS just sucks. End of story. It works badly at so many levels that it's 
just not even funny.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/