Re: CVS 1.11 & modules file: Cederqvist bug?

[Pascal Bourguignon]

Absolutely correct. I've signaled this problem last month. 

Note however that I think that the  right thing to do is to ALWAYS run
the triggered programs  on the server side. Then  it's doing the right
thing, and it's only a problem with the documentation.


> From: Steve James <address@hidden>
> Date: Sun, 15 Jul 2001 22:37:23 +0100
> 
> Hi folks,
> 
> I want to run a client-side script on update (pserver). Fine, according to 
> the Cederqvist, I can do this using the '-u' option in the 'modules' file. 
> Unfortunately (for me) the script I specify is run on the *server* not the 
> client. Can anyone else corroborate this please? Depending on how you look at 
> it, this is either a bug in CVS or the document. I anticipate the latter. 
> Comments?
> 
> Cheers,
> Steve.
> 
> -- background:- --
> Below is the relevant line in my modules file. To simplify things, the script 
> is actually just 'ls'
> 
>       ste/test -u ls ste/test 
> 
> Here's the output from 'cvs up' on the client (pserver)
> 
>       cvs server: Updating .
>       cvs server: Executing ''ls' '/home/cvs/root/ste/test''
>       README,v
>       test.c,v
> 
> The first two lines are a bit of a hint that the script is going to run on 
> the server -- it says it's doing just that. The last two lines are adequate 
> proof that it's done so, since I can see the repository's files.
> 
> Here's what I presume to be the bug in the doc (this is in the node "Module 
> program options"):-
> 
> The commit and update programs are locally-based, and are run as
> follows:-
>  
>    The program is always run locally. One must re-checkout the tree one
> is using if these options are updated in the modules administrative
> file. The file CVS/Checkin.prog contains the value of the option `-i'
> set in the modules file, and similarly for the file CVS/Update.prog and
> `-u'. The program is always executed from the top level of the
> checked-out copy on the client. Again, the program is first searched
> for in the checked-out copy and then using the path.
> 
> Perhaps this was correct for an older version of CVS?
> I'm using CVS pserver & doc  1.11.1p1 on Linux, Win95 client 1.11.
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
> 
> 


------------------------------------------------------------------------
From: Pascal Bourguignon <address@hidden>
To: address@hidden
Subject: Error in the doc C.1.6
Message-Id: <address@hidden>
Date: Sat,  9 Jun 2001 23:42:56 +0200 (CEST)


http://cvshome.org/docs/manual/cvs_18.html#SEC161

The section 'C.1.6 How the modules file "program options" programs are
run' is wrong. It says that:

     The commit and update programs  are locally-based, and are run as
     follows:-
         The program is always run locally.

which is plain false. At least,  when I access the cvs repository thru
ssh with :ext:, the commit and update programs are run on the server:



address@hidden test1]$ cvs commit -m update
Checking in wang;
/cvs/test1/wang,v  <--  wang
new revision: 1.12; previous revision: 1.11
done
cvs server: Executing ''/scripts/commited' '/cvs/test1''
^^^^^^^^^^               

address@hidden test1]$ cvs update
cvs server: Updating .
cvs server: Executing ''/scripts/updated' '/cvs/test1''
^^^^^^^^^^


I think  that the  right thing to  do is  to ALWAYS run  the triggered
programs  on  the  server  side.  Well, when  there  is  no  transport
(CVSROOT=/dir), then the local side  and the server side are the same,
but conceptually, they  should be run on the server  side even in that
case.

They are aready when the :ext: transport is used. I've not tested with
other  transports. The documentation  should be  updated to  match the
implementation which is correct.



In addition,  the handling  of these triggers  should be  improved for
recursive processing. Right now, when we check out the top level:

     cvs checkout .

only the scripts  that are specified for the top  level module (.) are
run, not the scripts that may  be specified for each the modules. (The
files Checkin.prog and Update.prog are  not checked out). I think that
it's not right.

On  the other  hand, if  the trigger  are all  and always  server side
based, there's  not need to  checkout any Checkin.prog  or Update.prog
file...




-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------