Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 324346 - Subversive Revert Operation Painfully Slow
Summary: Subversive Revert Operation Painfully Slow
Status: RESOLVED FIXED
Alias: None
Product: Subversive
Classification: Technology
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Igor Burilo CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 287559
  Show dependency tree
 
Reported: 2010-09-02 15:33 EDT by Steve Cohen CLA
Modified: 2011-11-19 12:56 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Cohen CLA 2010-09-02 15:33:28 EDT
Build Identifier: I20100608-0911  Subversive at 2.2.2.I201005120I900

Revert is much too slow.  I am attempting to revert 533 .c and .h files for the most part and it has taken 15 minutes to do 60%.  I can delete the project and check it out again from version control (much more than 533 files) in a few seconds.

Reproducible: Always
Comment 1 dbharris CLA 2010-09-20 16:04:03 EDT
I've experienced this as well. A cursory examination of SVNKit source implies that the problem might be there - there are a large number of sleepForTimestamp() calls that seem to wait for the system clock to tick over enough for a filesystem timestamp to be updated. A Thread.wait() ensues.

However, that method does appear to allow these sleep calls to be overridden. Perhaps Subversive can specify this?
Comment 2 Alexander Gurov CLA 2011-06-12 01:44:22 EDT
I have checked through the code, there is no code in Subversive that could cause any delays. And SVNKit 1.3.5 does not contain any kind of "delays" or "sleeps" either. Moreover, Subversive performs caching of the SVN connector library instances in order to improve overall performance. So, may be somewhere in the SVN client libraries a non-optimal implementation code for the revert operation exists, but unfortunately there is nothing that could be done on our side in order to improve revert performance.
Comment 3 Steve Cohen CLA 2011-06-12 17:28:47 EDT
For what it's worth, I no longer notice this problem.

Probably should have specified the version in the original bug report, but from its date, I'm sure I have upgraded this plugin since then.
Comment 4 Alexander Gurov CLA 2011-06-17 09:26:44 EDT
(In reply to comment #3)
Thank you for your information. It is really good to be sure that the newer SVN Kit version does not cause the problem anymore.
Comment 5 Alexander Gurov CLA 2011-11-19 12:49:04 EST
I've found the case when the problem reappears even with the latest SVN Kit connector. It is the case when you perform revert from the Synchronize View. Since in this case it is working on per-resource basis in order to not touch any unnecessary resources, part of SVN Kit implementation causes the issue.
Comment 6 Alexander Gurov CLA 2011-11-19 12:56:06 EST
I've disabled corresponding part of the SVN Kit code.