Vadim Chekan wrote:
> I'm not sure how to solve it. One way is to modify
> svn_fs_base__get_mutable_rep to create new keys without saving
> strings/representations tables.
> Another way is to return new unsaved string/representation implying
> that consequent calls will modify representation and sa
Vadim Chekan writes:
> Other optimizations can be implemented, but I can not figure it out,
> where db transaction scope is set? I have impression that there is
> none which means that each bdb call is a transaction. If so, write
> operations are very slow, because transaction commit requires buf
Hi Michael,
I found why it is happening, but I can't see a simple way to change
the code. It seems to be design, not just code to work this way.
reps-strings.c:svn_fs_base__get_mutable_rep
=
SVN_ERR(svn_fs_bdb__string_append(fs, &new_str, 0, NULL, tra
Yes, I'll try to figure it out. Just wanted to make sure that it
wasn't intentional for whatever reason.
I've already looked up strings bdb implementation and could not see
anything suspicious. Now it's time for debugger :)
Vadim
On Tue, Dec 22, 2009 at 8:37 AM, C. Michael Pilato wrote:
> IIRC,
IIRC, it's not really 2x nodes -- it's one extra row for each string key.
So if a directory listing would normally consume a single string row, yes,
theres 1 + 1 = 2 (or, 2x) rows used. But if a file's contents would consume
10 strings rows, then it's still just the 1 additional empty row. THAT
S
5 matches
Mail list logo
