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

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429060

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:51:20 CET