Branko Čibej wrote:
> Julian Foad wrote:
>> Note that svn_sort__hash does not sort a hash in place, because a hash
>> isn't ordered, so it returns an array generated from that hash.
>> Therefore several lines of code must change at each point of use.
>> Nevertheless I found that to be an effective solution, not too
>> cumbersome.
>
> But quite useless, because svn_wc_entries_read is a _public_ function.
> Which means that every single Subversion client would have to use the
> svn_sort__hash() kluge.
Ah, _if_ those other clients want sorted output, yes. OK, I'm starting to
understand your point of view: you're thinking that our _libraries_ should
provide sorted lists so that all clients get sorted output, and all in the same
way (which I agree is important).
That explains your "can't do it before v.2" in another mail to which I
responded rather bluntly. What we can't do (before then) is make other clients
automatically have sorted output - but then I don't think we could force that
upon them anyway, because we don't know what they do with the data we provide
before they display it.
Before version 2, we can make _our_ client give sorted output, and we can make
it possible for other clients to do so as well, if they want to. (For
instance, we can make sure that we call their callbacks in sorted order, but,
where our APIs provide a hash, they have to sort it.)
>> I found that there were barely enough uses of those functions to make
>> it worthwhile creating new, sorted versions of them, but I would not
>> object to doing so.
>
> Apart from the fact that we'd have to uses sorted tables in the FS, too,
> not just in the WC, you have to maintain the sorted list every time you
> change the entries, and entries modification becomes quadratic.
I'm not sure, but it sounds like you are focussing on a particular
implementation method again. Changing entries in a sorted list doesn't require
quadratic time, even though a simple implementation of it does.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 23 00:13:50 2005