[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs commitinfo - remote access issues - enforced code beautification

From: Greg A. Woods
Subject: Re: cvs commitinfo - remote access issues - enforced code beautification
Date: Wed, 20 Mar 2002 22:12:33 -0500 (EST)

[ On Wednesday, March 20, 2002 at 15:12:06 (-0800), Thomas S. Urban wrote: ]
> Subject: Re: cvs commitinfo - remote access issues - enforced code 
> beautification
> What do you mean by "can not really"?  I do some modification of
> committed files with a script called from commitinfo.

Hmmm.... but that can happen only on the server.  If you modify a file
unbeknownst to the user doing a commit from a remote client then you've
suddenly changed what he or she is committing without necessarily
telling them.

I'm not an expert in the CVS client/server protocol itself and I haven't
actually ever tried to do what you are doing in a client/server
environment, but as far as I can tell from the examples in the protocol
documentation remote clients will end up with an out-of-date file that,
although it has been marked as being up-to-date with respect to the
revision that is now in the repository, is different from the new
revision now checked into the RCS file in the repository (and thus
without removing the local file and then running "cvs update" again the
user won't see what was done to their file).  Note that the filename
passed to the commitinfo program is a _copy_ of the working file.  The
commitinfo program has no access back to the actual working file on
client host.

   The file names passed to the program do not refer to RCS files -- they       
   point to normal files, whose contents are exactly the same as the            
   working-copy files being committed. The only unusual aspect is that CVS      
   has them temporarily placed inside the repository, so they'll be available   
   to programs running on the machine where the repository is located.          

Commitinfo can be used to reject a commit, but it should not ever be
used to change a file, and especially not to then allow the changed file
to be committed.  Users change files and then commit their changes to a
change tracking tool.  The change tracking tool should not itself ever
make any changes.

Note also that the manual says (for good reason):

    Some sites require that the files pass a test suite.  Policies like
    this can be enforced using the commitinfo file, but you should think
    twice before you enforce such a convention.  By making the
    development environment too controlled it might become too
    regimented and thus counter-productive to the real goal, which is to
    get software written.

                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]