Hyrum K Wright <hy...@hyrumwright.org> writes:
> I've been looking at which bugs can be closed by the pending
> completion of wc-ng. In particular, I've been looking at issue #1284:
> http://subversion.tigris.org/issues/show_bug.cgi?id=1284
>
> The issue is essentially a complaint about the performance of 'svn mv
> somedir targetdir' when the number of files in somedir is very large,
> in the thousands. It's a performance bug with no real good feeling
> for done, but given the performance improvements of wc-ng, I'm marking
> it as so.
I believe there is a relatively small change that could make it better
still. Look at libsvn_client/copy.c:do_wc_to_wc_moves_with_locks2
SVN_ERR(svn_wc_copy3(b->ctx->wc_ctx, b->pair->src_abspath_or_url,
dst_abspath, FALSE /* metadata_only */,
b->ctx->cancel_func, b->ctx->cancel_baton,
b->ctx->notify_func2, b->ctx->notify_baton2,
scratch_pool));
SVN_ERR(svn_wc_delete4(b->ctx->wc_ctx, b->pair->src_abspath_or_url,
FALSE, FALSE,
b->ctx->cancel_func, b->ctx->cancel_baton,
b->ctx->notify_func2, b->ctx->notify_baton2,
scratch_pool));
Have svn_wc_copy3 set metadata_only to TRUE, this will be faster. Then
do svn_io_rename to move the working tree, it's a single rename so it
should be fast. The svn_wc_delete4 call should still operate if the
working tree is missing and could be marginally faster.
Overall this should be significantly faster as it doesn't have to copy
all the working files. It has the additional benefit that it preserves
timestamps in the working tree. The only reason I haven't implemented
it yet is that I haven't decided whether we should use a workqueue.
--
Philip
