[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-10-15 19:38:09 CEST

C. Michael Pilato wrote:
> Julian Foad <julianfoad@btopenworld.com> writes:
>
>>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.
>
> No, it just means I don't *not* want it. Big difference.

:-)

>>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.)
>
> Oh, you're not adding to my load. There are benefits to having both
> streaminess and predictable, sorted outcome. In fact, one might argue
> that the system isn't fully streamy unless the outcome *is* sorted
> (since sorted output makes binary searches possible, and linear
> searches able to bail immediately when the search item isn't present).
>
> I'm sorry to say, though, that this is just not my itch today. In the
> overall scheme of Things To Do, this falls so far down on my version
> of that list that for all intents and purposes, it doesn't exist. I
> don't mind contributing what knowledge I have in, bounded by what time
> I have, to help you or others out. But that's all you're likely to
> get from me. I trust you understand.

That's fine, and thank you for offering to help.

> Depending on the sort order you wish to make 'the policy', you might
> literally be running into a brick wall. *All* of Subversion uses the
> "editor" concepts throughout, and their only promises is
> depth-firstness. This is wholly incompatible with any notion of
> "report all children, then descend" -- to change this is getting
> pretty close to deciding to rewrite libsvn_wc. In Visual Basic.

Agreed. My footnote about "report all children, then descend" was just a remark, not a realistic possibility.

> Your best bet is to push for depth-first where siblings are sorted in
> alphanumeric order (the same way that svn_compare_paths() reports
> ordering). I believe that you could implement this without a single
> protocol change, but don't hold me to that.

I'm glad you think this is the most likely approach, because that's what I was thinking too.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 15 19:37:57 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.