> Can the keywords be collapsed on check in to the base keyword? For example:
>
> $who: username$ would get condensed to $who:$
> $revision: r1234$ would get condensed to $revision:$
I thought they were -- based on the Definitive Guide that I read this
morning.
>
> Then on checkout, the keywords would get expanded through whatever the
> substitution policy is.
>
> That way, the file doesn't change with every commit because the keyword
> expands differently. Is what we really want to revision, the keywords, not
> the meta data defined by the keywords?
>
In my case for a flat version file, I want the meta data in the file and
forget that it was Meta Data.
> This does require parsing the file on both check in and checkout. If this
> isn't already being done, that can be (will be :) ) a huge performance
> issue. Maybe a solution is to limit keywords to the 1st line of a file, or
> first N lines of a file.
>
Performance isn't much of an issue with keywords because of the wisely
chosen keyword property that must be set. It's only an issue if its
chosen to be used. What I'm looking forward might be called keyword-once
and if I chose to use it for one file, I'll pay the price of the one file.
If you don't, then you pay no price.
Rereading the Issue, "we'd need to know the revision number of the commit
*before* the commit is done." My best response would be that we could
define, by meta data, a log file for a subtree that could be handled
specially. Yes, in order to write it expanded, the value must be in
there -- unless its *never* in there (until you change a bunch from tags
rthat reference the txn to plain text and the issue is dropped for several
txn in one new one).
But, it sounds like we'll probably generate this file with our releases
:-( Incidentally, this is my only problem with svn, which is a good thing
-- I am picky :-)
j.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 13 22:17:27 2003