#125 Make vlatest/vwhohas/RepoUI::highver more efficient
There are a few cases where the repository tools do
more searching of remote repositories than they need
to. This can make the tools operate slowly at
repositories that are far removed from the master.
- With the -m flag vlatest will search for the master
copy of all objects that are neither an
immutableDirectory nor an immutableFile in a directory
it is searching. This may be unnecessary if, for
example, it is an appendable directory into which
vlatest will not recurse. It should instead wait until
it knows whether it needs the master copy. (Also,
this can result in an error when the repository of a
subdirectory is unreachable even if the -n flag is given!)
- vwhohas has essentially the same problem with its -m
flag. While it is necessary to find the master copy of
any appendable directory to be searched, it is not
necessarily required to find the master copy of every
non-immutable directory entry.
- ReposUI::highver is slightly better by delaying the
search of remote repositories until it finds a
non-master stub which has a higher number than any
other directory entry previously seen. However, there
may be another directory entry encountered later which
would be higher than the non-master stub. It would be
better to delay the search of remote repositories until
after listing the entire directory and then do so only
when there are one or more non-master stabs with higher
numbers than all local non-stub objects.
All of these will require adding additional complexity
to the code. In the case of ReposUI::highver and
possibly vlatest it may mean using additional data
structures (to remember stubs numbered higher than the
highest non-stub). I believe it's worth the additional
complexity, as we have seen some significant delays for
remote clients with high latency when using these on
large directories (1000+ entries). It may even be
worth scrutinizing all uses of VestaSource::list in the
repository tools to look for other cases like this
where we could reduce the amount of searching of remote
repositories.
Logged In: YES
user_id=304837
Originator: YES
I apparently forgot to update this when we made some
improvements to vlatest and vwhohas back in this version:
/vesta/vestasys.org/vesta/repos_ui/44
We did not go quite as far as I suggested in this entry
because we did not delay looking for the master copy until
after listing the entire directory. That could still be
done, but as noted would require additional data structures.
Also, we did not make any improvements to ReposUI::highver.