> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2009d_at_ryandesign.com]
> Sent: Wednesday, December 09, 2009 5:50 PM
> To: Leyendecker, Robert
> Cc: Daniel Becroft; Thomas Harold; users_at_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 <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 01:25:13 CET