RE: Any simple way to set/get global revision number?

From: Daniel Becroft [mailto:djcbecroft_at_gmail.com]
Sent: Wednesday, December 09, 2009 4:23 PM
To: Leyendecker, Robert
Cc: Ryan Schmidt; Thomas Harold; users_at_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 <Robert.Leyendecker_at_lsi.com<mailto:Robert.Leyendecker_at_lsi.com>> wrote:
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2009d_at_ryandesign.com<mailto:subversion-2009d_at_ryandesign.com>]
> Sent: Wednesday, December 09, 2009 12:31 PM
> To: Leyendecker, Robert
> Cc: Thomas Harold; users_at_subversion.tigris.org<mailto:users_at_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 <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-12-10 00:29:44 CET