[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-10-11 18:47:28 CEST

On Tue, 2005-10-11 at 15:52 +0100, Julian Foad wrote:
> Some people have said that it can't be implemented efficiently. That depends,
> of course, on exactly what is to be implemented, but I do not believe it.
> There are exceedingly few problems that cannot be computed efficiently and
> there is no reason to think this is one of them.

In my vision, $UpdateRev$ reflects the .svn/entries state of the file it
lives in, and is only re-expanded when the entry is changed. This can
be implemented efficiently, as long as we record enough state in the
entry to avoid re-expanding a file when its svn:keywords property does
not contain UpdateRev. Also, a very similar mechanism can update $URL$
after an "svn switch", fixing #1975.

In a different vision, $UpdateRev$ reflects the version state of the
entire working copy no matter how the working copy is modified. As a
result, "svn update foofiile" must potentially change the contents of
any number of files, not just foofile, because that command changes the
version state of the working copy to a mixed state. It's very hard to
imagine such a vision being implemented efficiently; it would either
require an up-and-down scan of the working copy on every "svn update
foofile" command, or it would involve storing, in each directory's .svn
area, a list of files whose svn:keywords property contains UpdateRev.
The latter design is fragile, has ugly ramifications for working-copy
severability, and requires "svn propset svn:keywords" to potentially do
a great deal of work.

> To assume that the implementor of this feature would do a poor job is irrational.

No one's assuming that.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 11 18:48:54 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.