I 99% agree with you, but I think it would be better to insert the
value at (just before) commit, not update, just as the $Id$ value
is inserted now.
If you insert the value at update and the primary developer never
updates, only commits, they will never get the new value. I think
the general principle is that, after I commit, I want the same
files that the repository has.
"Leyendecker, Robert" <Robert.Leyendecker_at_lsi.com> wrote on 12/09/2009
04:11:09 PM:
> 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.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?
> dsForumId=1065&dsMessageId=2429008
>
> 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>.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2429034
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:41:55 CET