I'm working on the problem of providing more feedback to the user
during long-running svn operations... this is especially important to
GUI clients like gsvn or rapidsvn. Luckily, operations like 'update'
and 'commit' call the client's notification callback on every single
file that gets processed. The commandline client already takes
advantage of this, and the GUIs can too.
But in the case of svn_client_status (a.k.a. "refresh" in GUI terms),
there's no notification going on: this routine works for a long time,
then finally returns the entire hash all at once. It can seem
extremely slow to the user.
What I'd *like* to happen is some kind of notification callback to be
called every time a status struct is added to the hash. Then the
client could simply print status info on the fly, and even feel free
ignore the full hash it eventually gets back.
The problem, however, is harder than that: svn_client_status()
possibly makes two internal passes at building the hash. First this
routine walks the entire working copy, either adding 'interesting'
status structures, or just adding a status struct for everything it
finds. Then, if -u was passed, it walks the whole working copy
*again* to send its state to the server to get an update report. When
the update report comes back, it parses the report and marks existing
status structs as 'out of date', and creates new ones as needed.
The point here is that the feedback idea only works in the
purely-local version of svn_client_status(). In the networked
version, there's no way to know if we're "finished" with a structure,
because it may need to be tweaked later by the server report.
One solution might be to reverse the order of the passes. First get
the network report and start parsing it. As each status structure is
built, do an immediate local-stat of the object. Now we now it's safe
to 'notify' the client, because the status structure is complete.
After these notifications, we do a normal local-only walk, and only
send notification on structures that are added (if the structure
already exists, notification must have been sent already.)
Does this solution sound reasonable?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 11 16:14:00 2002