Les Mikesell <lesmikesell_at_gmail.com> wrote on 08/14/2013 10:17:41 AM:
> From: Les Mikesell <lesmikesell_at_gmail.com>
> To: dlellis_at_rockwellcollins.com
> Cc: Ben Reser <breser_at_apache.org>, Ivan Zhakov <ivan_at_visualsvn.com>,
> Johan Corveleyn <jcorvel_at_gmail.com>, "users_at_subversion.apache.org"
> Date: 08/14/2013 10:18 AM
> Subject: Re: How to change paths on an external file without a full
> update --depth infinity?
> On Wed, Aug 14, 2013 at 11:48 AM, <dlellis_at_rockwellcollins.com> wrote:
> > I believe that if we can improve external performance (speed and
> > -- like handling externals when depth != infinity), not only would we
> > the current users of SVN that have come to accept this, but we would
> > huge opportunity to get back on the radar of other users that have
> > previously chosen other options.
> I'm not sure that current SVN users accept problems with depth !=
> infinity as much as they arrange their layout so they don't have to do
> that. What's a common use case for needing some disjoint arrangement
> of components that you can't assemble with externals and normal
This is a case of trying to improve performance on externals by only
updating externals that have changed. Without connection caching,
performing an external update over a WAN is a test of patience. For us,
our repo is accessed over a WAN. Its not an issue for non-"file
externals". For example, a WC of 1000 file externals will take over 15
minutes to update with zero changes but the same WC with no file externals
(1000 normal files) takes 30 seconds tops. Keep in mind, no actual file
revisions are being downloaded, just checked.
We have been attempting to put in place a workaround to give us the
benefit of file externals with a general algorithm of:
update external table (svn ps svn:external -F tmpfile)
commit external table (svn commit . --depth empty --ignore_externals)
update the externals table for paranoia (svn update . --depth empty
foreach external in svn:properties (compare svn:externals to svn info -v)
if the local revision (svn info) is not the same as the external
update the external (svn update foo.c)
This has proven to be difficult to do since:
a. a corruption issue was identified (bug 4409)
b. we can't change a path on a file external (bug 4001) with out a full
update (depth infinity) (old file gets deleted, new one doesn't get
Either of these issues prevents doing a simple update of a file external
or doing a current directory update (50 files is more bearable than a full
That said, this attempted work around would not be needed if the
connection caching can bring file external updates to something closer to
the performance of regular files.
Hope this helps, I'd be glad to explain in more detail how we implement
this. I think we have a very successful strategy for our needs.
Received on 2013-08-14 20:14:29 CEST