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

Re: svn commit: r1127646 - in /subversion/trunk/subversion: svnrdump/load_editor.c tests/cmdline/svnrdump_tests.py

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 27 May 2011 14:03:20 -0400

On 05/25/2011 05:41 PM, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Thu, May 26, 2011 at 00:36:48 +0300:
>> I've not read the code, but would an array of 'svn_revnum_t[2]' be
>> a better representation?
>> Specifically: an append-only array of [from_rev, to_rev] pairs, sorted
>> by from_rev. That's less overhead (and we could take advantage of the
>> sorting to store less data), at the cost of O(log(n)) lookup.
> And the numbers... well, for a plain C array it would be 70% less than
> in Greg's analysis of the hash case, since the additional 20 bytes per
> mapping entry are gone. (and that's before I suggest to not store
> [N+1, M+1] if [N,M] is already stored)

Great ideas. I've filed issue #3903 to track this enhancement. Not, IMO, a
1.7 blocker (any more than it was a 1.0 blocker).

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2011-05-27 20:03:53 CEST

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.