Philip Martin <philip@codematters.co.uk> writes:
> Ben Collins-Sussman <sussman@collab.net> writes:
>
> > 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?
>
> The wc diff editor (i.e. single revision svn diff -rREV) does
> something similar, although it does the local check at each
> close_directory. Doing the local check only once will affect the
> order in which items are displayed [...]
Yeah, this occurred to me too. The only reason we see sorted output
is specifically because the commandline client is sorting the *entire*
hash at once. Printing status info as soon as it's available will
create a very chaotic listing, because the process of gathering the
information is inherently unpredictable.
Hmm, I don't like my proposal anymore.
My original Evil Plan was that the client app could store the
status-hash pointer in the notification baton, so that when it
received a notification event that path "foo" was stat'ted, it could
look up that key in its notification_baton->statushash to get the
actual status struct. I was going to change the commandline client to
print status info on the fly. But it's not worth giving up the sort.
Perhaps the status notification system can be much simpler than I
intended. Every time a status structure is either created or tweaked,
we send a notification event that contains no real info but the
pathname. A GUI client can display a "throbber" that rapidly
flashespathnames, and the commandline client could display progress
dots (just like a our "Sending file data...." display). At least a
client would have a way to indicate that *something* is happening,
i.e. some kind of work is being done.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 11 17:15:53 2002