[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SubWCRev is terribly slow (on fresh working copies?!?)

From: Lübbe Onken <luebbe.tortoisesvn_at_gmail.com>
Date: Tue, 4 Aug 2015 09:24:20 +0200

2015-08-03 19:29 GMT+02:00 Stefan Küng <tortoisesvn_at_gmail.com>:

> On 03.08.2015 10:42, Lübbe Onken wrote:
> > 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:
> http://tortoisesvn.net/faq.html#detectmodification
> > 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.
Ouch, that hurts. Does this indicate a bug in svnkit? I would expect that a
fresh checkout should be in "perfect" state.
Note that this doesn't happen on our "old" Cruisecontrol server, but this
one uses the svn command line and not svnkit.

The only workaround that I can think of right now is to insert a manual svn
cleanup of the working copy as a build step.
Any other suggestions?

- Lübbe

Please help me get more space on Dropbox :)
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net  PGP Key ID 0x23F511AB
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2015-08-04 09:24:25 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.