I think that the server "writes back" the files to the client. Isn't this the way keywords are expanded on the client side once the checkin is through?
Shubho -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Greg A. Woods Sent: Thursday, March 21, 2002 8:43 AM To: Thomas S. Urban Cc: CVS-II Discussion Mailing List Subject: Re: cvs commitinfo - remote access issues - enforced code beautification [ 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. http://cvsbook.red-bean.com/cvsbook.html 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; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
