On 24.01.2014 14:09, Stefan Sperling wrote:
> On Thu, Jan 23, 2014 at 01:11:36PM +0000, Kuno Meyer wrote:
>> Hi all,
>>
>> One of the repositories I am working with has a long list of "svn:external"
>> links. This has a major impact on working copy update performance, since
>> each external link needs an additional roundtrip to the (painfully slow) SVN
>> server. So it can easily be the case that the update of the main working
>> copy (several 10k files) is done in <10 seconds, but querying the 40-45
>> external repository takes another 60-80 seconds.
>>
>> However, since the external links are all fixed to a specific revision
>> number, and since the working copy knows its current reference revision
>> number, why do you have to roundtrip to the SVN server anyway? Wouldn't it
>> be safe to omit the server roundtrip, under the assumption that a published
>> revision is immutable?
> Yes in principle, but the external working copy must have been tampered
> with. E.g. it must not contain mixed revisions.
>
> And non-pinned externals inside of pinned externals need to be handled
> properly.
>
> There may be more restrictions I'm not aware of right now.
> Many retrictions can be determined cheaply by querying the external
> working copy's database, but some may need a disk crawl.
>
>> At least in my case, this would result in a speedup of "svn update" of
>> factor 5-15 in the case of no or only a only few changesets to download.
> Please file an ENHANCEMENT issue for this. I like the idea.
I think we'd get much better performance if we parallelized externals
handling. I'm not aware of any reason (apart from serializing
notifications) why this wouldn't work, as long as the externals have
separate working copies.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-01-24 14:23:28 CET