[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-11-09 18:19:46 CET

> I just filed issue #3003 for this.
>
> I have a proof of concept written in perl that uses a new
> svn_wc_crawl_revisions3() and am in the process of reworking
> libsvn_client/update.c to utilize it as well. I don't expect to need
a
> new update interface api - the change should be transparent.

I've made progress on this - I have a semi-working fix that I'm starting
to get ready to checkin to a devel branch.

Some background info:

First - I created svn_wc_crawl_revisions3 to take multiple paths,
starting and stopping the editor reporter on the first and last path
entries.

Next I updated the svn_client__update_internal routine to take a list of
paths and create the adm_access tree accordingly (update and update2
were modified accordingly). The partial adm_access tree is passed to
the new crawler. The result is a partially locked working copy tree and
a single ra_session and update editor reporter driven by only the paths
specified.

Currently I am simply using svn_path_get_longest_ancestor on the
user-supplied path list to determine the root for the adm_access set. I
know this is deficient because path sets may not have a common root
unless translated into absolute paths first. (Ex: svn up -N * */* does,
but svn up * ../* does not).

So my questions:

  What is the best way to find a common root path? I was thinking of
converting everything to absolute paths first.

  My edits have been against 1.4.2 - I have not taken a single look at
the depth features of 1.5. Does anyone know if --depth will conflict
with this implementation?

Thanks,

Eric M.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 9 18:27:32 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.