Ben Collins-Sussman <sussman@collab.net> writes:
> > > 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.
It's not so bad :)
Just because the client gets notify callbacks in the wrong order
doesn't mean it has to display them in that order. The command line
client can accumulate the information supplied by the callbacks, and
then sort it and print it when the svn_client_statuses call returns.
A GUI client can decide to update the GUI with the information as it
receives it, or to update some progress indicator and do post
svn_client_statuses processing like the command line client. Give the
information to the application and let the application make the
decision.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 11 19:06:50 2002