On Thu, Dec 10, 2009 at 7:11 AM, Leyendecker, Robert <
Robert.Leyendecker_at_lsi.com> wrote:
> > -----Original Message-----
> > From: Ryan Schmidt [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
> > 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 <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-09 23:24:31 CET