httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: CVS
Date Tue, 13 Feb 1996 13:24:38 GMT
> > 
> > Do we have any URLs or info that state,
> >   a) this is what you need
> You don't need anything to use it on hyperreal which is what I'd suggest
> for now.
> >   b) this is where you get it
> Umm, hyperreal. Ben's probably got a better idea of the individual bits 
> you need and what to do. It's all in FreeBSD by default so I've never had
> to chase up all the bits you need to install it on a clean system. BSDI
> had most of what I needed too, all I did was upgrade from an older cvs
> to 1.7.
> Off the top of my head you need cvs, rcs, patch and diff. Install them
> in reverse order.

Dean posted a correct (IMHO) list earlier of versions. A small warning for
those not familiar with GNU; diff comes as part of diffutils. I usually compile
the diffutils with a "g" prefix (i.e. you get gdiff, gdiff3 etc.) to avoid any
flag conflicts with OS distribution versions. CVS autodetects this variation
during configuration.

Another warning; put /usr/local/bin (or wherever you install this stuff)
_first_ in your PATH - almost every OS breaks CVS one way or another -
hyperreal has CVS 1.3 to bite you, SCO distribute a version of patch so ancient
it won't tell me the version number, and so on...

> >   c) this is what it does
> I'll repost that tutorial I have separately. Umm You might want to read it
> this time :-)
> There's also pretty good documentation in the cvs sources.

Heh! Good, but altogether too extensive. And it made my head spin.

> >   d) this is how we'll use it
> That's up to us.

It is, but we should write it down. Most users of CVS need know little more
than how to check out and in, how to resolve conflicts, and perhaps how to tag,
if we introduce a tagging policy.

A small guide on the commands we actually use, with tags in the format we
use, etc., would be of great value. This guide should also include the "rules".

I would also propose that there be a "guest" login on hyperreal which has
readonly access to the repository, for people who don't have CVS write access.

> > Now, I personally think that the voting system has *some* merit.
> > Is there anything in the proposed cvs scheme to stop, say me, from
> > introducing some awful pile of crap that everyone else has to try
> > to deal with and/or fix?
> > 
> > It'd be useful to only allow new changes to be made if two or three
> > other people think its a good idea.. no long drawn out patch votes,
> > just a simple system whereby someone suggests a change but must wait
> > for 2 (3?) others to say "okay let's give it a try".
> FreeBSD has a peer review system which I explained about before (and it's
> implemented in the code I've installed on hyperreal. It's voluntary, there's
> no way to enforce that people adhere to it but there's a Reviewed: by line
> in the commit message where you are supposed to list the people that have
> peer reviewed your changes. If that field is blank then you can see that no-one
> besides the committer has given a look over. 
> The procedure would be to send a patch to a couple of people for review then
> when they say it's OK, commit it. We only use this in FreeBSD in certain
> situations
> 1) You're committing changes to an area that is really the expertise of
>    someone else but you have some neat ideas that you think would help so
>    you get the "expert" for that area to look them over.
> 2) You are the expert but you think that the changes are a bit off the wall
>    and think that other people should take a look first rather than get
>    yourself flamed after the fact.
> There's a general point I'd make here. This project is growing rapidly and
> suffering from the growing pains that such projects do but the original
> developers have to loosen the reigns a little and actually trust other people
> besides themselves to work on the code. If you don't think someone is
> technically competent to make these judgement calls themselves then don't
> give them the keys to the door. Peer review is then implicit in the fact that
> their patches have to go into cvs via someone who is deemed technically
> competent. We're suffering from growth already, with 20 or 30 people having
> to review patches before they get the OK and the large numbers of patches
> that are now arriving, things are going to grind to a halt if some trust
> of other people's abilities isn't exercised.
> The "voluntary" review procedure works well in FreeBSD but relies
> on the ability of individuals to understand things well enough to know when
> changes are so trivial they should just go in without bothering people and
> when things may need some further input from other team members.
> There are controls on all this. People who continually skip the peer review
> and commit bad code lose cvs access. When occasionally someone commits code
> with good intentions and that code turns out to be ill conceived it can
> be backed out. This is the control that cvs gives you over the source. As
> long as it's not a daily occurence backing out code is not a problem.
> > Also, how does CVS resolve style conflicts?. Say I create
> > a new config variable called FooBar and I think it's the best name since
> > sliced bread, but someone else thinks BarFoo is much better, so changes
> > the name without asking me. We could end up flipping from one name
> > to another as fast as CVS would allow (in theory :-)... again some
> > peer-review is needed to stop arguments before they happen.
> Well, Apache needs a style guide for general code layout and "standards" for
> variable naming and so forth so it's easy to understand. cvs does nothing
> to enforce this other than making it simple enough to check out someone's
> patch and re-style it. There have been situations where a couple of people
> have got into petty fights of continutally changing each other's code for
> rather irrelevant reasons. The usual result is that one or the other
> gets kicked out of the cvs team.
> cvs is not a project management tool, there will still be a need for a
> "management team" to resolve conflicts. At the moment that team is this
> list.
> Some of this may seem like a straigh-jacket after the rather loose coding
> policies we've had in the past and the "right" of anyone to submit patches
> but that wasn't a problem when there were 10 of us and most of the code
> was written by one or two people. Project management is now an issue. cvs is
> one tool that will help (there are others too such as gnats and sup) the
> mechanics of maintaining the code but running the project now requires a more
> formal footing. Setting out a style guide is one important step, agreeing on
> procedures for getting access to cvs is another and establishing a review
> procedure that maintains the quality of the code without bogging us down
> in something like the voting procedure.
> I appreciate your concerns but their best addressed by thinking about how
> the project is to be managed rather than worrying about the impact cvs will
> have. Moving to cvs will bring nothing but improvements.
> As a first step I'd suggest that Ben, myself and whoever else feels they know
> how to use cvs start getting the main branch up to date by submitting the
> patches *individually* as separate commits. I prefer that path since it gives
> us a separate revision for each submitted patch making it easier to back out
> and also giving a log of what each patch does. You'll also be able to get
> the actual patch back by doing a diff between revisions.

OK, but we can't all apply the patches ... someone has to be nominated. I'll
do it, if noone else wants to, but it may be a few days - I shouldn't really
be taking the time out for this email even...

Also, there's such a _mass_ of patches for 1.0.2 that I'd be inclined to wait
until the current vote is over, then we can at least only put in patches which
are still candidates (or have already passed).

> I'd particularly like those people who've stated they have cvs experience
> from other projects to get stuck in and start using it for Apache work since
> I won't have to teach you the basic cvs commands and hopefully when those
> with less experience see how it actually works in practice they'll  be
> motivated to get to grips with it themselves.
> Note to Ben and others who already have access:  
> Don't commit anything to the 1.0.1 branch, put all the patches on the head.  The
> way that will work is that everything gets put on the head since patches for
> 1.0.1 have to go into 1.1 too.  You pull over patches from the head into 1.0.1
> if it's agreed they're suitable patches for the "stable" branch.  For the moment
> I'll probably do that myself as and when people ask for that to happen.  Let's
> not worry about stable for the moment and just get the development process up to
> speed.

Ah, I see. Isn't this kind of backwards from the usual use of the vendor
branch? Or is 1.0.1 not strictly a vendor branch?

Anyway, I get the picture. To summarize, the head will always be the latest
version plus all patches to date (that haven't been summarily vetoed). Voting
will take place as before on the changes from the previous release, the
approved patches will be merged across into the "release" branch, and then we
start again. What happens to unapproved patches? I think we'll have to
introduce a two-part vote, i.e. "this patch is vetoed for the next release, but
can stay in the development stream" as opposed to "this patch is vetoed from
both the release and the development stream".



Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant        Fax:   +44 (181) 994 6472
and Technical Director      Email:
A.L. Digital Ltd,           URL:
London, England.

View raw message