Re: Sorted order for output of "status" etc.
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-10-14 02:17:12 CEST
C. Michael Pilato wrote:
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
Agreed: that's good.
> This means that it reads a single directory's worth of status items,
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. 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 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
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.
 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.
 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.
 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.
This is an archived mail posted to the Subversion Dev mailing list.