Greg Hudson <ghudson@MIT.EDU> writes:
> Actually, how do we make our exception list without making a complete
> pass over the working directory? Perhaps an "I have version
> exceptions in my subtree" bit in the directory version? If so, that
> bit has to bubble up through parent directories when you run "svn
> update" in a subdir, which is ugly; however, I don't think there's an
> alternative. The fundamental difficult case is:
>
> svn co http://blah
> sleep 3600 # While someone else checks in changes
> cd foo/bar/baz/quux
> svn update
> cd ../../../..
> svn update # How do we know about the exception in
> # foo/bar/baz/quux without searching the whole
> # tree?
You do have to search the whole tree. But this is unavoidable. Let
me phrase your example another way, to make it seem less horrible and
more inevitable:
Rule: "To do an update, the client must send the server the state
of every entity involved in the update."
Now, as far as the bandwidth used by that state report, the client can
save some bits by reporting only exceptions. But that only makes the
report's expression more efficient -- the data-gathering stage cannot
be made more efficient, because in order to *report* everything's
state, the client has to *know* everything's state.
In other words:
Your "svn update" up there is being run recursively from the top of a
large tree. No non-recursion flag was passed, and no targets were
specified, so an implied "." target is used...
Well, if the client is updating every entity in a tree, it shouldn't
be surprising that it first must walk that tree to find out what state
things are currently in, before it can do the update. That's just
life. :-)
If we stored all the revision metadata in one centralized file, we
wouldn't have this problem. But then we wouldn't have detachable
subdirectories, which would be a pity. And anyway, compared to the
network lag, how bad can the local tree-walking be? Sure, it's not
instantaneous, but if you're doing real work, the netlag is going to
bite you a lot harder than local entries-checking anyway.
-K
Received on Sat Oct 21 14:36:18 2006