Change RacyGitTests to create a racy git situation in a stable way
By using File#setLastModified, we can create a racy git situation
stably.
Tested with --runs_per_test=100
Bug: 526111
Change-Id: I60b3632d353e19f335668325aa603640be423f58
Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
(cherry picked from commit df637928d2ef4b9ee06af7e37344c7848f870ce4)
diff --git a/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java b/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java
index 9236b4e..8b1d5cc 100644
--- a/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java
+++ b/org.eclipse.jgit.test/tst/org/eclipse/jgit/lib/RacyGitTests.java
@@ -61,8 +61,8 @@
public class RacyGitTests extends RepositoryTestCase {
@Test
- public void testIterator() throws IllegalStateException, IOException,
- InterruptedException {
+ public void testIterator()
+ throws IllegalStateException, IOException, InterruptedException {
TreeSet<Long> modTimes = new TreeSet<>();
File lastFile = null;
for (int i = 0; i < 10; i++) {
@@ -126,9 +126,6 @@
@Test
public void testRacyGitDetection() throws Exception {
- TreeSet<Long> modTimes = new TreeSet<>();
- File lastFile;
-
// Reset to force creation of index file
try (Git git = new Git(db)) {
git.reset().call();
@@ -136,42 +133,44 @@
// wait to ensure that modtimes of the file doesn't match last index
// file modtime
- modTimes.add(valueOf(fsTick(db.getIndexFile())));
+ fsTick(db.getIndexFile());
// create two files
- addToWorkDir("a", "a");
- lastFile = addToWorkDir("b", "b");
+ File a = addToWorkDir("a", "a");
+ File b = addToWorkDir("b", "b");
+ assertTrue(a.setLastModified(b.lastModified()));
+ assertTrue(b.setLastModified(b.lastModified()));
// wait to ensure that file-modTimes and therefore index entry modTime
// doesn't match the modtime of index-file after next persistance
- modTimes.add(valueOf(fsTick(lastFile)));
+ fsTick(b);
// now add both files to the index. No racy git expected
- resetIndex(new FileTreeIteratorWithTimeControl(db, modTimes));
+ resetIndex(new FileTreeIterator(db));
assertEquals(
- "[a, mode:100644, time:t0, length:1, content:a]" +
- "[b, mode:100644, time:t0, length:1, content:b]",
+ "[a, mode:100644, time:t0, length:1, content:a]"
+ + "[b, mode:100644, time:t0, length:1, content:b]",
indexState(SMUDGE | MOD_TIME | LENGTH | CONTENT));
- // Remember the last modTime of index file. All modifications times of
- // further modification are translated to this value so it looks that
- // files have been modified in the same time slot as the index file
- modTimes.add(Long.valueOf(db.getIndexFile().lastModified()));
+ // wait to ensure the file 'a' is updated at t1.
+ fsTick(db.getIndexFile());
- // modify one file
- addToWorkDir("a", "a2");
- // now update the index the index. 'a' has to be racily clean -- because
- // it's modification time is exactly the same as the previous index file
- // mod time.
- resetIndex(new FileTreeIteratorWithTimeControl(db, modTimes));
+ // Create a racy git situation. This is a situation that the index is
+ // updated and then a file is modified within a second. By changing the
+ // index file artificially, we create a fake racy situation.
+ File updatedA = addToWorkDir("a", "a2");
+ assertTrue(updatedA.setLastModified(updatedA.lastModified() + 100));
+ resetIndex(new FileTreeIterator(db));
+ assertTrue(db.getIndexFile()
+ .setLastModified(updatedA.lastModified() + 90));
db.readDirCache();
// although racily clean a should not be reported as being dirty
assertEquals(
- "[a, mode:100644, time:t1, smudged, length:0, content:a2]" +
- "[b, mode:100644, time:t0, length:1, content:b]",
- indexState(SMUDGE|MOD_TIME|LENGTH|CONTENT));
+ "[a, mode:100644, time:t1, smudged, length:0, content:a2]"
+ + "[b, mode:100644, time:t0, length:1, content:b]",
+ indexState(SMUDGE | MOD_TIME | LENGTH | CONTENT));
}
private File addToWorkDir(String path, String content) throws IOException {
