[-users list]
Hi Alfred,
In short, the answer to your issues is "wait for Subversion 1.7, which
will have a brand new working copy library". Unfortunately for you,
the expected date for that is June-ish. But it does completely address
your three issues.
More details in-line below:
On Wed, Oct 8, 2008 at 5:13 PM, Alfred Perlstein <bright_at_mu.org> wrote:
>...
> 1) Reduce the ".lock" operation when doing updates.
> When svn does most "update" or "stat" operations, it traverses the
> tree making "lock files" this causes the speed of the tool be to
> much slower than it could be. We'd like to explore options for a
> custom build that would reduce that.
Yeah... it probably shouldn't take out locks for update or stat, but
I'm assuming it does to ensure read-consistency.
In 1.7, there will be one sqlite database replacing all of a working
copy's "entries" files and no locks whatsoever. The two operations
will do a quick traversal of the working copy (update will look for
missing items, status will look for text modifications). We may have
shortcut versions that skip the traversal entirely.
> 2) Reduce "entries.log" operation when doing updates/checkout:
>> For instance, when doing a "svn checkout" I'll see ".svn/tmp/entries"
>> created many times, and then renamed over ".svn/entries".
>>
>> Is there any way to reduce these items when you _know_ you're going
>> to be working in isolation?
>>
>> Could this be made any faster by just updating the files in place?
Subversion does this to ensure that a half-written/corrupted copy of
entries is not left in place if its operation is interrupted for some
reason, rather than for multiple-user operation.
Reducing the number of times entries is rewritten would probably be
difficult (we already try to avoid it), but is mooted by the new
strategy in 1.7 (no entries files at all).
> 3) Reduce the size of the checkout, we'd like to explore opportunities for not having copies of the files in the "svn-base" directory, either storing this on the server (as an option) or maybe just compressing it.
We've explored this in the past. The svn-base files are expected to be
present by too many things. There is a lot of coupling going on in the
working copy library. This is one of the basic reasons that the
library is being rewritten entirely for 1.7, and that version should
support omitting and/or compressing the text base files.
Happy to answer any further questions you may have!
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-09 03:43:42 CEST