Karl Fogel <kfogel@newton.ch.collab.net> writes:
> Greg Stein <gstein@lyra.org> writes:
> > 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.
>
> I can't remember what they're for either, but sounds like a good place
> to start looking...
It appears that all the uses of svn_fs__string_clear() (there are
three) exist when doing one of the following two things:
1. replacing a directory entries list after mods.
2. replacing a node property list after mods.
However, this isn't exactly the root of the problem. As I see it, the
real problem is an assumption throughout the filesystem that you can't
have a `representation' pointing to a non-existent `string'. So, for
example, when we make a new file, we call svn_fs__string_append() with
empty data just to generate a new string key where future contents for
that file will live. Of course, in the old system, that was fine,
because we would just overwrite this empty string with real contents
for the file. In the new system though, this is another example of
a great way to have a wasted DB row.
My suggested solution is two-fold:
1. replace the three calls to svn_fs__rep_contents_clear() with a new
function: svn_fs__rep_contents_delete() (I've coded this locally,
and it takes care of many of the "wasted record" cases).
2. expose the get_and_bump_key() function inside of strings-table.c
(as something like "svn_fs__string_reserve_key()") and allow brand
new reps to simply claim a new string key but without actually
writing anything there.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 9 17:14:36 2002