Re: Philip, is issue #1556 easy for you?

kfogel@collab.net writes:

> Sander, Mike, Ben, and I were just discussing issue #1556, the
> "mysterious post-update/checkout delay on huge trees" bug.
>
> Of course, it's not mysterious anymore -- we know it's due to the
> post-update unlocking, which is (apparently?) triggered by a pool
> cleanup function.

Locking can get triggered by pool cleanup, but for update it's coded
explicitly since svn_client_update calls svn_wc_adm_close. I see that
svn_client__checkout_internal doesn't explictily call close, I think
it should (although that won't make it any faster.)

> The problem is, the unlocking happens after the
> client has printed the last line, so in large trees the user just gets
> an unexplained pause:
>
> $ svn up
> [...]
> U subversion/include/svn_delta.h
> U subversion/include/svn_wc.h
> Updated to revision 7684.
> [insert long delay here]
> $

I don't get anything like the delay reported in the issue. I haven't
tried the mozilla tree, but I have tried trees with 2500 directories
and they unlock in about 5 seconds. That's using 7200rpm (i.e. old)
SCSI disks. There seems to be an order of magnitude difference in the
time reported in the issue (5000 directories in 2 minutes) and the
time I measure (2500 directories in 5 seconds). Is this a Windows
difference? Or much slower disks? Or is it something other than the
unlocking code causing the delay?

> Speeding up the unlocking isn't in the cards, but that's okay. We're
> just hoping to give the user some feedback, so they don't wonder
> what's going on, as in:
>
> $ svn up
> [...]
> U subversion/include/svn_delta.h
> U subversion/include/svn_wc.h
> Unlocking working copy (please wait)...
> [insert long delay here]
> Updated to revision 7684.
> $
>
> It's easy to add a notification code for this, but we're not show
> where/how to call it, because we're not quite sure where the unlocking
> gets triggered.

svn_client_update() calls svn_wc_adm_close() which calls do_close() on
the working copy path. do_close() calls do_close() recursively on
each child before removing its own lock.

> Granted that we could probably solve this with some research... but,
> you probably already have the knowledge in your head and could get
> it right the first time. Care to take it on? If not, that's fine,
> just let me know so we can allocate time. (Or if you don't have
> time to do it, but do have time to post some pointers, even that
> would help.)

I'm not sure what you want the feedback to look like, just one single
"please wait" message? Is that just a single notify call added to
svn_client_update()? I'm guessing you don't want a notify call for
each directory unlocked.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org