[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: FW: Multi-path updates

From: Miller, Eric <Eric.Miller_at_amd.com>
Date: 2007-10-26 00:36:26 CEST

> "Miller, Eric" <Eric.Miller@amd.com> writes:
> > I'm sorry, I should have posted Erik's response in here as well. He
> > seems to think it is due to the svn_sleep_for_timestamp, and I think
> > that is at least part of the problem.
> >
> > Reviewing update.c, I don't understand why the sleep is *inside* the
> > path loop. Once inside that loop it shouldn't matter if the
timestamps
> > are the same or not (as it does not matter with a hierarchical run).
>
> Actually, I don't think that's what the code does.
>
> Looking at subversion/libsvn_client/update.c:svn_client_update3(), it
> passes '&sleep' to svn_client__update_internal(). This happens inside
> the path loop.
>
> When svn_client__update_internal() gets a non-NULL boolean pointer, it
> doesn't sleep, it just sets the boolean, to indicate to the caller
> that a sleep is required. The 'sleep_here' local var remains FALSE.
> (svn_client__update_internal() will sleep unconditionally in the event
> of an error, but presumably that's not what's happening here.)
>
> Note also that the call to svn_client__handle_externals() is passed
> the same boolean pointer, and does the same thing with it; no actual
> sleeping happens in externals.c.

Ah yep, both you and the implementation are correct. I got tripped up
on the *use_sleep definition in svn_client__update_internal().

Unfortunately there went my easy out. Do you think it would be possible
to drive a partial tree update with a single ra session? I'm assuming
opening and closing this session is what is the most time consuming.

Thanks,

Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 26 00:36:57 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.