Bug 336686

Summary: testFileMoveAndCopy, testFolderMoveAndCopy and testBug62547 failed
Product: [Eclipse Project] Platform Reporter: Tomasz Zarna <tomasz.zarna>
Component: CVSAssignee: Malgorzata Janczarska <malgorzata.tomczyk>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P2 CC: daniel_megert, Szymon.Brandys
Version: 3.7Keywords: test
Target Milestone: 3.7 M6   
Hardware: PC   
OS: All   
URL: http://fullmoon.ottawa.ibm.com/downloads/drops/N20110207-2000/testresults/html/org.eclipse.team.tests.cvs.core_win32.win32.x86_6.0.html
Whiteboard:
Attachments:
Description Flags
Fix for tests
none
Corrected tests
none
Corrected tests v02
none
mylyn/context/zip none

Description Tomasz Zarna CLA 2011-02-09 04:26:45 EST
N20110207-2000

This may be caused by recent fix for bug 62547. Gosia please take a look and confirm.

testFileMoveAndCopy	
The modification timestamp was changed for '/testFileMoveAndCopy-1297159480656/folder1/a.txt' but the contents match that of the server. The timestamp has been reset.

org.eclipse.team.internal.ccvs.core.CVSException: The modification timestamp was changed for '/testFileMoveAndCopy-1297159480656/folder1/a.txt' but the contents match that of the server. The timestamp has been reset.
at org.eclipse.team.internal.ccvs.ui.operations.CVSOperation.asException(CVSOperation.java:157)
at org.eclipse.team.internal.ccvs.ui.operations.CVSOperation.handleErrors(CVSOperation.java:200)
at org.eclipse.team.internal.ccvs.ui.operations.CVSOperation.endOperation(CVSOperation.java:95)
at org.eclipse.team.internal.ccvs.ui.operations.RepositoryProviderOperation.endOperation(RepositoryProviderOperation.java:218)
at org.eclipse.team.internal.ccvs.ui.operations.CVSOperation.run(CVSOperation.java:80)
at org.eclipse.team.tests.ccvs.core.EclipseRunnable.run(EclipseRunnable.java:30)
at java.lang.Thread.run(Thread.java:619)

testFolderMoveAndCopy	
The modification timestamp was changed for '/testFolderMoveAndCopy-1297159506812/folder1/folder3/file.txt' but the contents match that of the server. The timestamp has been reset.

org.eclipse.team.internal.ccvs.core.CVSException: The modification timestamp was changed for '/testFolderMoveAndCopy-1297159506812/folder1/folder3/file.txt' but the contents match that of the server. The timestamp has been reset.
at org.eclipse.team.internal.ccvs.ui.operations.CVSOperation.asException(CVSOperation.java:157)
at org.eclipse.team.internal.ccvs.ui.operations.CVSOperation.handleErrors(CVSOperation.java:200)
at org.eclipse.team.internal.ccvs.ui.operations.CVSOperation.endOperation(CVSOperation.java:95)
at org.eclipse.team.internal.ccvs.ui.operations.RepositoryProviderOperation.endOperation(RepositoryProviderOperation.java:218)
at org.eclipse.team.internal.ccvs.ui.operations.CVSOperation.run(CVSOperation.java:80)
at org.eclipse.team.tests.ccvs.core.EclipseRunnable.run(EclipseRunnable.java:30)
at java.lang.Thread.run(Thread.java:619)

testBug62547	Failure	expected:<1297149691444> but was:<1297149691000>

junit.framework.AssertionFailedError: expected:<1297149691444> but was:<1297149691000>
at org.eclipse.team.tests.ccvs.core.provider.IsModifiedTests.testBug62547(IsModifiedTests.java:584)
at org.eclipse.team.tests.ccvs.core.EclipseTest.runTest(EclipseTest.java:1448)
at org.eclipse.team.tests.ccvs.core.EclipseTest.runBare(EclipseTest.java:1295)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:416)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:249)
at org.eclipse.test.UITestApplication$2.run(UITestApplication.java:197)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3864)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3543)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2700)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2664)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2498)
at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:674)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:667)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115)
at org.eclipse.test.UITestApplication.runApplication(UITestApplication.java:140)
at org.eclipse.test.UITestApplication.run(UITestApplication.java:62)
at org.eclipse.test.UITestApplication.start(UITestApplication.java:212)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
at org.eclipse.core.launcher.Main.main(Main.java:34)
Comment 1 Dani Megert CLA 2011-02-09 04:33:31 EST
And there are 2 more failures in N20110207-2000.

Can we please fix this asap. We need to get back to a state where we have builds without failures. Thanks.
Comment 2 Tomasz Zarna CLA 2011-02-09 05:05:48 EST
(In reply to comment #1)
> And there are 2 more failures in N20110207-2000.

See bug 246547 for failure in testImportMultipleProjects and bug 325553 for testCacheBase.
Comment 3 Malgorzata Janczarska CLA 2011-02-10 03:50:20 EST
Created attachment 188657 [details]
Fix for tests

This patch fixes tests. The fixes are as follows:
1. one test included too large precision of modification date for Linux
2. two other tests failed when cvs server return any additional information, in this case on level info although the operation was successful.
Comment 4 Tomasz Zarna CLA 2011-02-10 04:34:34 EST
It appears that testFileMoveAndCopy() would have warned us about bug 62547 if assertModificationState had been called for both files after copying the destination back to the source without a commit in the meantime (line 360). Gosia could you please verify this?
Comment 5 Malgorzata Janczarska CLA 2011-02-10 07:05:46 EST
(In reply to comment #4)
> It appears that testFileMoveAndCopy() would have warned us about bug 62547 if
> assertModificationState had been called for both files after copying the
> destination back to the source without a commit in the meantime (line 360).
> Gosia could you please verify this?

That's correct, the file was moved from it's original place and then moved back to it. Before bug 62547 was fixed the file was reported as unchanged, although there were some actions on it in meantime. However its content did not change, so information that the file in unchanged is not far from trough. That's why I added testBug62547: the file content changes in meantime and there is no doubt that file should be reported as changed.
Comment 6 Tomasz Zarna CLA 2011-02-11 05:05:29 EST
The fix is fine, I would add a few tweaks:
* simply rethrow an exception if it indicates an error
* add the missing files to assertModificationState check in testFileMoveAndCopy(), not sure if the other test is missing them too
* can we avoid "Decreasing precision" hack in testBug62547, by simply getting a timestamp from one file and setting it on the other, without calling System.currentTimeMillis()?
* try to use the same helper methods in your test as in the others, this will make reading the tests easier in the future
Comment 7 Malgorzata Janczarska CLA 2011-02-11 06:23:06 EST
Created attachment 188762 [details]
Corrected tests

Tomek's comments applied.
Comment 8 Tomasz Zarna CLA 2011-02-12 06:13:10 EST
Created attachment 188828 [details]
Corrected tests v02

(In reply to comment #7)
> * add the missing files to assertModificationState check in
> testFileMoveAndCopy(), not sure if the other test is missing them too

You missed that in your patch. I modified assertions in testFileMoveAndCopy and testFolderMoveAndCopy. I also simplified the test in testBug62547 a little bit.
Comment 9 Tomasz Zarna CLA 2011-02-12 06:13:14 EST
Created attachment 188829 [details]
mylyn/context/zip
Comment 10 Tomasz Zarna CLA 2011-02-12 06:16:06 EST
The latest patch has been applied to HEAD. Available in build >=N20110212-2000.