cvs commitinfo - remote access issues - enforced code beautification

[Austin Lauree]

I am trying to administer our cvs repository to ensure that all java
code commited runs through a 'beautification' process.

I setup a test system where CVSROOT/commitinfo contains:
ALL /scm/cvsscripts/commitscript

And /scm/cvsscripts/commitscript is a korn shell script that provides
me debug information (such as machine name and os, all arguments
passed through by cvs' commitinfo, and environment information) and,
for temporary testing, appends a line to all file arguments with the
extension .java.

I have discovered that:

If your CVSROOT is a local dir, using no remote access method, the
commitscript runs on your local machine against the files in your
working directory.  All is well, except for the fact that the
beautification executable I want to run doesn't have binary releases
for all the client platforms I support and the fact that most of my
developers access the repository through remote access methods (many
are in offices in other countries).

If your CVSROOT is a remote dir, using rsh/ssh/pserver access methods,
the commitscript runs on the cvs server (the repository host) against
temporary files that it copies from your working directory.  It does
NOT reflect the changes made to these temporary files in the client's
working files, but it does update the client's CVS/Entries file to
reflect that the commit has been accepted into the repository.  So you
end up with the 'beautified' code in the repository, cvs thinking you
have this updated code in your working area when you don't, and a big
bloody mess, no?

From the debug information I've set the commitscript to report to me,
I see no way through arguments or environment to detect that the
client is commiting through remote access and certainly not where
they're commiting from so that a forced update to the working area
could be performed post-commit.

Does anyone have a solution to this that I've overlooked in my
frustration?

Thanks,
-Lauree