Erik,
Thanks but I had seen that FAQ and either it isn't appropriate or I don't
understand how to implement it in MS Visual Studio 2005 ;-(
In the example (for a GNU Makefile), it shows how to get the value in a C
program. Unfortunately, I need this value hard coded in the resource file
(that is why I put the defines as they were since Windows resource files can
include C Header files), so that the correct build information is included
in the executable (as seen by looking at the version in the program's
properties using right-click under Windows Explorer).
The FAQ also references SubWCRev.exe, just like I did, but that updates the
user's working copy which becomes out of step to the version in the
repository and requires everyone who updates the repository to do it on
their own working copy.
Much better is Subversion did it in the repository at every commit time.
If a commit can't send something back, I suppose the user could do an
immediate update following a commit. Can an update be limited to just one
file (version.h)? I am not sure I would be allowed to set up a
"post-commit" script on a SourceForge.net repository!
But then again, maybe I am missing something?
David
-----Original Message-----
From: Erik Huelsmann [mailto:ehuels@gmail.com]
Sent: 30 October 2006 23:20
To: DK
Cc: users@subversion.tigris.org
Subject: Re: Inserting revision numbers in source
> I would like to know if anyone has asked for this before and, if so,
> what the answer/solution was?
>
> I am a developer on a C++ project hosted on SourceForge.net, which
> uses Subversion as its repository. I would like the Subversion
> repository to mimic the antics of TortoiseSVN's program "SubWCRev.exe"
automatically.
Yes, even so often someone decided to write a FAQ about it:
http://subversion.tigris.org/faq.html#version-value-in-source
But, it's also hard to implement (efficiently), given mixed revision working
copies:
http://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in
-action.mixedrevs
> By this I mean that I would have two members in the source
> ("version.in" and
> "version.h") with "version.in" being (less my comments):
>
>
> #define FILEVER 3, 4, 0, $WCREV$
> #define PRODUCTVER 3, 4, 0, $WCREV$
> #define STRFILEVER "3, 4, 0, $WCREV$\0"
> #define STRPRODUCTVER "3, 4, 0, $WCREV$\0"
>
> What I would like is that when anyone commits anything to this
> project, Subversion copies "version.in" to "version.h" (overwriting it
> if it exists) whilst it substitutes the $WCREV$ (or differently named
> keyword to be distinct from TortoiseSVN's program) with the current
> revision number (if "version.in" is changed during the commit, then it
> would be copied after the change has been committed).
>
> During the commit process, the new "version.h" would be sent back to
> the user committing his/her change so that their working copy is
> identical to that stored in the repository.
Well, there's no such thing as 'send back to the user' in a commit process,
but it could be done in post-commit. However not without scanning the full
source tree, which comes at a (very large) cost (time)...
> This way "version.h" always has the current build number in it should
> anyone Checkout the project.
>
> This differs from the current $Rev$ keyword in that the whole field is
> replace by a numeric value rather than inserting the revision number
> after the "$Rev:" string i.e.:
>
>
> #define FILEVER 3, 4, 0, $Rev$:
>
> would become
>
>
> #define FILEVER 3, 4, 0, $Rev: nnnn$:
>
> which is not a valid C statement. This would not be a problem for
> future updates as the source file ("version.in") was not altered.
>
> It also differs from the SubWCRev program which would, in the process
> of updating "version.h" mark the directory as updated and hence now
> different from the repository.
>
> I would envision a different keyword associated with the "version.in"
> file in the Subversion repository - something like $Rev$ but meaning
> replacing the whole keyword string with the revision number and
> specifying the name of the file to be replaced (in my case "version.h").
>
> If anyone has an alternative solution, I would be grateful to hear.
>
> Thanks
>
> David.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 31 00:39:18 2006