Re: dupkeys leading to wasted records.

I'm going to guess this is somehow related to svn_fs__string_clear(). When I
switched to the dup keys, I saw some strange calls to that which I couldn't
quite discern their purpose. The code does a delete, then inserts a blank
record. I'm going to guess that something does a clear, then a set, which
ends up with a blank from the clear, then a set which produces the second
record.

I'd suggest to examine our uses of clear() to see what they're really trying
to do.

Cheers,
-g

On Wed, May 08, 2002 at 04:39:31PM -0500, cmpilato@collab.net wrote:
> I happened to notice while debugging Philip's latest bug report that
> our strings table appears to be wasting a BDB row for every string
> added to the table. That is, now that we have the whole duplicate key
> thing going on, the strings table look like this:
>
> --
> VERSION=3
> format=print
> type=btree
> duplicates=1
> keys=1
> HEADER=END
> 0
>
> 0
> ((trunk 3 3.1) (tags 3 2.1) (branches 3 1.1))
> 1
>
> 1
> ((trunk 3 3.2) (tags 3 2.1) (branches 3 1.1))
> 10
>
> 10
> Tue Feb 16 10:49:07 PST 1999\0a\0a
>
> (...)
>
> DATA=END
> --
>
> Note that the first of all the duplicate keys points to an empty row.
> I've verified that this has nothing to do with any recent changes to
> the filesystem code, and presume it began immediately after enabling
> the duplicate key system.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org