[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS 1.11 & modules file: Cederqvist bug?
From: |
Pascal Bourguignon |
Subject: |
Re: CVS 1.11 & modules file: Cederqvist bug? |
Date: |
Mon, 16 Jul 2001 03:41:49 +0200 (CEST) |
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------