> > 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.
>
> 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.
>
> 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. 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.
>
> This is almost the same functionality (to varying degres) that
> client side scripts are trying to emulate, except I think having it
> formally supported in subversion is more flexible and less error
> prone. It seems like a worthy feature given all the custom
> workarounds to accomplish the same thing.
>
> I think this is a reasonably well articulated idea.
Not sure if the SVN devs will see it as a worthwhile feature.
How about just having some cron job that on every commit it modifies your version.h file and commits it assuming version.h wasn't commited with the last commit. This time whenever anyone does an update they will always get an updated version.h. It might get you there.
BOb
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429026
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:20:23 CET