Community
Participate
Working Groups
It failed twice in a row.
This test still passes locally. I was suspecting that we have new jgit, but after updating target platform it still passes locally. It look like in some conditions git log returns commits in a wrong order. This is how it looks like we have commits: 3. Initial commit (master, Branch1) 2. commit1 (master) 1. commit2 (Branch1) We checkout Branch1 and do git Log for HEAD and do git log, we get 2 commits 2. Initial commit 1. commit2 We do git log for the whole repo and we get 3 commits 3. commit2 2. Initial commit 3. ??? (guessing commit1) Test this is what test expects: 3. commit2 2. commit1 1. Initial commit I'm guessing "Initial commit" and "commit1" are changes in places. Maybe "Initial commit" and "commit1" where made so fast that they have the same date?
(In reply to comment #1) > I'm guessing "Initial commit" and "commit1" are changes in places. Maybe > "Initial commit" and "commit1" where made so fast that they have the same date? I added sleep(1) before doing commits in the test. Let's see if it helps.
I'm out of ideas why this test if failing. Maybe Tomek will know it. It's his code.
Last two builds, ie I20120119-2230, I20120122-2230, look fine to me. Does it mean what you did in comment 2 helped?
(In reply to comment #4) > Last two builds, ie I20120119-2230, I20120122-2230, look fine to me. Does it > mean what you did in comment 2 helped? It failed in I20120119-1647 and this fix was added in v20120119-1029, so I20120119-1647 should contain this fix.
It failed locally today on my workspace, but only once. I couldn't get it to fail again.
I've reverted Gosia's patch from comment 2. If it happens again we will see the stacktrace, which hasn't been attached to the bug.
This test failed today in I20120205-2230. Quite randomly, because for 3 builds that was made during the weekend the test failed only once.
The stack trace: expected:<[commit1]> but was:<[Initial commit]> at org.eclipse.orion.server.tests.servlets.git.GitLogTest.testLogAllBranches(GitLogTest.java:414) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:501) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:259) at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:36) at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:32) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) 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:352) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:624) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:579) at org.eclipse.equinox.launcher.Main.run(Main.java:1433) at org.eclipse.equinox.launcher.Main.main(Main.java:1409) at org.eclipse.core.launcher.Main.main(Main.java:34)
Delaying a commit by 1 ms was not enough as commit times are saved in secs [1]. A temporary solution is to defer problematic commits by 1 sec [2]. A better fix has been proposed on bug 370696, comment 1. [1] org.eclipse.jgit.revwalk.RevCommit.getCommitTime() [2] 8b96590d3bd776445da780d5adc8bd4768aea6c0
Created attachment 210565 [details] mylyn/context/zip
*** Bug 369078 has been marked as a duplicate of this bug. ***