You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2005/02/22 21:39:29 UTC
Sorted output from Subversion commands
So, a while ago there was a discussion on the GCC list and later on
#svn-dev about how "svn diff" output should be sorted.
At the time, I naïvely thought that sorting the entries list and
returning a modified hash table that supports in-order traversal would
do the trick. Then I went digging into the code, and it turns out that's
not enough. Unfortunately, our public APIs return an apr_hash_t. And,
this not being C++, there's no way to override that tables traversal order.
There is a fairly "simple" way to get sorted output from almost all
Subversion commands, and that is to teach svn_wc_entries_read,
svn_io_get_dirents and friends to return a table that's inherenly
ordered (probably implemented as a binary tree). We'd have to create new
versions of those APIs, but we know how to do that.
The issue is this: svn_wc_entries_read caches the entries table in the
adm_access baton. If we write svn_wc_entries_read2 that creates a tree
of entries instead of a hash table and puts that in the cache, that
cache is no longer compatible with the one svn_wc_entries_read expects.
This means that a client could call one or the other function, but
should _not_ mix both in the same process.
Now the question: Can we, according to our versioning rules, demand that
a client never uses two different versions of the same function at the
same time? In other words, if we add svn_wc_entries_read2, can we modify
svn_wc_entries_read to return an error if the entries cache contains the
wrong type of structure?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Julian Foad wrote:
>> Branko Čibej wrote:
>>> Greg Hudson wrote:
>>>> We have svn_sort__hash(). It's used in libsvn_subr/hash.c for hash
>>>> dumps, for instance.
>>>>
>>> Yes, but using this would mean we'd have to re-sort the table every
>>> time it's modified, which is a) inefficient, and b) doesn't work
>>> because we don't _know_ that the client modified the table
>> doesn't work?
> svn_wc_entries_read returns an apr_hash_t*. Most of the time, this hash
> table is cached in the adm_access baton. The user of the
> svn_wc_entries_read function can modify the hash table, and in doing so
> will modify the cache. This means that we cannot also cache a sorted
> list of the hash table, because we can never be certain that the list is
> up-to-date.
Right, that wouldn't work, but it wasn't apparent that Greg or anyone was
suggesting doing that.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> Branko Čibej wrote:
>
>> Greg Hudson wrote:
>>
>>> Branko Čibej wrote:
>>>
>>>> At the time, I naïvely thought that sorting the entries list and
>>>> returning a modified hash table that supports in-order traversal
>>>> would do the trick. Then I went digging into the code, and it turns
>>>> out that's not enough. Unfortunately, our public APIs return an
>>>> apr_hash_t. And, this not being C++, there's no way to override
>>>> that tables traversal order.
>>>
>>>
>>> We have svn_sort__hash(). It's used in libsvn_subr/hash.c for hash
>>> dumps, for instance.
>>>
>> Yes, but using this would mean we'd have to re-sort the table every
>> time it's modified, which is a) inefficient, and b) doesn't work
>> because we don't _know_ that the client modified the table (and
>> that's another reason why we shouldn't return a pointer straight into
>> the entries cache from the client).
>
>
> That's interesting. You are talking particularly about
> svn_wc_entries_read, I believe. Sorting the result is inefficient,
> certainly, but not grossly, I think. But doesn't work? I don't
> follow that. Who is "we" who don't know that "the client" has
> modified the table? What's this pointer? I'm afraid I'm not familiar
> enough with the code, and you've lost me.
svn_wc_entries_read returns an apr_hash_t*. Most of the time, this hash
table is cached in the adm_access baton. The user of the
svn_wc_entries_read function can modify the hash table, and in doing so
will modify the cache. This means that we cannot also cache a sorted
list of the hash table, because we can never be certain that the list is
up-to-date.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> Greg Hudson wrote:
>> Branko Čibej wrote:
>>> At the time, I naïvely thought that sorting the entries list and
>>> returning a modified hash table that supports in-order traversal
>>> would do the trick. Then I went digging into the code, and it turns
>>> out that's not enough. Unfortunately, our public APIs return an
>>> apr_hash_t. And, this not being C++, there's no way to override that
>>> tables traversal order.
>>
>> We have svn_sort__hash(). It's used in libsvn_subr/hash.c for hash
>> dumps, for instance.
>>
> Yes, but using this would mean we'd have to re-sort the table every time
> it's modified, which is a) inefficient, and b) doesn't work because we
> don't _know_ that the client modified the table (and that's another
> reason why we shouldn't return a pointer straight into the entries cache
> from the client).
That's interesting. You are talking particularly about svn_wc_entries_read, I
believe. Sorting the result is inefficient, certainly, but not grossly, I
think. But doesn't work? I don't follow that. Who is "we" who don't know
that "the client" has modified the table? What's this pointer? I'm afraid I'm
not familiar enough with the code, and you've lost me.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Tue, 2005-02-22 at 16:39, Branko Čibej wrote:
>
>
>>So, a while ago there was a discussion on the GCC list and later on
>>#svn-dev about how "svn diff" output should be sorted.
>>
>>
>
>Also see http://svn.haxx.se/dev/archive-2003-10/0569.shtml and
>http://svn.haxx.se/dev/archive-2004-06/0000.shtml and their follow-ups.
>
>
>
>>At the time, I naïvely thought that sorting the entries list and
>>returning a modified hash table that supports in-order traversal would
>>do the trick. Then I went digging into the code, and it turns out that's
>>not enough. Unfortunately, our public APIs return an apr_hash_t. And,
>>this not being C++, there's no way to override that tables traversal order.
>>
>>
>
>We have svn_sort__hash(). It's used in libsvn_subr/hash.c for hash
>dumps, for instance.
>
>
Yes, but using this would mean we'd have to re-sort the table every time
it's modified, which is a) inefficient, and b) doesn't work because we
don't _know_ that the client modified the table (and that's another
reason why we shouldn't return a pointer straight into the entries cache
from the client).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Branko Čibej <br...@xbc.nu>.
Philip Martin wrote:
>Branko ÄŒibej <br...@xbc.nu> writes:
>
>
>
>>You can modify the sorted list in O(log N) time, but you can't cache
>>the result. So every time some function reads the entries, it has to
>>spend O(N*log N) time to sort the list before doing a traversal. This
>>is not quadratic, but you have to multiply it by the number of times
>>you have to repeat the sort.
>>
>>
>
>I haven't looked at the code, but it's quite possible that something
>like svn_client_diff only needs to sort each hash once, in which case
>it doesn't need to be cached and O(N log N) might be acceptable.
>Repository diffs like "diff -rN" and "diff -rN:M" are more of a
>problem as they rely on unsorted data from svn_repos_dir_delta.
>
>
My idea was to sort the data in the FS, too.
>It's possible that svn_client_status could be sorted much like
>svn_client_diff, and that "st -u" would have the same repository
>problem as "diff -rN".
>
>
I guess the trouble is that I really, really dislike the idea of sorting
in some places but not in others. Ah, well...
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Philip Martin <ph...@codematters.co.uk>.
Branko Äibej <br...@xbc.nu> writes:
> You can modify the sorted list in O(log N) time, but you can't cache
> the result. So every time some function reads the entries, it has to
> spend O(N*log N) time to sort the list before doing a traversal. This
> is not quadratic, but you have to multiply it by the number of times
> you have to repeat the sort.
I haven't looked at the code, but it's quite possible that something
like svn_client_diff only needs to sort each hash once, in which case
it doesn't need to be cached and O(N log N) might be acceptable.
Repository diffs like "diff -rN" and "diff -rN:M" are more of a
problem as they rely on unsorted data from svn_repos_dir_delta.
It's possible that svn_client_status could be sorted much like
svn_client_diff, and that "st -u" would have the same repository
problem as "diff -rN".
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>>You can modify the sorted list in O(log N) time, but you can't cache
>>the result. So every time some function reads the entries, it has to
>>spend O(N*log N) time to sort the list before doing a traversal. This
>>is not quadratic, but you have to multiply it by the number of times
>>you have to repeat the sort.
>>
>>
>
>Why can't you cache it and just invalidate it whenever you invalidate
>the thing it's based on?
>
You can't cache it because you don't know when it's modified because the
hash table is accessible through a public API.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> You can modify the sorted list in O(log N) time, but you can't cache
> the result. So every time some function reads the entries, it has to
> spend O(N*log N) time to sort the list before doing a traversal. This
> is not quadratic, but you have to multiply it by the number of times
> you have to repeat the sort.
Why can't you cache it and just invalidate it whenever you invalidate
the thing it's based on?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> Branko Čibej wrote:
>
>> Julian Foad wrote:
>
>>> 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.
You can modify the sorted list in O(log N) time, but you can't cache the
result. So every time some function reads the entries, it has to spend
O(N*log N) time to sort the list before doing a traversal. This is not
quadratic, but you have to multiply it by the number of times you have
to repeat the sort.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Julian Foad <ju...@btopenworld.com>.
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
Re: Sorted output from Subversion commands
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> Greg Hudson wrote:
>
>> On Tue, 2005-02-22 at 16:39, Branko Čibej wrote:
>
>>> At the time, I naïvely thought that sorting the entries list and
>>> returning a modified hash table that supports in-order traversal
>>> would do the trick. Then I went digging into the code, and it turns
>>> out that's not enough. Unfortunately, our public APIs return an
>>> apr_hash_t. And, this not being C++, there's no way to override that
>>> tables traversal order.
>>
>>
>> We have svn_sort__hash(). It's used in libsvn_subr/hash.c for hash
>> dumps, for instance.
>
>
> 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.
> Branko Čibej wrote:
> > There is a fairly "simple" way to get sorted output from almost all
> > Subversion commands, and that is to teach svn_wc_entries_read,
> > svn_io_get_dirents and friends to return a table that's inherenly
> > ordered [...]
>
> 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.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Julian Foad <ju...@btopenworld.com>.
Greg Hudson wrote:
> On Tue, 2005-02-22 at 16:39, Branko Čibej wrote:
>
>>So, a while ago there was a discussion on the GCC list and later on
>>#svn-dev about how "svn diff" output should be sorted.
>
> Also see http://svn.haxx.se/dev/archive-2003-10/0569.shtml and
> http://svn.haxx.se/dev/archive-2004-06/0000.shtml and their follow-ups.
Thank you for finding those threads in which I proposed generating all output
in sorted order. I will update my patch to apply to trunk.
At the time, the conclusion was roughly that that would be good, but only if
all cases including mixed WC-and-repository operations are covered. I have not
yet managed to cover all the cases. I think I could argue now that sorting a
significant and cleanly defined subset of operations would be acceptable, with
the hope but not a requirement that the rest should be done later.
>>At the time, I naïvely thought that sorting the entries list and
>>returning a modified hash table that supports in-order traversal would
>>do the trick. Then I went digging into the code, and it turns out that's
>>not enough. Unfortunately, our public APIs return an apr_hash_t. And,
>>this not being C++, there's no way to override that tables traversal order.
>
> We have svn_sort__hash(). It's used in libsvn_subr/hash.c for hash
> dumps, for instance.
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.
Branko Čibej wrote:
> There is a fairly "simple" way to get sorted output from almost all
> Subversion commands, and that is to teach svn_wc_entries_read,
> svn_io_get_dirents and friends to return a table that's inherenly
> ordered [...]
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.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-02-22 at 16:39, Branko Čibej wrote:
> So, a while ago there was a discussion on the GCC list and later on
> #svn-dev about how "svn diff" output should be sorted.
Also see http://svn.haxx.se/dev/archive-2003-10/0569.shtml and
http://svn.haxx.se/dev/archive-2004-06/0000.shtml and their follow-ups.
> At the time, I naïvely thought that sorting the entries list and
> returning a modified hash table that supports in-order traversal would
> do the trick. Then I went digging into the code, and it turns out that's
> not enough. Unfortunately, our public APIs return an apr_hash_t. And,
> this not being C++, there's no way to override that tables traversal order.
We have svn_sort__hash(). It's used in libsvn_subr/hash.c for hash
dumps, for instance.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Branko Čibej <br...@xbc.nu>.
Kevin Puetz wrote:
>If it's possible to return an error, I presume it's possible to in some way
>detect when the wrong structure is stored. Wouldn't it then be possible to
>just invalidate the cache in such a case (presuming it's actually a cache)
>and read from whatever the authoritative source is? Admittedly, that
>wouldn't be very fast, but the even when mixing library versions like this
>it would still work then...
>
>
Ah, as a matter of fact, this _would_ work quite nicely! it's not even
necessary re-read from the file, we could convert the data in memory.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Kevin Puetz <pu...@puetzk.org>.
kfogel@collab.net wrote:
> Branko Čibej <br...@xbc.nu> writes:
>> Now the question: Can we, according to our versioning rules, demand
>> that a client never uses two different versions of the same function
>> at the same time? In other words, if we add svn_wc_entries_read2, can
>> we modify svn_wc_entries_read to return an error if the entries cache
>> contains the wrong type of structure?
>
> Suppose you write library X, against the Subversion 1.0 API. Then I
> write library Y, against the 1.2 API. Now application A comes along
> and uses *both* X and Y, passing data structures back and forth
> between them.
>
> This would mean that adm_access batons would not be exchangeable in
> this way, even though they are the exact same type in both libraries.
> I think that would be very difficult to document, and difficult for
> people to code around.
>
> So, I am forced to conclude that we can't make such a demand.
If it's possible to return an error, I presume it's possible to in some way
detect when the wrong structure is stored. Wouldn't it then be possible to
just invalidate the cache in such a case (presuming it's actually a cache)
and read from whatever the authoritative source is? Admittedly, that
wouldn't be very fast, but the even when mixing library versions like this
it would still work then...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> >So, I am forced to conclude that we can't make such a demand.
>
> In other words, we can't have sorted output before 2.0.
No, that's not what I said, sir :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> All right, we can't have /efficient/ sorted output before 2.0. Since
> you'd have to sort the hash entries before every traversal, entries
> handling would have worse than quadratic complexity, and that's
> unnaceptable.
Ooh, this is a hasty exchange of views, isn't it? :-)
Even if sorted output required sorting the hash before every traversal (which
it doesn't - only necessary on those traversals whose order affects the
output), that wouldn't result in quadratic or worse behaviour unless the sort
is very naive. The sort is probably something like O(N log N), and that would
be added to (not multiplied by) the time currently taken by each affected
traversal.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Branko Čibej <br...@xbc.nu>.
Julian Foad wrote:
> Branko Čibej wrote:
>
>> kfogel@collab.net wrote:
>
>>> So, I am forced to conclude that we can't make such a demand.
>>>
>> In other words, we can't have sorted output before 2.0.
>
>
> Rubbish! Sorry; I mean I humbly suggest that that concusion is
> wrong. One particular implementation method is unavailable, that's all.
All right, we can't have /efficient/ sorted output before 2.0. Since
you'd have to sort the hash entries before every traversal, entries
handling would have worse than quadratic complexity, and that's
unnaceptable.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Julian Foad <ju...@btopenworld.com>.
Branko Čibej wrote:
> kfogel@collab.net wrote:
>
>> Branko Čibej <br...@xbc.nu> writes:
>>> Can we [...] demand
>>> that a client never uses two different versions of the same function
>>> at the same time?
[...]
>> So, I am forced to conclude that we can't make such a demand.
>>
> In other words, we can't have sorted output before 2.0.
Rubbish! Sorry; I mean I humbly suggest that that concusion is wrong. One
particular implementation method is unavailable, that's all.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>Branko Čibej <br...@xbc.nu> writes:
>
>
>>Now the question: Can we, according to our versioning rules, demand
>>that a client never uses two different versions of the same function
>>at the same time? In other words, if we add svn_wc_entries_read2, can
>>we modify svn_wc_entries_read to return an error if the entries cache
>>contains the wrong type of structure?
>>
>>
>
>Suppose you write library X, against the Subversion 1.0 API. Then I
>write library Y, against the 1.2 API. Now application A comes along
>and uses *both* X and Y, passing data structures back and forth
>between them.
>
>This would mean that adm_access batons would not be exchangeable in
>this way, even though they are the exact same type in both libraries.
>I think that would be very difficult to document, and difficult for
>people to code around.
>
>So, I am forced to conclude that we can't make such a demand.
>
>
In other words, we can't have sorted output before 2.0.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Sorted output from Subversion commands
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> Now the question: Can we, according to our versioning rules, demand
> that a client never uses two different versions of the same function
> at the same time? In other words, if we add svn_wc_entries_read2, can
> we modify svn_wc_entries_read to return an error if the entries cache
> contains the wrong type of structure?
Suppose you write library X, against the Subversion 1.0 API. Then I
write library Y, against the 1.2 API. Now application A comes along
and uses *both* X and Y, passing data structures back and forth
between them.
This would mean that adm_access batons would not be exchangeable in
this way, even though they are the exact same type in both libraries.
I think that would be very difficult to document, and difficult for
people to code around.
So, I am forced to conclude that we can't make such a demand.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org