On Tue, Aug 4, 2015 at 9:24 AM, Lübbe Onken <luebbe.tortoisesvn_at_gmail.com>
> 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:
>> > 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.
Easy to figure out:
* do the checkout, write down some of the files timestamps
* run an svn cleanup
* compare the file timestamps
if they're different, then the checkout somehow doesn't use the correct
timestamps or they get changed afterwards (after the checkout).
> 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?
or do the checkout with the command line client?
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-04 10:10:12 CEST