Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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.