httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <>
Subject Re: cvs commit: apache/src mod_rewrite.h Makefile.tmpl (fwd)
Date Tue, 19 Nov 1996 10:36:58 GMT (Dean Gaudet) writes:

> One problem is that unless you actually tag the affected files before a
> multi-file commit then rolling out isn't as trivial as you're implying.
> Given our apache-cvs mailing list at least there's a record of the
> revisions involved, so it's a matter of manually typing in all the cvs
> update -r commands by hand.  Just playing devil's advocate... I don't

True if you want to review a single commit but I bowed down to Rob on
that long ago and fixed the commit script to provide a diff. You can
also use a timestamp to get a cvs diff.

In any case, it's the time that the review takes place that's at issue
not really whether cvs can provide the diff. My comment about learning
cvs was more to do with how we try out new things more so than how to
actually get a diff in front of you for review.

> time to ensure stability.  I have successfully worked on projects larger
> than apache practicing the post-commit review methodology using cvs.

Me too. As I said, this is the first forum I've come across where such
draconian control is being proposed a cvs commit is sanctioned. Cvs can
do a number of things one of which is to allow rapid prototyping of
ideas and dissemination of working code. As long as the commit compiles
and doesn't cause the server to crash I'd consider it acceptable,
particularly early in the development process. During release cycles
then peer review should be used and I cut it fine with the satisfy
patch but I thought I was ahead of the deadline. During the
development stages though a strictly enforced peer review process is
stifling when you just want to try out an idea and see how it sits
with everyone. It's very difficult to do that without getting into the
main tree because otherwise you're continully updating you development
to catchup with a moving target and people can't be bothered trying
out your ideas because they end up with the same problem,
i.e. tracking your development diffs against a moving cvs target. If
you're doing development yourself then the whole thing falls down dead
since you have to maintain your own diffs outside of the current cvs
and you're just not going to bother fussing mergin someone elses diffs
in as well. We've been here before, please lets not go back.

Peer review *IS* important but let's not stop the src code moving
forward, if you don't like what someone's done then get them to change
it, it's so rare an event in practice that it would be silly to impose
stifling rules on everyone just to prevent the odd case.

Where I do think that discussion should preceed a commit is when a
fundamental change of direction is being proposed, like changing the
module api or something like that. Deciding on when that is required
is a judgement call and people certainly shout loud enough if you get
the call wrong so I don't see it's a big problem.

  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155

View raw message