Subversion's stated goal is to have optimal locking -- readers never interfere with anyone nor are interfered with by anyone, and writers interfere with each other only when they're making changes to the same resources. The only thing standing in the way of this goal is the way representation and string keys are generated during commits. To get a new string or rep key, the "next-key" entry is used, but its value is not incremented until the end of the relevant trail, when the new "next-key" is berkeley-committed along with everything else. I think (?) the fix is to fetch the next key and increment that entry all in one tiny berkeley transaction, which will begin and end during the much longer-lived trail in which the svn commit is taking place. There might be many such next-key fetches during a single svn commit, which is fine -- we're not going to run out of keys, and Subversion doesn't care whether the keys are contiguous within a given commit, as long as they're not being shared by other commits.