I dont know C (or variants) but on Perl POE development team we use
something like this:
$REVISION = sprintf "%d", ("$Revision: 203 $"=~/(\d+)/);
I am not sure how you could do that in C, but I would think that it would
work.
On 10/30/06, DK <dk@dsl.pipex.com> wrote:
>
> 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 01:01:39 2006