I thought I'd post this here in case it proves useful to others. Here
is a random list of Things That Are True of the various *info files. It
is incomplete and in no significant order whatsoever. Version tested is
cvs 1.10 on Solaris, built from source.
1. when running in local mode, CVS runs in the actual source directory.
2. when running in rsh OR pserver mode, CVS runs in a directory named
/tmp/cvs-servXXX directory (where I assume /tmp is really $TMPDIR)
3. when running from commitinfo, args are as follows:
$CVSROOT/path/to/directory/where/file/being/committed/is
relativeFileBeingCommitted
4. when running from verifymsg, single arg is filename of log message
5. no args by default when running from loginfo
6. From taginfo documentation:
The "taginfo" file is used to control pre-tag checks.
The filter on the right is invoked with the following arguments:
$1 -- tagname
$2 -- operation "add" for tag, "mov" for tag -F, and "del" for tag
-d
$3 -- repository
$4-> file revision [file revision ...] (the one being tagged)
7. Looks like you can tell if something is being cvs removed because
the relevant line in CVS/Entries looks like this:
/theFile.txt/-1.56/the date goes here//
(note the minus sign).
8. Verifymsg scripts have no way at all of determining what directory
file is in
9. Loginfo scripts always get at least one argument IF the %{}
construct is
used, even if it's %{}. Components in the %{} are space-separated,
thus screwing up Windows. Code defensively. Additionally, it is
the case that
if you put *any* character into %{} other than sVv, it will be
expanded to the empty
string followed by a comma. For example:
Filter argument: %{xxx}
First and only argument to loginfo script (in quotes): "some
directory/here ,,,"
Filter argument: %{s}
First and only argument to loginfo script (in quotes): "some
directory/here theFile.txt"
(I think I have that right). So it looks like the first "component"
of the filter argument
is always the directory within the repository where the file whose
log message is being
captured resides. Unfortunately, it is space-delimited, which
screws you up.
10. Order of invocation per file on commit is:
commitinfo (abort on failure)
verifymsg (abort on failure)
<commit happens>
loginfo
11. commitinfo and verifymsg run by same parent pid; not so loginfo. So
a getppid() call
will return the same PID for commitinfo and verifymsg but will be
incremented by 3 when
loginfo is run. I don't know if the "3" is reliable or
timing-based.
Cheers,
Laird
