You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Leyendecker, Robert" <Ro...@lsi.com> on 2009/12/08 19:43:17 UTC
Any simple way to set/get global revision number?
Say I have a c file called version.h and in this file is a macro to build a version string using $HeadURL$ and $Revision$. When a user runs the program this information is printed into the log file to help isolate problems to specific versions that change on daily basis.
Is there a way to set a property so that this version.h file is automatically checked out whenever an update is made to the directory even if the version.h file is not touched? Or conversely, is there a way to have it automatically checked in as a changed file whenever a commit is done on any other file in the directory?
I'm trying to avoid having to manually run/maintain external scripts or programs like svnversion to scrape/touch/alter version files and force changes since the src files may be ported to different systems and I want the svn info embedded into a single version file.
Am I out of luck for an easy solution?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428310
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Any simple way to set/get global revision number?
Posted by BRM <bm...@yahoo.com>.
It depends on the platform you are using. If you are using TSVN then there is a program (SubWCRev I think) that can do things like you want.
But as far as I am aware it is not official SVN functionality, and likely never will be since (to my understanding) the SVN devs don't want client-side scripting; though a number of SVN clients do support it (like TSVN).
What you want to do, however, is best left for your build tools to do. If you need multi-platform support that is a bit harder; but still possible, especially with tools like CMake, which can help you with this kind of scripting functionality - but I'd leave that to the CMake folks (cmake.org) and their mailing lists for how to do it.
HTH,
Ben
________________________________
From: "Leyendecker, Robert" <Ro...@lsi.com>
To: users@subversion.tigris.org
Sent: Tue, December 8, 2009 2:43:17 PM
Subject: Any simple way to set/get global revision number?
Say I have a c file called version.h and in this file is a macro to build a version string using $HeadURL$ and $Revision$. When a user runs the program this information is printed into the log file to help isolate problems to specific versions that change
on daily basis.
Is there a way to set a property so that this version.h file is automatically checked out whenever an update is made to the directory even if the version.h file is not touched? Or conversely, is there a way to have it automatically checked in as a changed
file whenever a commit is done on any other file in the directory?
I’m trying to avoid having to manually run/maintain external scripts or programs like svnversion to scrape/touch/alter version files and force changes since the src files may be ported to different systems and I want the svn info embedded into a single
version file.
Am I out of luck for an easy solution?
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428317
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by "Leyendecker, Robert" <Ro...@lsi.com>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2009d@ryandesign.com]
> Sent: Wednesday, December 09, 2009 5:50 PM
> To: Leyendecker, Robert
> Cc: Daniel Becroft; Thomas Harold; users@subversion.tigris.org
> Subject: Re: Any simple way to set/get global revision number?
>
>
> On Dec 9, 2009, at 17:27, Leyendecker, Robert wrote:
>
> > Yes - after I sent this I realized that I would get dinged about
> mixed revisions, local mods, etc. However, putting this detail in a
> version string is also problem even with a rat's nest of client side
> scripting. For the feature I am proposing where I have modified or
> corrupted the directory, maybe "M" or "Dirty" some other indication
> with a version number would be appropriate since subversion
> automatically knows this when I update the directory.
>
> You could use the same format svnversion uses, even if you don't use
> svnversion to get the information, since the developers of that tool
> already spent time thinking about a good format to use.
>
>
> > You are correct - I would like anyone (not just me) to be able to
> checkout/update code give it to someone without depending on scripts
> and subversion and without the subversion directory structure and have
> an atomic version number automatically embedded that makes sense for
> the "directory" and not just the file. If the working directory doesn't
> have modifications/conflicts etc, then I think it is reasonable to want
> to have the atomic version number at time of last commit for the
> updated files that I have manually pre-linked to version.h (or vice
> versa). I don't think going back to older revisions breaks this idea,
> but haven't fully thought it through. I also fully acknowledging it may
> not be an easy thing to implement in the subversion design.
>
> You could write a "make tarball" script which creates a tarball of all
> your source, after updating version.h with the revision number. Then
> you would only require that the machine on which you run that script
> has Subversion installed.
>
>
> > But the "global" (wish I had more accurate term) version issue
> doesn't seem impossible to resolve in a more satisfactory way with some
> built in support rather than depend 100% on scripting to embed. The
> limitation of not having some built in support for this function gets
> converted to risk/time/error in user land when considering the large
> body of ad hoc scripting employed as workarounds.
>
> The reason cited in the FAQ for why this is not implemented is that it
> would take way too long for Subversion to scan every file in every
> directory of your working copy to figure out which ones have this
> special keyword in order to be able to update them. The Subversion
> client keeps no central database which could be consulted to know which
> files have the keyword, therefore an exhaustive and time-consuming
> search would be necessary. And since most users won't be using this
> keyword, the exhaustive search would have been done for nothing. This
> is changing with Subversion 1.7, however, wherein the working copy
> metadata will be consolidated in a single place* so I would think
> locating a file with a particular keyword should then become a quicker
> operation. Thus it should be possible to revisit this feature request
> after 1.7's release.
>
>
> *as far as I know. Read more about WC-NG ("Working Copy - Next
> Generation") here:
>
> http://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/design
>
OK - I think I'm starting to better understand the limitation. I am assuming you could avoid a brute force search for keywords by using the working directory metadata which would have info about which files are linked/important to version.h. I was thinking something similar to the way an external is linked via a property. In other words, rather than have Subversion hunt for keywords in files - you tell it which files are linked to version.h and this is kept in local metadata so it knows that when foo.c and bar.c are updated, then force an update version.h which, via the consequence of forcing an update, automatically results in $Revision$ keyword populated with version number (and M or other indication as to directory state). But maybe this is simply not possible in the architecture and has no value for most people. On the other hand, I have seen quite a bit of creative scripting recently trying to emulate some part of this... so it seems like a very desirable feature.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429064
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Any simple way to set/get global revision number?
Posted by "Hyrum K. Wright" <hy...@hyrumwright.org>.
On Dec 9, 2009, at 5:50 PM, Ryan Schmidt wrote:
> On Dec 9, 2009, at 17:27, Leyendecker, Robert wrote:
> ...
> The reason cited in the FAQ for why this is not implemented is that it would take way too long for Subversion to scan every file in every directory of your working copy to figure out which ones have this special keyword in order to be able to update them. The Subversion client keeps no central database which could be consulted to know which files have the keyword, therefore an exhaustive and time-consuming search would be necessary. And since most users won't be using this keyword, the exhaustive search would have been done for nothing. This is changing with Subversion 1.7, however, wherein the working copy metadata will be consolidated in a single place* so I would think locating a file with a particular keyword should then become a quicker operation. Thus it should be possible to revisit this feature request after 1.7's release.
>
>
> *as far as I know. Read more about WC-NG ("Working Copy - Next Generation") here:
>
> http://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/design
Yes, wc-ng will have centralized metadata.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429081
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Any simple way to set/get global revision number?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Dec 9, 2009, at 17:27, Leyendecker, Robert wrote:
> Yes – after I sent this I realized that I would get dinged about mixed revisions, local mods, etc. However, putting this detail in a version string is also problem even with a rat’s nest of client side scripting. For the feature I am proposing where I have modified or corrupted the directory, maybe “M” or “Dirty” some other indication with a version number would be appropriate since subversion automatically knows this when I update the directory.
You could use the same format svnversion uses, even if you don't use svnversion to get the information, since the developers of that tool already spent time thinking about a good format to use.
> You are correct – I would like anyone (not just me) to be able to checkout/update code give it to someone without depending on scripts and subversion and without the subversion directory structure and have an atomic version number automatically embedded that makes sense for the “directory” and not just the file. If the working directory doesn’t have modifications/conflicts etc, then I think it is reasonable to want to have the atomic version number at time of last commit for the updated files that I have manually pre-linked to version.h (or vice versa). I don’t think going back to older revisions breaks this idea, but haven’t fully thought it through. I also fully acknowledging it may not be an easy thing to implement in the subversion design.
You could write a "make tarball" script which creates a tarball of all your source, after updating version.h with the revision number. Then you would only require that the machine on which you run that script has Subversion installed.
> But the “global” (wish I had more accurate term) version issue doesn’t seem impossible to resolve in a more satisfactory way with some built in support rather than depend 100% on scripting to embed. The limitation of not having some built in support for this function gets converted to risk/time/error in user land when considering the large body of ad hoc scripting employed as workarounds.
The reason cited in the FAQ for why this is not implemented is that it would take way too long for Subversion to scan every file in every directory of your working copy to figure out which ones have this special keyword in order to be able to update them. The Subversion client keeps no central database which could be consulted to know which files have the keyword, therefore an exhaustive and time-consuming search would be necessary. And since most users won't be using this keyword, the exhaustive search would have been done for nothing. This is changing with Subversion 1.7, however, wherein the working copy metadata will be consolidated in a single place* so I would think locating a file with a particular keyword should then become a quicker operation. Thus it should be possible to revisit this feature request after 1.7's release.
*as far as I know. Read more about WC-NG ("Working Copy - Next Generation") here:
http://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/design
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429060
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by "Leyendecker, Robert" <Ro...@lsi.com>.
From: Daniel Becroft [mailto:djcbecroft@gmail.com]
Sent: Wednesday, December 09, 2009 4:23 PM
To: Leyendecker, Robert
Cc: Ryan Schmidt; Thomas Harold; users@subversion.tigris.org
Subject: Re: Any simple way to set/get global revision number?
On Thu, Dec 10, 2009 at 7:11 AM, Leyendecker, Robert <Ro...@lsi.com>> wrote:
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2009d@ryandesign.com<ma...@ryandesign.com>]
> Sent: Wednesday, December 09, 2009 12:31 PM
> To: Leyendecker, Robert
> Cc: Thomas Harold; users@subversion.tigris.org<ma...@subversion.tigris.org>
> Subject: Re: Any simple way to set/get global revision number?
>
>
> On Dec 9, 2009, at 09:51, Leyendecker, Robert wrote:
>
> > A reasonable proposal is to develop a new svn property to tag a file
> to always be checked out fresh when any other file is checked out in
> the directory - that 5th wheel file would have the $Revision$ etc
> keywords in it and would always pick up the global revision with no
> external client side script necessary
>
> But the first paragraph of the relevant FAQ entry explains why that's
> not practical.
>
> http://subversion.tigris.org/faq.html#version-value-in-source
>
Yes, I knew someone would eventually point me to this link. But I'm not requesting every file be checked and retagged. This isn't necessary in 99.99% of cases. I only want one file updated with the revision and it would be updated via the svn update/checkout mechanism.
When I do an update it brings everything up to a particular revision, if one of the files being updated coincidently has the $Revision$ keyword, I get exactly what I want. If version.h isn't one of those files, you are out of luck.
But - if in addition to my updated source files I also always get my version.h (just one file) then the $Revision$ keyword gets replaced with exactly what I want - just as if I did all the various things being done by client side scripts to achieve exactly the same result - a single number for my updated files in my working directory. This doesn't require subversion to do much more than it is already doing.
The $Revision$ keyword is designed to give the last revision of the file containing that keyword. This means there is no ambiguity with what version it should be. Having the $Revision$ keyword reflect the revision of multiple files means that its meaning is then changed. Consider the following:
svn update -r HEAD . (where HEAD is r100)
svn update -r 95 .\foo.c
svn update -r 96 .\foo.h
What value of $Revision$ is expect in version.h now? Given that $Revision$ in foo.c would be 95 and foo.h would be 96, what are you expecting for $Revision$ in version.h (given that under normal circumstances it would report 100)?
Then when I ask "what version are you running..." they can tell me a number even if they aren't running svn (or got a binary from someone else who built it without subversion etc) and I can check out that exact version.
No, it doesn't. That revision will tell you what version was checked out, not what version was built. Any local modifications, or mixed-revisions are not detected.
The "admin" just writes a version.h file with the keywords, marks it with a property that it is always checked out/updated in the users local dir and all users get the version.h file *automatically* available when they update to latest versions.
If they are able to run an update, then they have a copy of your source code, and they have SVN installed.
That happens because subversion knows the version.h file is linked to the modification of other files (or directory) via properties set by the user/admin and this link forces it to update the users local copy when the user updates.
The scenario you seem to be trying to solve is where the build is happening on a machine without SVN installed. Is it not possible to install SVN on these machines, and then modify the build script to achieve the required result?
Regards,
Daniel B.
Yes - after I sent this I realized that I would get dinged about mixed revisions, local mods, etc. However, putting this detail in a version string is also problem even with a rat's nest of client side scripting. For the feature I am proposing where I have modified or corrupted the directory, maybe "M" or "Dirty" some other indication with a version number would be appropriate since subversion automatically knows this when I update the directory.
You are correct - I would like anyone (not just me) to be able to checkout/update code give it to someone without depending on scripts and subversion and without the subversion directory structure and have an atomic version number automatically embedded that makes sense for the "directory" and not just the file. If the working directory doesn't have modifications/conflicts etc, then I think it is reasonable to want to have the atomic version number at time of last commit for the updated files that I have manually pre-linked to version.h (or vice versa). I don't think going back to older revisions breaks this idea, but haven't fully thought it through. I also fully acknowledging it may not be an easy thing to implement in the subversion design.
But the "global" (wish I had more accurate term) version issue doesn't seem impossible to resolve in a more satisfactory way with some built in support rather than depend 100% on scripting to embed. The limitation of not having some built in support for this function gets converted to risk/time/error in user land when considering the large body of ad hoc scripting employed as workarounds.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429056
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Any simple way to set/get global revision number?
Posted by Daniel Becroft <dj...@gmail.com>.
On Thu, Dec 10, 2009 at 7:11 AM, Leyendecker, Robert <
Robert.Leyendecker@lsi.com> wrote:
> > -----Original Message-----
> > From: Ryan Schmidt [mailto:subversion-2009d@ryandesign.com]
> > Sent: Wednesday, December 09, 2009 12:31 PM
> > To: Leyendecker, Robert
> > Cc: Thomas Harold; users@subversion.tigris.org
> > Subject: Re: Any simple way to set/get global revision number?
> >
> >
> > On Dec 9, 2009, at 09:51, Leyendecker, Robert wrote:
> >
> > > A reasonable proposal is to develop a new svn property to tag a file
> > to always be checked out fresh when any other file is checked out in
> > the directory - that 5th wheel file would have the $Revision$ etc
> > keywords in it and would always pick up the global revision with no
> > external client side script necessary
> >
> > But the first paragraph of the relevant FAQ entry explains why that's
> > not practical.
> >
> > http://subversion.tigris.org/faq.html#version-value-in-source
> >
>
> Yes, I knew someone would eventually point me to this link. But I'm not
> requesting every file be checked and retagged. This isn't necessary in
> 99.99% of cases. I only want one file updated with the revision and it would
> be updated via the svn update/checkout mechanism.
>
> When I do an update it brings everything up to a particular revision, if
> one of the files being updated coincidently has the $Revision$ keyword, I
> get exactly what I want. If version.h isn't one of those files, you are out
> of luck.
>
> But - if in addition to my updated source files I also always get my
> version.h (just one file) then the $Revision$ keyword gets replaced with
> exactly what I want - just as if I did all the various things being done by
> client side scripts to achieve exactly the same result - a single number for
> my updated files in my working directory. This doesn't require subversion to
> do much more than it is already doing.
>
The $Revision$ keyword is designed to give the last revision of the file
containing that keyword. This means there is no ambiguity with what version
it should be. Having the $Revision$ keyword reflect the revision of multiple
files means that its meaning is then changed. Consider the following:
svn update -r HEAD . (where HEAD is r100)
svn update -r 95 .\foo.c
svn update -r 96 .\foo.h
What value of $Revision$ is expect in version.h now? Given that $Revision$
in foo.c would be 95 and foo.h would be 96, what are you expecting for
$Revision$ in version.h (given that under normal circumstances it would
report 100)?
Then when I ask "what version are you running..." they can tell me a number
> even if they aren't running svn (or got a binary from someone else who built
> it without subversion etc) and I can check out that exact version.
>
No, it doesn't. That revision will tell you what version was checked out,
not what version was built. Any local modifications, or mixed-revisions are
not detected.
> The "admin" just writes a version.h file with the keywords, marks it with a
> property that it is always checked out/updated in the users local dir and
> all users get the version.h file *automatically* available when they update
> to latest versions.
If they are able to run an update, then they have a copy of your source
code, and they have SVN installed.
That happens because subversion knows the version.h file is linked to the
> modification of other files (or directory) via properties set by the
> user/admin and this link forces it to update the users local copy when the
> user updates.
>
The scenario you seem to be trying to solve is where the build is happening
on a machine without SVN installed. Is it not possible to install SVN on
these machines, and then modify the build script to achieve the required
result?
Regards,
Daniel B.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429028
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by Bob Archer <bo...@amsi.com>.
> Bob Archer <bo...@amsi.com> wrote on 12/09/2009 05:19:20 PM:
>
> > How about just having some cron job that on every commit it
> modifies
> > your version.h file and commits it assuming version.h wasn't
> > commited with the last commit. This time whenever anyone does an
> > update they will always get an updated version.h. It might get
> you there.
>
> I tried this, but you're always one behind and/or you get in an
> infinite loop:
>
> 1 - modify the file with the current version
> 2 - commit, which bumps the version
> 3 - since the version changed, go back to (1)
But, the version didn't really change. When I do an update version.h will have the rev it was updated in it. Right? I think even if you use svnversion it will put the last rev that file was changed... not the rev number of HEAD, which I think is what it sounds like what you want.
The infinite loop is avoided because you ignore the version.h file. We have several files that our build commits and we have cc.net set to ignore those files in the build triggers.
>
> (Plus, cron isn't portable, nor is svnversion, and it feels like
> a hack for something that would be better integrated into svn
> just as $Id$ is.)
You don't need cron to be portable... you only need the cron job to run on one machine, like your svn server which makes sure that version.h is committed into ever rev... if it is not you immediately commit it. The chance that someone will do a get or update from the rev that did have a commited version.h is pretty slim.
But, $Id$ and $Rev$ work exactly the same way.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429047
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by Kenneth Goldman <kg...@us.ibm.com>.
Bob Archer <bo...@amsi.com> wrote on 12/09/2009 05:19:20 PM:
> How about just having some cron job that on every commit it modifies
> your version.h file and commits it assuming version.h wasn't
> commited with the last commit. This time whenever anyone does an
> update they will always get an updated version.h. It might get you there.
I tried this, but you're always one behind and/or you get in an
infinite loop:
1 - modify the file with the current version
2 - commit, which bumps the version
3 - since the version changed, go back to (1)
(Plus, cron isn't portable, nor is svnversion, and it feels like
a hack for something that would be better integrated into svn
just as $Id$ is.)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429037
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by Bob Archer <bo...@amsi.com>.
> > On Dec 9, 2009, at 09:51, Leyendecker, Robert wrote:
> >
> > > A reasonable proposal is to develop a new svn property to tag a
> file
> > to always be checked out fresh when any other file is checked out
> in
> > the directory - that 5th wheel file would have the $Revision$ etc
> > keywords in it and would always pick up the global revision with
> no
> > external client side script necessary
> >
> > But the first paragraph of the relevant FAQ entry explains why
> that's
> > not practical.
> >
> > http://subversion.tigris.org/faq.html#version-value-in-source
> >
>
> Yes, I knew someone would eventually point me to this link. But I'm
> not requesting every file be checked and retagged. This isn't
> necessary in 99.99% of cases. I only want one file updated with the
> revision and it would be updated via the svn update/checkout
> mechanism.
>
> When I do an update it brings everything up to a particular
> revision, if one of the files being updated coincidently has the
> $Revision$ keyword, I get exactly what I want. If version.h isn't
> one of those files, you are out of luck.
>
> But - if in addition to my updated source files I also always get
> my version.h (just one file) then the $Revision$ keyword gets
> replaced with exactly what I want - just as if I did all the
> various things being done by client side scripts to achieve exactly
> the same result - a single number for my updated files in my
> working directory. This doesn't require subversion to do much more
> than it is already doing.
>
> Then when I ask "what version are you running..." they can tell me
> a number even if they aren't running svn (or got a binary from
> someone else who built it without subversion etc) and I can check
> out that exact version.
>
> The "admin" just writes a version.h file with the keywords, marks
> it with a property that it is always checked out/updated in the
> users local dir and all users get the version.h file
> *automatically* available when they update to latest versions. That
> happens because subversion knows the version.h file is linked to
> the modification of other files (or directory) via properties set
> by the user/admin and this link forces it to update the users local
> copy when the user updates.
>
> This is almost the same functionality (to varying degres) that
> client side scripts are trying to emulate, except I think having it
> formally supported in subversion is more flexible and less error
> prone. It seems like a worthy feature given all the custom
> workarounds to accomplish the same thing.
>
> I think this is a reasonably well articulated idea.
Not sure if the SVN devs will see it as a worthwhile feature.
How about just having some cron job that on every commit it modifies your version.h file and commits it assuming version.h wasn't commited with the last commit. This time whenever anyone does an update they will always get an updated version.h. It might get you there.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429026
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Any simple way to set/get global revision number?
Posted by Les Mikesell <le...@gmail.com>.
Leyendecker, Robert wrote:
>> -----Original Message-----
>> From: Ryan Schmidt [mailto:subversion-2009d@ryandesign.com]
>> Sent: Wednesday, December 09, 2009 12:31 PM
>> To: Leyendecker, Robert
>> Cc: Thomas Harold; users@subversion.tigris.org
>> Subject: Re: Any simple way to set/get global revision number?
>>
>>
>> On Dec 9, 2009, at 09:51, Leyendecker, Robert wrote:
>>
>>> A reasonable proposal is to develop a new svn property to tag a file
>> to always be checked out fresh when any other file is checked out in
>> the directory - that 5th wheel file would have the $Revision$ etc
>> keywords in it and would always pick up the global revision with no
>> external client side script necessary
>>
>> But the first paragraph of the relevant FAQ entry explains why that's
>> not practical.
>>
>> http://subversion.tigris.org/faq.html#version-value-in-source
>>
>
> Yes, I knew someone would eventually point me to this link. But I'm not requesting every file be checked and retagged. This isn't necessary in 99.99% of cases. I only want one file updated with the revision and it would be updated via the svn update/checkout mechanism.
>
> When I do an update it brings everything up to a particular revision, if one of the files being updated coincidently has the $Revision$ keyword, I get exactly what I want. If version.h isn't one of those files, you are out of luck.
>
> But - if in addition to my updated source files I also always get my version.h (just one file) then the $Revision$ keyword gets replaced with exactly what I want - just as if I did all the various things being done by client side scripts to achieve exactly the same result - a single number for my updated files in my working directory. This doesn't require subversion to do much more than it is already doing.
>
> Then when I ask "what version are you running..." they can tell me a number even if they aren't running svn (or got a binary from someone else who built it without subversion etc) and I can check out that exact version.
>
> The "admin" just writes a version.h file with the keywords, marks it with a property that it is always checked out/updated in the users local dir and all users get the version.h file *automatically* available when they update to latest versions. That happens because subversion knows the version.h file is linked to the modification of other files (or directory) via properties set by the user/admin and this link forces it to update the users local copy when the user updates.
>
> This is almost the same functionality (to varying degres) that client side scripts are trying to emulate, except I think having it formally supported in subversion is more flexible and less error prone. It seems like a worthy feature given all the custom workarounds to accomplish the same thing.
>
> I think this is a reasonably well articulated idea.
If you have differing copies in branches and tags, how does having the global
repository version number at the time of a build identify what you have built?
--
Les Mikesell
lesmikesell@gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429059
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by Kenneth Goldman <kg...@us.ibm.com>.
I 99% agree with you, but I think it would be better to insert the
value at (just before) commit, not update, just as the $Id$ value
is inserted now.
If you insert the value at update and the primary developer never
updates, only commits, they will never get the new value. I think
the general principle is that, after I commit, I want the same
files that the repository has.
"Leyendecker, Robert" <Ro...@lsi.com> wrote on 12/09/2009
04:11:09 PM:
> Yes, I knew someone would eventually point me to this link. But I'm
> not requesting every file be checked and retagged. This isn't
> necessary in 99.99% of cases. I only want one file updated with the
> revision and it would be updated via the svn update/checkout mechanism.
>
> When I do an update it brings everything up to a particular
> revision, if one of the files being updated coincidently has the
> $Revision$ keyword, I get exactly what I want. If version.h isn't
> one of those files, you are out of luck.
>
> But - if in addition to my updated source files I also always get my
> version.h (just one file) then the $Revision$ keyword gets replaced
> with exactly what I want - just as if I did all the various things
> being done by client side scripts to achieve exactly the same result
> - a single number for my updated files in my working directory. This
> doesn't require subversion to do much more than it is already doing.
>
> Then when I ask "what version are you running..." they can tell me
> a number even if they aren't running svn (or got a binary from
> someone else who built it without subversion etc) and I can check
> out that exact version.
>
> The "admin" just writes a version.h file with the keywords, marks it
> with a property that it is always checked out/updated in the users
> local dir and all users get the version.h file *automatically*
> available when they update to latest versions. That happens because
> subversion knows the version.h file is linked to the modification of
> other files (or directory) via properties set by the user/admin and
> this link forces it to update the users local copy when the user updates.
>
> This is almost the same functionality (to varying degres) that
> client side scripts are trying to emulate, except I think having it
> formally supported in subversion is more flexible and less error
> prone. It seems like a worthy feature given all the custom
> workarounds to accomplish the same thing.
>
> I think this is a reasonably well articulated idea.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?
> dsForumId=1065&dsMessageId=2429008
>
> Please start new threads on the <us...@subversion.apache.org> mailing
list.
> To subscribe to the new list, send an empty e-mail to <users-
> subscribe@subversion.apache.org>.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429034
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by "Leyendecker, Robert" <Ro...@lsi.com>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2009d@ryandesign.com]
> Sent: Wednesday, December 09, 2009 12:31 PM
> To: Leyendecker, Robert
> Cc: Thomas Harold; users@subversion.tigris.org
> Subject: Re: Any simple way to set/get global revision number?
>
>
> On Dec 9, 2009, at 09:51, Leyendecker, Robert wrote:
>
> > A reasonable proposal is to develop a new svn property to tag a file
> to always be checked out fresh when any other file is checked out in
> the directory - that 5th wheel file would have the $Revision$ etc
> keywords in it and would always pick up the global revision with no
> external client side script necessary
>
> But the first paragraph of the relevant FAQ entry explains why that's
> not practical.
>
> http://subversion.tigris.org/faq.html#version-value-in-source
>
Yes, I knew someone would eventually point me to this link. But I'm not requesting every file be checked and retagged. This isn't necessary in 99.99% of cases. I only want one file updated with the revision and it would be updated via the svn update/checkout mechanism.
When I do an update it brings everything up to a particular revision, if one of the files being updated coincidently has the $Revision$ keyword, I get exactly what I want. If version.h isn't one of those files, you are out of luck.
But - if in addition to my updated source files I also always get my version.h (just one file) then the $Revision$ keyword gets replaced with exactly what I want - just as if I did all the various things being done by client side scripts to achieve exactly the same result - a single number for my updated files in my working directory. This doesn't require subversion to do much more than it is already doing.
Then when I ask "what version are you running..." they can tell me a number even if they aren't running svn (or got a binary from someone else who built it without subversion etc) and I can check out that exact version.
The "admin" just writes a version.h file with the keywords, marks it with a property that it is always checked out/updated in the users local dir and all users get the version.h file *automatically* available when they update to latest versions. That happens because subversion knows the version.h file is linked to the modification of other files (or directory) via properties set by the user/admin and this link forces it to update the users local copy when the user updates.
This is almost the same functionality (to varying degres) that client side scripts are trying to emulate, except I think having it formally supported in subversion is more flexible and less error prone. It seems like a worthy feature given all the custom workarounds to accomplish the same thing.
I think this is a reasonably well articulated idea.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429008
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Any simple way to set/get global revision number?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Dec 9, 2009, at 09:51, Leyendecker, Robert wrote:
> A reasonable proposal is to develop a new svn property to tag a file to always be checked out fresh when any other file is checked out in the directory - that 5th wheel file would have the $Revision$ etc keywords in it and would always pick up the global revision with no external client side script necessary
But the first paragraph of the relevant FAQ entry explains why that's not practical.
http://subversion.tigris.org/faq.html#version-value-in-source
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428945
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Any simple way to set/get global revision number?
Posted by Hari Kodungallur <hk...@gmail.com>.
On Wed, Dec 9, 2009 at 8:33 AM, Bob Archer <bo...@amsi.com> wrote:
> > > How about taking a slightly different approach.
> > >
> > > Rather than versioning your app based on the svn revision number,
> > > version it based on the build number. Have the build script
> > update the
> > > version.h file. Once the build is done commit the version.h file
> > and
> > > create a tag for that build. Now if someone updates from head and
> > does
> > > a manual build the version.h file is correct for that revision.
> > >
> > > BOb
> > >
> > >
> > Yes, I failed to mention that is similar to the first approach I
> > implemented - people use mix of linux and windows tortoise client
> > and they instinctively just commit specific files they changed (me
> > included) and the elegant self generating version .h file (that I
> > spent time getting just right with lots of echo's and >> and a note
> > about this being an automatically generated file, do not edit, etc
> > :-) sits as an orphan in their directory forever or until they
> > remember to check it in. Next person does update and the version
> > number is unchanged.
> >
> > Of course having the build script doing an auto-commit on file
> > changes isn't practical since people do tons of builds a day. Looks
> > like creating a special build process using auto tools or scripts
> > and svnversion seems only solution and if you don't have this with
> > full svn and gnu in your environment you are out of luck and have
> > to rely on manually versioning those files before distributing
> > them.
>
> If the build script is run by a dev it should not be committed as an
> official version. Only the build server can commit an official version. This
> is easy to do by having a property in your build script that flags whether
> this is a versioned build or just an interim build that a dev is testing.
>
> You could also have a "current" tag that is updated after each build so
> people that are building for production would checkout/export from that tag
> which would always have the correct version.h in it.
>
>
Here is my 2c. This is probably something that is individual's preference
though.
I think if you can make sure the version.h creation is correct and
repeatable, then you don't need to check in the version.h file at all. You
can have a template version.h (version.h.tmpl) checked into svn. Then the
build script generates version.h using the template + a few build specific
information generated at the time of the build. Then you only need to make
sure that any person who builds a branch (or trunk) at a particular
revision, always gets the exact same copy of the version.h. [I've had such
implementation in multiple companies].
-Hari
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428921
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by Bob Archer <bo...@amsi.com>.
> > How about taking a slightly different approach.
> >
> > Rather than versioning your app based on the svn revision number,
> > version it based on the build number. Have the build script
> update the
> > version.h file. Once the build is done commit the version.h file
> and
> > create a tag for that build. Now if someone updates from head and
> does
> > a manual build the version.h file is correct for that revision.
> >
> > BOb
> >
> >
> Yes, I failed to mention that is similar to the first approach I
> implemented - people use mix of linux and windows tortoise client
> and they instinctively just commit specific files they changed (me
> included) and the elegant self generating version .h file (that I
> spent time getting just right with lots of echo's and >> and a note
> about this being an automatically generated file, do not edit, etc
> :-) sits as an orphan in their directory forever or until they
> remember to check it in. Next person does update and the version
> number is unchanged.
>
> Of course having the build script doing an auto-commit on file
> changes isn't practical since people do tons of builds a day. Looks
> like creating a special build process using auto tools or scripts
> and svnversion seems only solution and if you don't have this with
> full svn and gnu in your environment you are out of luck and have
> to rely on manually versioning those files before distributing
> them.
If the build script is run by a dev it should not be committed as an official version. Only the build server can commit an official version. This is easy to do by having a property in your build script that flags whether this is a versioned build or just an interim build that a dev is testing.
You could also have a "current" tag that is updated after each build so people that are building for production would checkout/export from that tag which would always have the correct version.h in it.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428905
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by "Leyendecker, Robert" <Ro...@lsi.com>.
> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer@amsi.com]
> Sent: Wednesday, December 09, 2009 10:09 AM
> To: Leyendecker, Robert; Thomas Harold
> Cc: users@subversion.tigris.org
> Subject: RE: Any simple way to set/get global revision number?
>
> How about taking a slightly different approach.
>
> Rather than versioning your app based on the svn revision number,
> version it based on the build number. Have the build script update the
> version.h file. Once the build is done commit the version.h file and
> create a tag for that build. Now if someone updates from head and does
> a manual build the version.h file is correct for that revision.
>
> BOb
>
>
Yes, I failed to mention that is similar to the first approach I implemented - people use mix of linux and windows tortoise client and they instinctively just commit specific files they changed (me included) and the elegant self generating version .h file (that I spent time getting just right with lots of echo's and >> and a note about this being an automatically generated file, do not edit, etc :-) sits as an orphan in their directory forever or until they remember to check it in. Next person does update and the version number is unchanged.
Of course having the build script doing an auto-commit on file changes isn't practical since people do tons of builds a day. Looks like creating a special build process using auto tools or scripts and svnversion seems only solution and if you don't have this with full svn and gnu in your environment you are out of luck and have to rely on manually versioning those files before distributing them.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428901
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by Bob Archer <bo...@amsi.com>.
How about taking a slightly different approach.
Rather than versioning your app based on the svn revision number, version it based on the build number. Have the build script update the version.h file. Once the build is done commit the version.h file and create a tag for that build. Now if someone updates from head and does a manual build the version.h file is correct for that revision.
BOb
> -----Original Message-----
> From: Leyendecker, Robert [mailto:Robert.Leyendecker@lsi.com]
> Sent: Wednesday, December 09, 2009 10:52 AM
> To: Thomas Harold
> Cc: users@subversion.tigris.org
> Subject: RE: Any simple way to set/get global revision number?
>
> Thanks very much for the links, it's great to see what other people
> are doing.
>
> Build scripts and self generating version files are the process
> I've been using for a while and it works fine as long as your build
> env is static and controlled by a single entity (cative). Doesn't
> work so well moving source code minus svn directories to other non-
> svn environments.
>
> I've written a few ugly client side hacks to get around this and
> been in a few interesting organizational meetings to figure out
> workarounds. Given all the options in SVN - the revision issue
> merits a more flexible and officially sanctioned solution by svn
> development team. It doesn't seem like an insurmountable problem.
>
> A reasonable proposal is to develop a new svn property to tag a
> file to always be checked out fresh when any other file is checked
> out in the directory - that 5th wheel file would have the
> $Revision$ etc keywords in it and would always pick up the global
> revision with no external client side script necessary, in other
> words, no special
> perl/python/bash/sed/awk/grep/tcl/m4/autotools/AutohotKey/etc
> (although I like a challenge as much as the next developer :-). I
> also tried emulating this behavior with externals, but no luck.
>
> Anyway, then you could simply check out and move source code around
> to other non-svn systems (windows, linux, or other) and still have
> your embedded versioning in the version.h file.
>
> But - I don't know how the svn source code is structured so maybe
> this is too difficult to implement. Or maybe this option exists in
> an admin configuration and I'm just unaware of it?
>
>
>
>
> > -----Original Message-----
> > From: Thomas Harold [mailto:thomas-lists@nybeta.com]
> > Sent: Tuesday, December 08, 2009 10:13 PM
> > To: Leyendecker, Robert
> > Cc: users@subversion.tigris.org
> > Subject: Re: Any simple way to set/get global revision number?
> >
> > On 12/8/2009 2:43 PM, Leyendecker, Robert wrote:
> > > Say I have a c file called version.h and in this file is a
> macro to
> > > build a version string using $HeadURL$ and $Revision$. When a
> user
> > runs
> > > the program this information is printed into the log file to
> help
> > > isolate problems to specific versions that change on daily
> basis.
> > > Is there a way to set a property so that this version.h file is
> > > automatically checked out whenever an update is made to the
> directory
> > > even if the version.h file is not touched? Or conversely, is
> there a
> > way
> > > to have it automatically checked in as a changed file whenever
> a
> > commit
> > > is done on any other file in the directory?
> > > I'm trying to avoid having to manually run/maintain external
> scripts
> > or
> > > programs like svnversion to scrape/touch/alter version files
> and
> > force
> > > changes since the src files may be ported to different systems
> and I
> > > want the svn info embedded into a single version file.
> > > Am I out of luck for an easy solution?
> >
> > Looks like you need to build the version.h file on the fly as
> part of
> > your build process.
> >
> > Found a bunch of links on StackOverflow...
> >
> > http://stackoverflow.com/questions/151299/embedding-svn-revision-
> > number-at-compile-time-in-a-windows-app
> >
> > http://stackoverflow.com/questions/145449/easy-way-to-embed-svn-
> > revision-number-in-page-in-php-closed
> >
> > http://stackoverflow.com/questions/111436/how-can-i-get-the-svn-
> > revision-number-in-php
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMes
> sageId=2428887
>
> Please start new threads on the <us...@subversion.apache.org>
> mailing list.
> To subscribe to the new list, send an empty e-mail to <users-
> subscribe@subversion.apache.org>.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428894
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by "Leyendecker, Robert" <Ro...@lsi.com>.
Thanks very much for the links, it's great to see what other people are doing.
Build scripts and self generating version files are the process I've been using for a while and it works fine as long as your build env is static and controlled by a single entity (cative). Doesn't work so well moving source code minus svn directories to other non-svn environments.
I've written a few ugly client side hacks to get around this and been in a few interesting organizational meetings to figure out workarounds. Given all the options in SVN - the revision issue merits a more flexible and officially sanctioned solution by svn development team. It doesn't seem like an insurmountable problem.
A reasonable proposal is to develop a new svn property to tag a file to always be checked out fresh when any other file is checked out in the directory - that 5th wheel file would have the $Revision$ etc keywords in it and would always pick up the global revision with no external client side script necessary, in other words, no special perl/python/bash/sed/awk/grep/tcl/m4/autotools/AutohotKey/etc (although I like a challenge as much as the next developer :-). I also tried emulating this behavior with externals, but no luck.
Anyway, then you could simply check out and move source code around to other non-svn systems (windows, linux, or other) and still have your embedded versioning in the version.h file.
But - I don't know how the svn source code is structured so maybe this is too difficult to implement. Or maybe this option exists in an admin configuration and I'm just unaware of it?
> -----Original Message-----
> From: Thomas Harold [mailto:thomas-lists@nybeta.com]
> Sent: Tuesday, December 08, 2009 10:13 PM
> To: Leyendecker, Robert
> Cc: users@subversion.tigris.org
> Subject: Re: Any simple way to set/get global revision number?
>
> On 12/8/2009 2:43 PM, Leyendecker, Robert wrote:
> > Say I have a c file called version.h and in this file is a macro to
> > build a version string using $HeadURL$ and $Revision$. When a user
> runs
> > the program this information is printed into the log file to help
> > isolate problems to specific versions that change on daily basis.
> > Is there a way to set a property so that this version.h file is
> > automatically checked out whenever an update is made to the directory
> > even if the version.h file is not touched? Or conversely, is there a
> way
> > to have it automatically checked in as a changed file whenever a
> commit
> > is done on any other file in the directory?
> > I'm trying to avoid having to manually run/maintain external scripts
> or
> > programs like svnversion to scrape/touch/alter version files and
> force
> > changes since the src files may be ported to different systems and I
> > want the svn info embedded into a single version file.
> > Am I out of luck for an easy solution?
>
> Looks like you need to build the version.h file on the fly as part of
> your build process.
>
> Found a bunch of links on StackOverflow...
>
> http://stackoverflow.com/questions/151299/embedding-svn-revision-
> number-at-compile-time-in-a-windows-app
>
> http://stackoverflow.com/questions/145449/easy-way-to-embed-svn-
> revision-number-in-page-in-php-closed
>
> http://stackoverflow.com/questions/111436/how-can-i-get-the-svn-
> revision-number-in-php
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428887
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
Re: Any simple way to set/get global revision number?
Posted by Thomas Harold <th...@nybeta.com>.
On 12/8/2009 2:43 PM, Leyendecker, Robert wrote:
> Say I have a c file called version.h and in this file is a macro to
> build a version string using $HeadURL$ and $Revision$. When a user runs
> the program this information is printed into the log file to help
> isolate problems to specific versions that change on daily basis.
> Is there a way to set a property so that this version.h file is
> automatically checked out whenever an update is made to the directory
> even if the version.h file is not touched? Or conversely, is there a way
> to have it automatically checked in as a changed file whenever a commit
> is done on any other file in the directory?
> I’m trying to avoid having to manually run/maintain external scripts or
> programs like svnversion to scrape/touch/alter version files and force
> changes since the src files may be ported to different systems and I
> want the svn info embedded into a single version file.
> Am I out of luck for an easy solution?
Looks like you need to build the version.h file on the fly as part of
your build process.
Found a bunch of links on StackOverflow...
http://stackoverflow.com/questions/151299/embedding-svn-revision-number-at-compile-time-in-a-windows-app
http://stackoverflow.com/questions/145449/easy-way-to-embed-svn-revision-number-in-page-in-php-closed
http://stackoverflow.com/questions/111436/how-can-i-get-the-svn-revision-number-in-php
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428733
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by "Leyendecker, Robert" <Ro...@lsi.com>.
> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer@amsi.com]
> Sent: Tuesday, December 08, 2009 1:55 PM
> To: Leyendecker, Robert; users@subversion.tigris.org
> Subject: RE: Any simple way to set/get global revision number?
>
> > Subject: Any simple way to set/get global revision number?
> >
> > Say I have a c file called version.h and in this file is a macro to
> > build a version string using $HeadURL$ and $Revision$. When a user
> > runs the program this information is printed into the log file to
> > help isolate problems to specific versions that change on daily
> > basis.
> >
> > Is there a way to set a property so that this version.h file is
> > automatically checked out whenever an update is made to the
> > directory even if the version.h file is not touched? Or conversely,
> > is there a way to have it automatically checked in as a changed
> > file whenever a commit is done on any other file in the directory?
>
> No, not that I know of.
>
> > I'm trying to avoid having to manually run/maintain external
> > scripts or programs like svnversion to scrape/touch/alter version
> > files and force changes since the src files may be ported to
> > different systems and I want the svn info embedded into a single
> > version file.
> >
> > Am I out of luck for an easy solution?
>
> I think the most common method here is to implement this in a build
> script and use a CI server that builds each check in. I know this is
> what you say this is what you want to avoid.... but I'm not quite sure
> why?
>
> http://subversion.tigris.org/faq.html#version-value-in-source
>
> BOb
>
>
Not all the environments that can compile and run the code have svn installed and sometimes source code is moved around without moving the svn info dirs. I have used scripts to accomplish these things in the past, was hoping for something more elegant in present day.
Creating a new SVN prop on arbitrary my_version.h file that forces this file to be updated (which would cause the embedded revision related keywords in my_version.h to be updated) when any other file is updated would do the trick for my simple case and avoid having to maintain separate scripting, autotools complexity, etc. If this new property were set, operation would be transparent - if you commit foo.c then bar.c (with $Date$, $Revisions$ etc keywords filled in) gets marked to be checked out next update and you have a way to automatically update the version info for the build.
Building this into svn would allow windows and linux clients to offer same functionality - a pretty easy way to manage the svn version number that gets printed when you type foobar --help without relying on client side scripts to parse and build in the needed info.
Anyway, just an idea. I anticipated the answer is probably no and never, but just wanted make sure I wasn't missing something obvious.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428318
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.
RE: Any simple way to set/get global revision number?
Posted by Bob Archer <bo...@amsi.com>.
> Subject: Any simple way to set/get global revision number?
>
> Say I have a c file called version.h and in this file is a macro to
> build a version string using $HeadURL$ and $Revision$. When a user
> runs the program this information is printed into the log file to
> help isolate problems to specific versions that change on daily
> basis.
>
> Is there a way to set a property so that this version.h file is
> automatically checked out whenever an update is made to the
> directory even if the version.h file is not touched? Or conversely,
> is there a way to have it automatically checked in as a changed
> file whenever a commit is done on any other file in the directory?
No, not that I know of.
> I'm trying to avoid having to manually run/maintain external
> scripts or programs like svnversion to scrape/touch/alter version
> files and force changes since the src files may be ported to
> different systems and I want the svn info embedded into a single
> version file.
>
> Am I out of luck for an easy solution?
I think the most common method here is to implement this in a build script and use a CI server that builds each check in. I know this is what you say this is what you want to avoid.... but I'm not quite sure why?
http://subversion.tigris.org/faq.html#version-value-in-source
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428312
Please start new threads on the <us...@subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <us...@subversion.apache.org>.