Greg Hudson wrote:
> 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.
Ah, thanks. You've said that before, but only now do I comprehend how it
solves the problem. That means the keyword reflects the revision to which its
file was last requested to be updated. The keyword is reexpanded whenever the
file is updated to a different revision number, even if its "last-modified"
revision does not change. Thus, this keyword reflects the "last updated to"
revision of a whole tree if and only if the tree is updated as a whole.
That would seem to satisfy those who only care about the keyword's consistency
when they are doing whole-tree updates.
Are those who requested the feature happy with that version of it?
> 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;
I'm not saying we want this, but I can imagine it 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.
Or an infinite number of other strategies. For example, off the top of my head:
Given that this requires "svn" to gain a concept of "whole working copy", we
can make sure that every .svn knows which of its files _and sub-trees_ contains
$UpdateRev$ keywords. Every removal or addition of this property has to be
propagated up to all of its parents, an order(log(N)) operation. If a sub-tree
is moved or copied away to be worked on independently, it (the sub-tree) will
still be self-consistent.
Then, when a change to "foofile" requires a tree-walk to update other files, we
only need to walk up to the parent and down through any sections of the tree
that have the keyword, which in typical cases (I expect) would be none or one,
and in the worst case everything, but that down-walk is still no worse cost
than an update of the whole tree to achieve the same result in your vision.
That has a typically small but maximally order(N) cost per individually updated
file. To modify this strategy to be efficient for multiple individual updates,
store in each .svn the revision number that $UpdateRev$ is using; then a tree
down-walk is necessary only when updating to a different revision.
> 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.
I think my example would only require order(log(N)) cost for such a "propset".
I am of course omitting some details, but unless I'm fundamentally wrong I
still think this could be done efficiently if we wanted to, and that using a
presumed inefficiency as an argument against the feature - or even just
mentioned in discussion - is unfair.
Please tell me if I'm being unreasonable.
>>To assume that the implementor of this feature would do a poor job is
>>irrational.
>
> No one's assuming that.
That's how I interpreted what Max Bowsher wrote (2005-09-30T11:20Z):
> My view (which I suspect is similar to many developers') is that I cannot
> believe people want a feature where "svn update just_one_file" causes svn to
> recurse both downward and upward throughout entire working copy.
>
> If we implemented that, people would complain (rightfully so) that svn was
> way too slow.
> And, if we cut corners, and didn't do that recursion in all cases, then we
> would knowingly be introducing a bug, [...]
>
> This is why I (and I suspect others too) are opposed to implementing it -
> because we cannot see any way which doesn't either introduce bugs, or horrible
> slowdowns.
Sorry, Max, but you did make unreasonable assumptions about the implementation.
Where there's a will, there's a way.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 11 20:39:19 2005