Summary: | [resources] Infinite loop renaming folder | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Jerome Lanneluc <jerome_lanneluc> |
Component: | Resources | Assignee: | Debbie Wilson <debbie_wilson> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | P1 | CC: | dj.houghton |
Version: | 2.1 | ||
Target Milestone: | 2.1 M4 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: | |||
Bug Depends on: | 28330 | ||
Bug Blocks: |
Description
Jerome Lanneluc
2002-12-13 04:21:47 EST
I will investigate this today and try to come up with a reproducable test case. A likely suspect is the partial match algorithm in the History Store visitor mechanism. Maybe you can ask Olivier if you need to get the code for our internal test suite. The history store visitor is incorrect (see bug 28330). Inside the visitor we created we were adding states to the history store. Because we were adding to the same table that we were visiting...we bail when the keys get too long. This is because the partial matching is incorrect. (see above referenced bug) As a work-around, I have changed the #copyhistory method to not modify the table in the visitor, but to collect all states to copy and then add all the states at the end. Closing bug since this problem is fixed. Added comment with FIXME as a reminder to change the code to be more performant once the referenced bug is resolved. Leaving referenced bug open. Referenced bug is closed and fixed. Changed #copyHistory implementation back to original form. (adding states from within the visitor) |