However:
- not everybody uses it. At work, we force people to use it by mailing
out the commit messages to an internal newsgroup, so everybody sees
when a commit doesn't have a good message. Without that kind of
pressure to write the message, the messages tend to be fairly bad, at
least as far as I have seen.
We are anal about it on the Vger tree.
- the commit messages go into a big black hole, and never come back. You
_can_ get at them, but you certainly don't get them easily, and you
_definitely_ don't get them when you try to make a combination patch.
Not true, if you know how to set up a CVS repository correctly, I have
things hacked up on vger so this _DOES_ happen. For all types of
large combo patches etc, you can get the commit messages in there any
way you like.
It is non-trivial to get _only_ the changes that correspond to a certain
series of commits, and to leave out the changes that everybody else have
been doing. At least I haven't found anything to do anything like that.
In short, CVS is not _nearly_ good enough. Sorry,
Ted T'so uses the technique on some of his tree's of creating a branch
which is where most people play around, ever week or couple of weeks,
a merge process is done by the people who have write access to the
main line.
I don't know how well it would work for us.
Anyways, I've also been maintaining a 2.0.x stable branch on the tree
actively and it seems to work rather well. And some people who use
vger create their own branches when they aren't totally confident
about their changes, then after testing they merge their stuff into
the main line and remove thier "temporary" branch.
The EGCS folks have run into some issues with branching, and worked
them out from what I can tell, maybe we can get some tips from them.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu