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

Sorted output from Subversion commands

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-02-22 22:39:29 CET

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

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.