[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Version-value-in-source alternative proposal

From: Matt England <mengland_at_mengland.net>
Date: 2006-01-26 04:14:40 CET

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.