Kevin M Radke/CedarRapids/RockwellCollins wrote on 08/14/2013 11:52:44 AM:
> dlellis_at_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.
Received on 2013-08-14 21:10:37 CEST