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
Received on Tue Feb 22 22:40:54 2005