subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dlel...@rockwellcollins.com
Subject Re: How to change paths on an external file without a full update --depth infinity?
Date Wed, 14 Aug 2013 19:04:07 GMT
Kevin M Radke/CedarRapids/RockwellCollins wrote on 08/14/2013 11:52:44 AM:


> dlellis@rockwellcollins.com wrote on 08/14/2013 01:13:52 PM:
> > > 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
> > > recursion?
> > > 
> > 
> > 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. 
> > 

> 
> Even with connection caching, you will still be asking the 
> server a separate question for each external instead of one 
> question for the whole working copy.  I think there will 
> always be a performance cost to using externals, and using 
> thousands is just asking for problems. 

We're ok with _some_ performance cost.  Also, it might be valuable to the 
SVN community to understand other use cases when they make architectural 
decisions.  I'm not sure its technically impossible to combine all the 
external requests by directory into a single transaction.  Let's ask the 
community and developers what they think.

> Designing a build 
> management system on top of subversion using only externals 
> is risky.

I disagree, but we've had this conversation already.  I'd be very welcome 
to try anything to help our performance.

Mime
View raw message