On 03.08.2015 10:42, Lübbe Onken wrote:
> Hi Folks,
> I noticed the following strange behaviour of SubWCRev. I also found a
> solution for the problem, which doesn't mean everything is fine, because
> I'd like to know why this happens and if there is a way to prevent it
> from happening in the first place.
> Whenever I set up a new project on our Jenkins build server, the server
> checks out a fresh working copy and builds the project in it. The size
> of a fresh working copy is about 1.5 gigabytes, including build
> artifacts about 1.7 gigabytes.
> Building a fresh project takes about one hour, which is incredibly slow.
> Looking at the console output during the build I see that the build
> spend several minutes (sic!) in each call to SubWCRev. SubWCRev is
> called many times during the build, so these minutes really add up...
> The solution is to run TortoiseSVN->Cleanup on the working copy. After
> that a call to SubWCRev only takes a few seconds again and the build
> times are back to the "normal" 15-17 minutes (factor four!)
> The TortoiseSVN->Cleanup itself takes several minutes.
> Jenkins checks out the working copies in svn 1.8 format using svnkit.
> I reckon that TortoiseSVN->Cleanup repairs a somehow initially broken
> working copy (rebuilds/creates indexes?!?)
That too, but I'm guessing the speedup happens because a cleanup also
adjusts the file times:
> Has anyone else encountered a similar problem?
> What could be the reason for this behaviour?
> What is your solution?
it seems the file times don't match the filetimes recorded in the .svn
db files and that's why fetching the status requires to do a
byte-by-byte comparison of all the files.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-08-03 19:29:44 CEST