I've been a SCM for almost 20 years now, and I have been using SCCS
and RCS keyword expansions for quite a while. This is my take on the
matter:
As long as the source is in the source archive, there really isn't
much need for any RCS expansion string. In Subversion, you can easily
pull up any information with the "svn log" command.
The only time you might deal with a program outside of the source
archive is something you sent to a client. That can easily be handled
at compile time by having a program "compile" an ident or what string
at the time of the build. This "ident" string can then be traced back
to a label or tag in your source archive, and you can then pull up
any information you might need via the "svn log" or similar command.
When I first used ClearCase, I realized it didn't have keyword
expansion at all. I wrote a trigger that would munge the expansion on
a check in. This turned out to be a really big headache because it
broke the automatic merging capabilities. Instead, I removed the RCS
keyword expansion munging and did a ident string build at build time.
At first, I was really upset about the lack of keyword expansion, but
then I realized that I really didn't miss it.
<cynical-non-serious-mode>
If it was up to me, I'd yank the RCS keywords feature out of
Subversion. Then, no one would complain about the wrong RCS keywords
are being expanded, or that the svn:keywords property is acting
funny. That would allow the Subversion developers more time to focus
on the features Subversion really needs and will save the CMs who are
using Subversion from wasting time trying to figure out how to
configure Subversion in order to take advantage of the whole RCS
keyword expansion. Everyone would be more productive.
</cynical-non-serious-mode>
On Oct 12, 2005, at 11:12 AM, Vincent Lefevre wrote:
> On 2005-10-11 14:06:55 -0400, Greg Hudson wrote:
>
>> Go to your svn working copy and look at .svn/entries. See the
>> "revision" field in the XML entries (for the directory itself and
>> for any files whose revision differs from the directory). That's the
>> number which would be substituted in for $UpdateRev$ in my vision.
>>
>
> But I think that this number doesn't make much sense in practice.
> And this is not Molle's vision:
>
> The keyword reflects the newest (highest) "last comitted
> revision" of
> any item in the current working copy.
>
> --
> Vincent Lefèvre <vincent_at_vinc17.org> - Web: <http://www.vinc17.org/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/
> blog/>
> Work: CR INRIA - computer arithmetic / SPACES project at LORIA
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 14 06:19:11 2005