[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-25 16:31:39 CEST

> "Miller, Eric" <Eric.Miller@amd.com> writes:
> > I posted this question/issue on users@ and got a little bit of info
from
> > Erik Huelsmann but wanted to see if I could get some more helpful
> > comments.
> >
> > Basically I would like to be able to perform a partial tree update
(svn
> > up -N [dir/file set]) with the same efficiency as a completely
recursive
> > update. Currently, using a target list takes much longer (see
below).
> >
> > I'm willing to implement my own update procedure but after digging
> > through some docs I'm wary that I may be in over my head.
> >
> > So - anyone have any ideas or pointers? Has this been done already?
> > Barring that, could I possibly call svn_ra_do_update with a custom
> > reporter that only returned info for my file set? Am I going down
the
> > wrong path here?
>
> The new --depth flag coming in 1.5 may address your particular use
> case. However, what you're doing currently shouldn't take 32x time of
> course. However, I'm not sure what the client is doing that causes
> this. Is it needlessly re-opening the .svn/ metadata many times?
> You'd have to debug into libsvn_wc to find out, I think.

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).

Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 25 16:32:24 2007

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