[cvsnt] Re: Commitinfo trigger script data?

[John Kinson]

Thanks Tony.  This really needs documenting though, as any organisation 
wishing to apply a process model to CVSnt will need to know how to 
access this information.

This is what I've learned empirically (please correct me if I'm wrong):

- commitinfo is invoked for each directory present in a commit (contrary 
to the implication of your comment below).

- the current working directory for the commitinfo and verifymsg trigger 
scripts is indeed the temporary directory containing the tree of files 
being committed in a pseudo-sandbox.  I say pseudo as you can't of 
course run CVS commands from these trigger scripts.

- The CVS/Entries file in the temporary sandbox can be used to obtain 
information about the files being committed.  Each line in the file has 
5 fields with the following format:

	/<filename>/<old rev>/<old timestamp>/?/T<sticky tag>

<old timestamp> is in GMT (UTC?).  Not sure what's in the fourth field, 
it's always been empty in my experiments.  <old rev> is 0 for new files, 
negative for removed files (with the absolute value equal to the 
revision removed), and positive for modified files.

- The CVS/Repository file gives the full (local, server-side) pathname 
of the corresponding repository directory.

- The new revision number for a file, if needed in a trigger script, can 
be predicted by looking up the branch tag in the repository ,v file as 
necessary (won't go into it here, but it seems straightforward enough).

I've not considered what happens when files are renamed though, so this 
information may need to be revised accordingly.

With regard to the official CVSnt documentation:

- http://www.cvsnt.org/manual/commit-files.html neglects to mention that 
verifymsg can also abort a commit by returning a non-zero exit status 
(but commitinfo explicitly states this.)

- The comments within the verifymsg and commitinfo files, and the HTML 
manual pages, really need extending to cover the above information.

> loginfo is better for this kind of thing though as that's called for 
> each directory.

No, loginfo is too late - the files have already been committed by then, 
and the return code is ignored anyway.

Cheers

JK
-- 
http://www.yellowradio.com/

If technology doesn't seem like magic,
it's probably obsolete.