You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@gonzo.ben.algroup.co.uk> on 1996/03/18 07:58:07 UTC

cvs commit: apache/src CHANGES conf.h http_main.c mod_cgi.c mod_userdir.c (fwd)

Jim (and others),

Please don't commit several changes in one go. You should make each change
and then commit, it makes it much easier to review (and undo if need be).

Also, I don't know how you achieved the affect you did in the log file, but
it ain't right; firstly, the list of changed files shouldn't be there (or
perhaps it should but it isn't usually), secondly, lines of minuses are going
to cause confusion, since cvs also uses them to seperate sections in a log,
and thirdly, "Committing in apache/src" as a log message is completely
pointless.

Also, how come there's that huge list of "No revisions" at the end?

What exactly did you do to generate this commit message??

Also, on matters of style - changing #ifdef ... to #if defined(...) is not
needed, so why do it? And correcting spelling is fine, but only if it was
wrong in the first place. "Initialise" and "initialize" are both correct.

Oh yeah, one last criticism - detailed programming changes should not be noted
in CHANGES - only things which are likely to affect the end user.

Cheers,

Ben.

Forwarded message:
> From heap.ben.algroup.co.uk!arachnet-fw.algroup.co.uk!taz.hyperreal.com!hyperreal.com!owner-apache-cvs Mon Mar 18 01:25:43 1996
> Date: Sun, 17 Mar 1996 17:55:58 -0800
> From: Jim Jagielski <ji...@hyperreal.com>
> Message-Id: <19...@taz.hyperreal.com>
> To: apache-cvs@hyperreal.com
> Subject: cvs commit: apache/src CHANGES conf.h http_main.c mod_cgi.c mod_userdir.c
> Sender: owner-apache-cvs@hyperreal.com
> Precedence: bulk
> 
> jim         96/03/17 17:55:57
> 
>   Modified:    src       CHANGES conf.h http_main.c mod_cgi.c mod_userdir.c
>                          CHANGES conf.h http_main.c mod_cgi.c mod_userdir.c
>                         -----------------------------------------------------------------
>                         conf.h: Added FLOCK_SERIALIZED_ACCEPT to A/UX
>                         http_main.c: created FLOCK_SERIALIZED_ACCEPT for
>                         systems that need it,  but using fcntl() locking is
>                         expensive (esp. running NFS) mod_cgi.c: Cliff
>                         Skolnick's read_client_block check mod_userdir.c:
>                         If we hit the end of the UserDir list, and we
>                         haven't  found a file, return NOT_FOUND; we were
>                         returning OK before  with junk in the r->filename
>                         slot
>   Log:
>   Committing in apache/src
>   
>   Revision  Changes    Path
>   1.11      +11 -0     apache/src/CHANGES
>   
>   Index: CHANGES
>   ===================================================================
>   RCS file: /export/home/cvs/apache/src/CHANGES,v
>   retrieving revision 1.10
>   retrieving revision 1.11
>   diff -C3 -r1.10 -r1.11
>   *** CHANGES	1996/03/17 08:41:32	1.10
>   --- CHANGES	1996/03/18 01:55:35	1.11
>   ***************
>   *** 1,3 ****
>   --- 1,14 ----
>   +   *) Added FLOCK_SERIALIZED_ACCEPT for those systems, like A/UX,
>   +      that need mutex-capability but using fcntl-locking is
>   +      expensive. [Jim Jagielski]
>   + 
>   +   *) Fixed translate_userdir(): return NOT_FOUND when at the end
>   +      of the UserDir list (was returning OK and junk in the filename).
>   +      [Jim Jagielski]
>   + 
>   +   *) Added in Cliff Skolnick's read_client_block patch (check for
>   +      no reads and break) [Jim Jagielski]
>   + 
>       *) If there was no default MIME type defined, Apache sent Content-type:
>          without a newline, thus swallowing the next header. Changed to send no
>          Content-type: at all. [Ben Laurie]

[snip]

>   No                   revision
>   
>   
>   
>   

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.