Re: Sorted order for output of "status" etc.

C. Michael Pilato wrote:
> 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.

Ah, that must mean you _do_ want it :-) Cool.

I'm sorry to add to your already busy load, but please bear with me for a small amount of discussion. I am not fooling around. I believe this to be a serious matter with realistic prospects of a useful outcome. (Of course I may be wrong.)

>>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.

Agreed: that's good.

> 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),
[1]
> 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.

The server making the same 'sort' promises is the bit that I hadn't thought of as a problem, but I see now that it has to be dealt with carefully. Since my primary goal is to make the output non-arbitrary, any simple fixed sort order would suffice.[2] Such an order could be introduced at the server, and then later promised by the protocol, and then perhaps at some later date relied upon by the client. Only the last stage, the client relying on it, has backwards compatibility implications, and those could be satisfied by a gap of two releases[3] and/or by an implementation which takes care to fall back gracefully to unsorted output (rather than breaking) when run against a non-sorted server.

Note also that even without the client relying on such a promise, it can still get the benefit of a sorted order in all client-only and all server-only operations, i.e. most operations other than "status -u" and "update".

Here's perhaps the most important thing:

On the principle of "Be conservative in what you send, flexible in what you accept," it might be a good idea for the Version 1.0 server not to promise to send in sorted order, so that clients don't expect it, but for it nonetheless to send in sorted order, so that we later have the *possibility* of having the clients make use of that sorted order. The order would be defined (trivially) here and now, but not officially "advertised".

> I understand your concerns, but I'm sorry -- I truly believe that this
> is going to provide unnecessary code churn.

OK. I will file an issue that explains the benefits and the difficulties, so that anyone else wanting to investigate this knows where they are starting from.

  No-one said it would be easy.
  No-one said it'd be this hard.
  No-one said it would be easy.
  No-one thought we'd come this far.
  Oh, and look, we've come this far.
                                - Sheryl Crow

- Julian

[1] Perhaps a postfix notation applied to directories could enable that: "Here are all the children's names, and now here are the contents of the first one: ( recurse ), ..." But now is of course not the time to consider protocol changes of this magnitude.

[2] To move from a fixed sort order (at the server) to a user-specifiable one would be a huge jump, requiring protocol change, but fortunately that is beyond the scope of this proposal.

[3] OK, maybe we don't have two releases to spare before things get more serious at 1.0. But that's partly the point: to think about it now before we are stuck with the status quo and have to wait for two major releases instead of minor ones.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 14 02:16:41 2003