Re: Proposal for $Revision$ keyword amendment

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. Note how
> that number differs from the "commited-rev" field which is substituted
> in for $LastChangedRevision$.

For any given file, I'm not able to get a different number for
committed-rev and revision (though it is easy to make the revision not
be the same as the parent folder). How is $UpdateRev$ different from
$LastChangedRevision$ then?

> Gah. I say "it would require a recursive walk of the tree, or it would
> require storing all this information," and you respond "it's probably
> not necessary to store all ths information, since we could just do a
> recursive walk of the tree." Well, of course.

Funny, the voice in my head explained that a lot better than what my
fingers typed. :-(

What I was suggesting was that, during normal [recursive] update
processing, the entries file be consulted for the presence of the
'dirty-keywords' entry and a flag set. If and only if that flag was
set, would an additional loop be required to expand the special
keywords. I'm still (possibly foolishly) operating under the assumption
that the OP wants the 'WC revision' not some single 'file revision',
which is not available after the entire WC has been walked. Whether a
flag is set, or the code collects the list of files that need
postprocessing, the expense is paid only by those people who need it.

Actually, it occurs to me that storing the keywords value in the entries
file (instead of with other generic props) would make several things easier.

> Doing a recursive walk of the tree in response to "svn update foofile"
> is not acceptable performance; such a command should be fast even if
> you're operating in a very large working copy.

Gosh, do you suppose that's why I'm arguing against the feature in the
first place? ;-)

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org