I will try to update the SVN version, but it is not as easy, as we are using the RHEL7 release and its default repos, due to our company policies.
I guess it is much, much faster to checkout the repository again, than “excluding” and existing folder from the working copy.
Can you briefly elaborate “why” this exclude takes sooo long ?
Does it do special things on each file ?
Von: Pavel Lyalyakin <pavel.lyalyakin_at_visualsvn.com>
Gesendet: Mittwoch, 20. März 2019 18:48
An: Weiss, Holger <Holger.Weiss_at_continental-corporation.com>
Betreff: Re: svn up --set-depth exclude takes very long time
On Wed, Mar 20, 2019 at 8:46 PM Pavel Lyalyakin <pavel.lyalyakin_at_visualsvn.com<mailto:pavel.lyalyakin_at_visualsvn.com>> wrote:
On Wed, Mar 20, 2019 at 2:33 PM Weiss, Holger <Holger.Weiss_at_continental-corporation.com<mailto:Holger.Weiss_at_continental-corporation.com>> wrote:
> having a very big working copy (>100GB) want to exclude “folderA” (~2.5GB) from this wc via “svn up –set-depth exclude folderA” .
> This command takes very long time – did not finish after 2 days when doing this on a NFS mounted dir.
> Even when the wc is on a local disk, it takes very long time (>1day).
> I am using SVN 1.7.14.
Note that SVN 1.7.x is not supported and you should plan an upgrade to the latest SVN 1.10.x (LTS) or SVN 1.11.x (regular time-based release) builds.
> Why does the “exclude” take such a long time and what can be done to make it faster ?
I guess that it's not the only operation that is slow on the network share, right? Please, upgrade your SVN client and try the same operation with the exclusive locking option. See SVNBook 1.8 about exclusive-locking runtime configuration option.
Here is an example:
svn update --config-option config:working-copy:exclusive-locking=true –set-depth exclude folderA
Oops, I forgot the links. Here they are.
With best regards,
Received on 2019-03-21 08:46:31 CET