Ben Collins-Sussman <sussman@collab.net> writes:
> 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?
Will this affect the order in which things are printed from 'svn st'?
Since we have the whole hash in hand before printing, we can use it to
do tricks like print all the '?' mark things first, or print all the
entries (versioned and unversioned) of a directory together, etc. In
other words, we're able to sort, because we have the complete set to
be sorted.
But some experimenting just now gives mixed results... It seems that
if I pass the -v flag, then '?' mark entries are interspersed randomly
among the versioned entries. If I don't pass -v, then the '?' entries
are all at the top of the output. However, in both cases, the
versioned entries are grouped by directory, which would still be
possible in the scheme you describe above, right?
So perhaps status right now behaves in an odd way, and I'm not sure
how that affects the plan. Maybe the current behavior has some bugs
which can be fixed in the current code, but would be harder to fix in
the new code?
Hmmm, a thought: if the problem is that we want to give GUIs some
feedback that stuff is happening, we could still use notification
callbacks, which svn_client_status() doesn't currently take. The
callbacks would get called on certain defined actions, namely, "local"
status being obtained, and "repository" status being obtained. Their
only purpose would be to confirm that the client code is doing stuff
and is not hung; presumably, they would be used for some sort of
progress meter / activity meter.
IOW, a "notification callback" doesn't have to be something the
command-line client uses to print out notifications. They could be
used by other sorts of clients, to do things other than printing out
information. Since svn_client_status() returns the completed status
in a hash, and that's what the command-line client uses for final
presentation of the status, it might make sense for notification
callbacks to do something different here.
-K
---------------------------------------------------------------------
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:49:21 2002