RE: Any simple way to set/get global revision number?
From: Leyendecker, Robert <Robert.Leyendecker_at_lsi.com>
Date: Wed, 9 Dec 2009 18:27:36 -0500
From: Daniel Becroft [mailto:djcbecroft_at_gmail.com]
On Thu, Dec 10, 2009 at 7:11 AM, Leyendecker, Robert <Robert.Leyendecker_at_lsi.com<mailto:Robert.Leyendecker_at_lsi.com>> wrote:
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)
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)?
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.
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?
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.
Please start new threads on the <users_at_subversion.apache.org> mailing list.
This is an archived mail posted to the Subversion Users mailing list.