You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by DK <dk...@dsl.pipex.com> on 2006/10/30 22:47:51 UTC
Inserting revision numbers in source
Hi,
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.
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.
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.
Re: Inserting revision numbers in source
Posted by Matt Sickler <cr...@gmail.com>.
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
>
>
RE: Inserting revision numbers in source
Posted by Kyle George <kg...@tcpsoft.com>.
On Mon, 30 Oct 2006, DK wrote:
> 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).
You can generate version.h as part of your makefile with a little
scripting using either SubWCRev or sed and svnversion or both. It looks
like you're already doing this. Make (even MSVS make) should be smart
enough to know it needs to regenerate the resource and your executable if
the include file changes.
In my use, I have templates for files (like your version.in) that I
autogen at build time.
> 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.
Distributed working copies are "out of step" by design. This is how
copy-modify-merge works. Just because User A commits a change to the
repository doesn't necessarily mean that users B C and D want those
changes right away. In the subversion model, you can't (nor should you)
push a change out to every working copy of your repository.
More importantly, with the possibility of mixed revision working copies
and/or local modifications, any version information in your exe header
isn't necessarily a guarantee that it was built with a pristine copy of
rXXXX. It's up to you to have a build/release policy that enforces
non-mixed update revision, non-locally modified working copies before
doing a build to insure that the version information is in fact accurate.
Ultimately, the point of including the revision number in the exe is to be
able to go back to exactly what was used to compile it at some point in
the future.
> Much better is Subversion did it in the repository at every commit time.
IMHO, make or a build script can do it better. Doesn't Visual Studio have
pre-build commands it can run? That might be a good place for something
like this on windows.
--
Kyle George
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Inserting revision numbers in source
Posted by DK <dk...@dsl.pipex.com>.
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
Re: Inserting revision numbers in source
Posted by Erik Huelsmann <eh...@gmail.com>.
> 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