followup question to FAQ

This is from the FAQ:

> Why doesn't the $Revision$ keyword do what I want? It expands to the
> file's last-changed revision, but I want something that will expand
> to the file's current revision.

The answer, in summary, is that every check-in would then have to check
every file in the repository to update the $Revision$ (and other)
keywords. The suggested workaround is to add a step to the build
process to update a file with the version info from svnversion or using
SubWCRev from TortoiseSVN.

I would like to put the current version into a file in my project,
however, I do not have a build process as it is an interpretted
language -- users check it out using subversion and they run it.
So if I'm going to automate the process, it has to be within
subversion. I would like to automatically update this file with
the version information at some point in either the commit or in
the update/checkout/export processes. I like the keyword mechanism,
and given the problems with a $CurrentRevision$ type of keyword
(as described above), staying with it would require getting subversion
to commit the file every time so that it gets updated. However, the
only mechanism that I've seen thus far (I'm new to subversion) of
customizing the commit process is that of the commit hook scripts.
But I don't think that these will do it: start-commit does not have
access to the working copy to touch the file (mark as modified, in
whatever fashion), pre-commit doesn't allow changes to the transaction,
and post-commit is too late (unless one works around by immediately
checking out the file, touching it, and commiting it; I think this
could be done via a script, but leaves two commit actions for every
actual commit performed -- not very clean). Is there a way to force
a commit of a particular file for every commit transaction? Are there
any ways to customize the update, checkout, and export actions? Is
there some other way to do what I'd like to do that I've completely
overlooked?

---
Jonathan Entner
jonathan.entner@jhuapl.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org