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