Julian Foad <julianfoad@btopenworld.com> writes:
> kfogel@collab.net writes:
> > To have both streaminess and sortedness is hard. Just ask CMike :-).
>
> C-Mike, is it hard (compared to other things that we do)?
Yes. If it wasn't hard, I would have invested that time I've spend
telling you to drop this into implementing it instead.
> Of course it is impossible to sort a stream after it has been
> generated, while keeping as a stream. Therefore a stream must be
> produced in sorted order. Sorting a tree just involves sorting each
> individual directory when it is encountered. I have a patch which
> does a large part of this.
>
> There may be harder things like merging streams from different
> sources (though that's actually a different problem). Whether we
> implement the difficult parts just depends on the cost/benefit
> trade-off. A lot of benefit can be had from implementing all the
> simple cases.
'svn status' is effectly doing *exactly* this. There are two streams
to worry about -- the one coming from the server, and the one coming
from the working copy. The code is bending over backward to ensure
depth-first-ness, which is (as has been) the primary concern for
Subversion path-y output, all while keeping as little as possible in
memory, and pushing stuff to the output stream the *moment* it is safe
to do so.
This means that it reads a single directory's worth of status items,
and no more, at a time. Any children of that directory which are
spoken of in the server stream are handled first, then those that
remain are handled. To get sortability, you'll have to either know in
advance all the children that the server is going to speak about
(bye-bye streaminess), or you have the change the server protocol to
make the same sort promises, means forcing this arbitrary policy down
at least as deep as the libsvn_repos library (and perhaps deeper) to
ensure streaminess.
> Anyway, I want to solicit agreement or objections to the principle
> before going into the implementation.
I understand your concerns, but I'm sorry -- I truly believe that this
is going to provide unnecessary code churn.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 13 19:09:05 2003