[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Proposal for $Revision$ keyword amendment

From: John Peacock <jpeacock_at_rowman.com>
Date: 2005-09-30 19:25:30 CEST

Greg Hudson wrote:
> I don't think we'd have to. We'd have to rewrite a file when (1) we're
> bumping their revision numbers at the end of an update, and (2) the
> entry indicates that the file has an svn:keywords property containing
> $GlobalRev$ or whatever. (Similarly, to fix the "svn switch" keywords
> bug, we'd have to rewrite each file whose entry indicates that the file
> has an svn:keywords property containing any keyword which lists the
> file's URL or FS path.)

But I think that Max is correct in stating that this operation would
have to walk the entire WC, even if it was only checking the entries
file in each directory. For the degenerate case where every file has a
keyword set, this would be equivalent to rewriting the WC every single
time anything changed.

> For normal cases, the main penalty would be having to store the
> svn:keywords property of each file inside the entries files.

In practice, you wouldn't need to store the actual svn:keywords property
itself, merely a flag that the given file has one at all. This flag
could be tailored to only reflect those svn:keywords entries that
requires the additional loop, in this case $UpdateRev$ and all of the
fields touched in the 'switch' bug. This might be acceptable tradeoff,
but I don't see how a tree-walk in some cases won't be inevitable. Of
course, the top level routine could simply note during normal update
processing whether or not any files have that flag, and only call the
post update if there is the presence of at least one.

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
Received on Fri Sep 30 19:26:04 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.