I offer an additional alternative to the current 'svnversion -n'
implementation of
<http://subversion.tigris.org/faq.html#version-value-in-source> that
requires feature enhancements to the Subversion system:
Define a $GlobalRevision$ keyword and a repo property (call it
'svn-global-revision-files') that allows a repo admin to list all files
with $GlobalRevision$ contained in them. Every client checkout/update will
force a svn client to check for all files listed in
'svn-global-revision-files' for $GlobalRevision$ and update said keyword
appropriately.
Under such a proposed solutions, most repo admins would set
svn-global-revision-files to list only one file (say a src/version.cpp
file) such that the subversion system need to do as little as possible to
update the "svn version source" files as little as possible.
This essentially does the same stuff that is done to keep .svn/entries up
to date...just applying it to the source as well.
The <http://subversion.tigris.org/faq.html#version-value-in-source>
solution stuff is just not very pretty for my system. eg, I prefer my make
output to be created a different directory then the stuff it reads from
(the source files/dirs). Without this, multiple makes (for multiple
platforms, apps, etc) can not run at one time--and yes this can happen a
lot for my systems, and I like to think we know what we are doing. Other
problems: I have to do with the error handling of creating and then
deleting the file, the side effects of a source file being created and not
deleting during a make error, wrong version numbers used when a rogue build
process happens (and yes, it happens), etc etc.
All in all, it's MUCH cleaner for me if I can force the
auto-version-value-in-source responsibility on the subversion system rather
then the make system.
-Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 26 04:16:06 2006