summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test
Commit message (Collapse)AuthorAgeFilesLines
* LocalDiskRefTreeDatabaseTest shall use MockSystemReaderMatthias Sohn2019-08-111-0/+1
| | | | | | | It missed to call the setup() method of its super class which prepares the MockSystemReader Change-Id: I39858749f8d0115fc6ac7edc8847ffb2bbc85c33 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Ensure we use MockSystemReader in testsMatthias Sohn2019-08-102-0/+5
| | | | | | | | | If we use the default system reader FileStoreAttributes cannot persist attributes in userConfig when tests run in Bazel due to sandboxing. Hence we need to ensure that all tests use MockSystemReader (and especially a mocked userConfig). Change-Id: Ic1ad8e2ec5a150c5433434a5f6667d6c4674c87d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Disable debug log for FS in org.eclipse.jgit.testMatthias Sohn2019-08-101-1/+1
| | | | | | | This was enabled unintentionally in 06fc6c7c and spams the test logs. We can enable this when needed. Change-Id: I9f3042c0e285ff236be65fcc02bdcfdb90efc3af Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Bazel: enable logging for tests in org.eclipse.jgit.testMatthias Sohn2019-08-103-3/+13
| | | | | | | | | - use slf4j-simple for logging in test runs - for log configuration see https://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html Change-Id: I9f0a532644b31162c867cd0d63f083296eaf6be5 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Stop using deprecated Constants.CHARACTER_ENCODINGDavid Pursehouse2019-08-091-1/+1
| | | | | Change-Id: I105b8a05bc64f249879a0795a059958553cc60c6 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Fix OpenSshConfigTest#configMatthias Sohn2019-08-081-1/+7
| | | | | | | | | | - use FS.DETECTED instead of db.getFS() since the ssh config is typically in a different place than the repository, the same is used in OpenSshConfig - reduce unnecessary repeated writes by introducing wait for one tick of the file time resolution Change-Id: Ifac915e97ff420ec5cf8e2f162e351f9f51b6b14 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* FileSnapshot: fix bug with timestamp thresholdingHan-Wen Nienhuys2019-08-071-8/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Increase the safety factor to 2.5x for extra safety if max of measured timestamp resolution and measured minimal racy threshold is < 100ms, use 1.25 otherwise since for large filesystem resolution values the influence of finite resolution of the system clock should be negligible. Before, not yet using the newly introduced minRacyThreshold measurement, the threshold was 1.1x FS resolution, and we could issue the following sequence of events, start create-file read-file (currentTime) end which had the following timestamps: create-file 1564589081998 start 1564589082002 read 1564589082003 end 1564589082004 In this case, the difference between create-file and read is 5ms, which exceeded the 4ms FS resolution, even though the events together took just 2ms of runtime. Reproduce with: bazel test --runs_per_test=100 \ //org.eclipse.jgit.test:org_eclipse_jgit_internal_storage_file_FileSnapshotTest The file system timestamp resolution is 4ms in this case. This code assumes that the kernel and the JVM use the same clock that is synchronized with the file system clock. This seems plausible, given the resolution of System.currentTimeMillis() and the latency for a gettimeofday system call (typically ~1us), but it would be good to justify this with specifications. Also cover a source of flakiness: if the test runs under extreme load, then we could have start create-file <long delay> read end which would register as an unmodified file. Avoid this by skipping the test if end-start is too big. [msohn]: - downported from master to stable-5.1 - skip test if resolution is below 10ms - adjust safety factor to 1.25 for resolutions above 100ms Change-Id: I87d2cf035e01c44b7ba8364c410a860aa8e312ef Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Cache FileStoreAttributeCache per directoryMatthias Sohn2019-08-061-0/+135
| | | | | | | | | | | | | Cache FileStoreAttributeCache entries since looking up FileStore for a file may be expensive on some platforms. Implement a simple LRU cache based on ConcurrentHashMap using a simple long counter to order access to cache entries. Change-Id: I4881fa938ad2f17712c05da857838073a2fc4ddb Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com> Also-By: Marc Strapetz <marc.strapetz@syntevo.com>
* Persist minimal racy threshold and allow manual configurationMatthias Sohn2019-08-063-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To enable persisting the minimal racy threshold per FileStore add a new config option to the user global git configuration: - Config section is "filesystem" - Config subsection is concatenation of - Java vendor (system property "java.vendor") - Java version (system property "java.version") - FileStore's name, on Windows we use the attribute volume:vsn instead since the name is not necessarily unique. - separated by '|' e.g. "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1" The same prefix is used as for filesystem timestamp resolution, so both values are stored in the same config section - The config key for minmal racy threshold is "minRacyThreshold" as a time value, supported time units are those supported by DefaultTypedConfigGetter#getTimeUnit - measure for 3 seconds to limit runtime which depends on hardware, OS and Java version being used If the minimal racy threshold is configured for a given FileStore the configured value is used instead of measuring it. When the minimal racy threshold was measured it is persisted in the user global git configuration. Rename FileStoreAttributeCache to FileStoreAttributes since this class is now declared public in order to enable exposing all attributes in one object. Example: [filesystem "AdoptOpenJDK|11.0.3|/dev/disk1s1"] timestampResolution = 7000 nanoseconds minRacyThreshold = 3440 microseconds Change-Id: I22195e488453aae8d011b0a8e3276fe3d99deaea Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Also-By: Marc Strapetz <marc.strapetz@syntevo.com>
* Measure minimum racy interval to auto-configure FileSnapshotMatthias Sohn2019-08-064-11/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By running FileSnapshotTest#detectFileModified we found that the sum of measured filesystem timestamp resolution and measured clock resolution may yield a too small interval after a file has been modified which we need to consider racily clean. In our tests we didn't find this behavior on all systems we tested on, e.g. on MacOS using APFS and Java 8 and 11 this effect was not observed. On Linux (SLES 15, kernel 4.12.14-150.22-default) we collected the following test results using Java 8 and 11: In 23-98% of 10000 test runs (depending on filesystem type and Java version) the test failed, which means the effective interval which needs to be considered racily clean after a file was modified is larger than the measured file timestamp resolution. "delta" is the observed interval after a file has been modified but FileSnapshot did not yet detect the modification: "resolution" is the measured sum of file timestamp resolution and clock resolution seen in Java. Java version filesystem failures resolution min delta max delta 1.8.0_212-b04 btrfs 98.6% 1 ms 3.6 ms 6.6 ms 1.8.0_212-b04 ext4 82.6% 3 ms 1.1 ms 4.1 ms 1.8.0_212-b04 xfs 23.8% 4 ms 3.7 ms 3.9 ms 1.8.0_212-b04 zfs 23.1% 3 ms 4.8 ms 5.0 ms 11.0.3+7 btrfs 98.1% 3 us 0.7 ms 4.7 ms 11.0.3+7 ext4 98.1% 6 us 0.7 ms 4.7 ms 11.0.3+7 xfs 98.5% 7 us 0.1 ms 8.0 ms 11.0.3+7 zfs 98.4% 7 us 0.7 ms 5.2 ms Mac OS 1.8.0_212 APFS 0% 1 s 11.0.3+7 APFS 0% 6 us The observed delta is not distributed according to a normal gaussian distribution but rather random in the observed range between "min delta" and "max delta". Run this test after measuring file timestamp resolution in FS.FileAttributeCache to auto-configure JGit since it's unclear what mechanism is causing this effect. In FileSnapshot#isRacyClean use the maximum of the measured timestamp resolution and the measured "delta" as explained above to decide if a given FileSnapshot is to be considered racily clean. Add a 30% safety margin to ensure we are on the safe side. Change-Id: I1c8bb59f6486f174b7bbdc63072777ddbe06694d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Add test for racy git detection in FileSnapshotMatthias Sohn2019-07-262-0/+189
| | | | | | | | | | | | | | | Repeat the test 10000 times to get statistics if measured fsTimestampResolution is working in practice to detect racy git situations. Add a class to compute statistics for this test. Log delta between lastModified and time when FileSnapshot failed to detect modification. This happens if the racy git limit determined by measuring filesystem timestamp resolution and clock resolution is too small. If it would be correct FileSnapshot would always detect modification or mark it modified if time since modification is smaller than the racy git limit. Change-Id: Iabe7af1a7211ca58480f8902d4fa4e366932fc77 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Repeat RefDirectoryTest.testGetRef_DiscoversModifiedLoose 100 timesMatthias Sohn2019-07-241-0/+2
| | | | | | This should help to detect if measured fsTimeResolution is too small. Change-Id: Id1f54dbdedb52b17859904e47776fa3a5887b8be Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix FileSnapshotTests for filesystem with high timestamp resolutionMatthias Sohn2019-07-191-2/+14
| | | | | | | | | When filesystem timestamp resolution is very high some tests don't work since runtime of the test setup is too long to reach a racily clean FileSnapshot. Hence skip these tests when timestamp resolution is higher than 10 millisecond. Change-Id: Ie47dd10eda22037b5c1ebff6b6becce0654ea807 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Retry deleting test files in FileBasedConfigTestMatthias Sohn2019-07-191-1/+1
| | | | Change-Id: I304b2b6f2e39f72f620bba53aead60256aed3660 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Measure filesystem timestamp resolution already in test setupMatthias Sohn2019-07-192-0/+4
| | | | | | | This helps to avoid some time critical tests can't prepare the test fixture intended since measuring timestamp resolution takes time. Change-Id: Ib34023e682a106070ca97e98ef16789a4dfb97b4 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Refactor FileSnapshotTest to use NIO APIsMatthias Sohn2019-07-192-89/+93
| | | | | | | | - use Path instead of File - create test directories, files and output stream using Files methods - delete unused list "files" Change-Id: I8c5c601eca9f613efb5618d33b262277df92a06a Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Use Instant instead of milliseconds for filesystem timestamp handlingMatthias Sohn2019-07-1821-141/+203
| | | | | | | | | | | | | | | | This enables higher file timestamp resolution on filesystems like ext4, Mac APFS (1ns) or NTFS (100ns) providing high timestamp resolution on filesystem level. Note: - on some OSes Java 8,9 truncate milliseconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes truncates timestamp resolution to microseconds when converting the internal representation to FileTime exposed in the API, see https://bugs.openjdk.java.net/browse/JDK-8181493 - WindowsFileAttributes also provides only microsecond resolution Change-Id: I25ffff31a3c6f725fc345d4ddc2f26da3b88f6f2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix NPE in FS$FileStoreAttributeCache.getFsTimestampResolutionMatthias Sohn2019-07-171-0/+8
| | | | | | Bug: 548682 Change-Id: I48840d3a68cf1db92c056d218a0d5ed0b9ea4c45 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Add debug trace for FileSnapshotMatthias Sohn2019-07-171-0/+2
| | | | | | | | | | | Checking lastModified is time critical hence debug trace is the only way to analyze issues since debugging is impractical. Also add configuration for buffering of log4j output to reduce runtime impact when debug trace is on. Limit buffer to 1MiB and comment this configuration out since we may not always want to use buffering. Change-Id: Ib1a0537b67c8dc3fac994a77b42badd974ce6c97 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Increase bazel timeout for long running testsMatthias Sohn2019-07-161-0/+4
| | | | | | | | | EolRepositoryTest and GcCommitSelectionTest timed out frequently when running unit tests using bazel with the default timeout "moderate" (300s). Increase timeout of these tests to "long" (900s). Change-Id: I43588cf950f55b50f868d9fe9c66d22bd428a54c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Bazel: Fix lint warning flagged by buildifierDavid Ostrovsky2019-07-162-8/+8
| | | | | | | | | | | | | | | | | | | | This change is fixing confusing name warning: [1]. ./org.eclipse.jgit.test/tests.bzl:12: confusing-name: Never use 'l', 'I', or 'O' as names (they're too easily confused with 'I', 'l', or '0'). And is also fixing: "All calls to rules or macros should pass arguments by keyword position argument" warning: [2]. ./org.eclipse.jgit.test/BUILD:42: positional-args: All calls to rules or macros should pass arguments by keyword (arg_name=value) syntax. [1] https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#confusing-name [2] https://github.com/bazelbuild/buildtools/blob/master/WARNINGS.md#positional-args Change-Id: If5c28ec8a1ddc1d1b1035bd07b838a2a564aea4f Signed-off-by: David Ostrovsky <david@ostrovsky.org>
* Bazel: Add missing dependencies for ArchiveCommandTestDavid Pursehouse2019-07-161-0/+6
| | | | | | | | Dependencies on commons-compress, xz, and jgit-archive are required for the build to succeed. Change-Id: I42f3721078a240ad93b8dcab909e66b9bfff0b56 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Bazel: Remove FileTreeIteratorWithTimeControl from BUILD fileDavid Pursehouse2019-07-161-1/+0
| | | | | | | | | FileTreeIteratorWithTimeControl was deleted in a024759, but was not removed from the BUILD file, thus causing the bazel build to fail. Change-Id: I892c0ffcac947298d0d6009374ee2c5d9afefb66 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Add support for nanoseconds and microseconds for Config#getTimeUnitMatthias Sohn2019-07-111-0/+12
| | | | Change-Id: I0a5828438810dd23790cba52d7ae2e055c6a3fc9 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Delete unused FileTreeIteratorWithTimeControlMatthias Sohn2019-07-112-177/+0
| | | | | | | The only usage of this test iterator was removed in df637928d. Hence delete this iterator and associated test. Change-Id: I47710133ec3edc675c21db210960c024982668c6 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* FileSnapshot#equals: consider UNKNOWN_SIZEHan-Wen Nienhuys2019-07-091-0/+11
| | | | | | | | | | | | | | | | Add a unittest. In commit I5485db55 ("Fix FileSnapshot's consideration of file size"), the special casing of UNKNOWN_SIZE was forgotten. This change, together with I493f3b57b ("Measure file timestamp resolution used in FileSnapshot") introduced a regression that would occasionally surface in Gerrit integration tests marked UseLocalDisk, with the symptom that creating the Admin user in NoteDb failed with a LOCK_FAILURE. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Change-Id: I7ffd972581f815c144f810481103c7985af5feb0
* Fix RacyGitTests#testRacyGitDetectionMatthias Sohn2019-07-031-11/+26
| | | | | | | | | | | | | | This test case assumed file system timestamp resolution of 1 second. On filesystems with a finer resolution this test fails since the index entry is only smudged if the file index entry's lastModified and the lastModified of the git index itself are within the same filesystem timer tick. Fix this by ensuring that these timestamps are identical which should work for any filesystem timer resolution. Bug: 548188 Change-Id: Id84d59e1cfeb48fa008f8f27f2f892c4f73985de Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
* Change RacyGitTests to create a racy git situation in a stable wayMasaya Suzuki2019-06-191-29/+24
| | | | | | | | | | | 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>
* Deprecate Constants.CHARACTER_ENCODING in favor of StandardCharsets.UTF_8David Pursehouse2019-06-196-13/+18
| | | | | Change-Id: I621ba174235a6fb56236e54d24bce704bb5afb28 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Fix non-deterministic hash of archives created by ArchiveCommandMatthias Sohn2019-06-193-8/+197
| | | | | | | | | | | | | | | | Archives created by the ArchiveCommand didn't produce deterministic archive hashes. For RevCommits RevWalk.parseTree returns the root tree instead of the RevCommit hence retrieving the commit's timestamp didn't work. Instead use RevWalk.parseAny and extract the tree manually. Archive entries store timestamps with 1 second resolution hence we need to wait longer when creating the same archive twice and compare archive hashes. Otherwise hash comparison in tests wouldn't fail without this patch. Bug: 548312 Change-Id: I437d515de51cf68265584d28a8446cebe6341b79 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Update Maven plugins and cleanup Maven warningsMatthias Sohn2019-06-181-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | update Maven plugins - jacoco-maven-plugin to 0.8.4 - japicmp-maven-plugin to 0.14.1 - maven-compiler-plugin to 3.8.1 - maven-deploy-plugin to 3.0.0-M1 - maven-enforcer-plugin to 3.0.0-M2 - maven-install-plugin to 3.0.0-M1 - maven-jar-plugin to 3.1.2 - maven-javadoc-plugin to 3.1.0 - maven-jxr-plugin to 3.0.0 - maven-pmd-plugin to 3.12.0 - maven-resources-plugin to 3.1.0 - maven-shade-plugin to 3.2.1 - maven-source-plugin to 3.1.0 - maven-surefire-plugin to 3.0.0-M3 - spotbugs-maven-plugin to 3.1.12 - tycho to 1.3.0 - tycho-pack200a-plugin to 1.3.0 - tycho-pack200b-plugin to 1.3.0 Cleanup Maven warnings - pin version of all used Maven plugins - remove deprecated way to declare minimum Maven version Change-Id: If23e2e2bb03e5e1e7b1eb9d4924a8faa0aa3704e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Make inner classes static where possibleDavid Pursehouse2019-06-177-9/+10
| | | | | | | | | | | | | | As reported by Error Prone: An inner class should be static unless it references members of its enclosing class. An inner class that is made non-static unnecessarily uses more memory and does not make the intent of the class clear. See https://errorprone.info/bugpattern/ClassCanBeStatic Change-Id: Ib99d120532630dba63cf400cc1c61c318286fc41 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com> (cherry picked from commit ee40efcea44bc0c9a28afe29a80c87636947484e)
* Prepare 5.1.9-SNAPSHOT buildsMatthias Sohn2019-06-052-47/+47
| | | | | Change-Id: I60571e4e0bea04bb2c25ef3d0332a9ab6895db06 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v5.1.8.201906050907-rv5.1.8.201906050907-rMatthias Sohn2019-06-052-2/+2
| | | | | Change-Id: Iae0ffe161df2ca8a800d21688d6b7d7419dfb640 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Test detecting modified packfilesChristian Halstrick2019-06-051-11/+222
| | | | | | | | | | | | | Test that JGit detects that packfiles have changed even if they are repacked multiple times in one tick of the filesystem timer. Test that this detection works also when repacking doesn't change the length or the filekey of the packfile. In this case where a modified file can't be detected by looking at file metadata JGit should still detect too fast modification by racy git checks and trigger rescanning the pack list and consequently rereading of packfile content. Change-Id: I67682cfb807c58afc6de9375224ff7489d6618fb Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Extend FileSnapshot for packfiles to also use checksum to detect changesMatthias Sohn2019-06-041-0/+143
| | | | | | | | | | | | | | If the attributes of FileSnapshot don't detect modification of a packfile read the packfile's checksum and compare it against the checksum cached in the loaded packfile. Since reading the checksum needs less IO than reloading the complete packfile this may help to reduce the overhead to detect modficiation when a gc completes while ObjectDirectory scans for packfiles in another thread. Bug: 546891 Change-Id: I9811b497eb11b8a85ae689081dc5d949ca8c4be5 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Add FileSnapshot test testing recognition of file size changesMatthias Sohn2019-05-291-0/+17
| | | | Change-Id: Ibcd76a5e6e4183ada0be1d4436ce957243f2094d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Capture reason for result of FileSnapshot#isModifiedMatthias Sohn2019-05-291-0/+7
| | | | | | | | | | | | | | | This allows to verify the expected behavior in FileSnapshotTest#testSimulatePackfileReplacement and enables extending FileSnapshot for packfiles to read the packfile's checksum as another criterion to detect modifications without reading the full content. Also add another field capturing the result of the last check if lastModified was racily clean. Remove unnecessary determination of raciness in the constructor. It was determined twice in all relevant cases. Change-Id: I100a2f49d7949693d7b72daa89437e166f1dc107 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Skip FileSnapshotTest#testSimulatePackfileReplacement on WindowsMatthias Sohn2019-05-291-0/+3
| | | | | | NTFS does not support FileKey hence ignore this test on Windows. Change-Id: I7b53a591daa5e03eb5e401b5b26d612ab68ce10d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Tune max heap size for testsMatthias Sohn2019-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | | This is an attempt to fix crashes observed on the new Jenkins infrastructure running on Kubernetes [1]. Increase it to 512m for - org.eclipse.jgit.ant.test - org.eclipse.jgit.http.test - org.eclipse.jgit.lfs.server.test - org.eclipse.jgit.lfs.test - org.eclipse.jgit.pgm.test Decrease it to 768m for - org.eclipse.jgit.test [1] e.g. https://ci-staging.eclipse.org/jgit/job/stable/job/jgit.gerrit/16074/console Change-Id: Id074ed0f7bcb8a13da649a547342af2a08439d9f Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> (cherry picked from commit e19e859977525c2a39aaa928dfdef20e5fab7e3c)
* Fix FileSnapshotTest.testNewFileNoWait() to match its javadocMatthias Sohn2019-05-271-2/+0
| | | | | | | testNewFileNoWait() was identical to testNewFileWithWait() but claims it doesn't wait at all. Hence remove the waits. Change-Id: I49b8ca5cb49a43c55fe61870c18c42f32fb4b74d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Include filekey file attribute when comparing FileSnapshotsMatthias Sohn2019-05-221-0/+28
| | | | | | | | | | | | | | | | | | | | | | Due to finite filesystem timestamp resolution the last modified timestamp of files cannot detect file changes which happened in the immediate past (less than one filesystem timer tick ago). Some filesystems expose unique file identifiers, e.g. inodes in Posix filesystems which are named filekeys in Java's BasicFileAttributes. Use them as another means to detect file modifications based on stat information. Running git gc on a repository yields a new packfile with the same id as a packfile which existed before the gc if these packfiles contain the same set of objects. The content of the old and the new packfile might differ if a different PackConfig was used when writing the packfile. Considering filekeys in FileSnapshot may help to detect such packfile modifications. Bug: 546891 Change-Id: I711a80328c55e1a31171d540880b8e80ec1fe095 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Measure file timestamp resolution used in FileSnapshotMatthias Sohn2019-05-221-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | FileSnapshot.notRacyClean() assumed a worst case filesystem timestamp resolution of 2.5 sec (FAT has a resolution of 2 sec). Instead measure timestamp resolution to avoid unnecessary IO caused by false positives in detecting the racy git problem caused by finite filesystem timestamp resolution [1]. Cache the measured resolution per FileStore since timestamp resolution depends on the respective filesystem type. If timestamp resolution cannot be measured or fails due to an exception fallback to the worst case FAT timestamp resolution and avoid caching this value. Add a 10% safety margin in FileSnapshot.notRacyClean(), though running FsTest.testFsTimestampResolution() 1000 times which is not using a safety margin didn't fail on Mac using APFS and Java 8, 11, 12. Measured Java file timestamp resolution: [2] [1] https://github.com/git/git/blob/master/Documentation/technical/racy-git.txt [2] https://docs.google.com/spreadsheets/d/1imy0y6WmRqBf0kjCxzxj2X7M50eIVfa7oaUIzEOHmjo Bug: 546891 Change-Id: I493f3b57b6b306285ffa7d392339d253e5966ab8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Prepare 5.1.8-SNAPSHOT buildsMatthias Sohn2019-04-202-47/+47
| | | | | Change-Id: I331bbaefd42ef94673ae8565c9b2b3af9eadfda0 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* JGit v5.1.7.201904200442-rv5.1.7.201904200442-rMatthias Sohn2019-04-202-2/+2
| | | | | Change-Id: Ifaa3a88c5e117912a8c691b8b8369dd9a17faebb Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Merge branch 'stable-5.0' into stable-5.1Matthias Sohn2019-03-211-0/+17
|\ | | | | | | | | | | | | | | * stable-5.0: Fix GC to delete empty fanout directories after repacking Change-Id: I5c0e7d59f137c27e4588f20f4472d3ea450cd59c Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * Merge branch 'stable-4.11' into stable-5.0Matthias Sohn2019-03-211-0/+17
| |\ | | | | | | | | | | | | | | | | | | | | | * stable-4.11: Fix GC to delete empty fanout directories after repacking Change-Id: Idce894a24e126e0fbe7bc9b6a3c64318f1a8eb75 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | * Merge branch 'stable-4.10' into stable-4.11Matthias Sohn2019-03-211-0/+17
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-4.10: Fix GC to delete empty fanout directories after repacking Change-Id: I7118b9c668dcbb0f5435cc613e964c557bfebf01 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | | * Merge branch 'stable-4.9' into stable-4.10Matthias Sohn2019-03-211-0/+17
| | | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * stable-4.9: Fix GC to delete empty fanout directories after repacking Change-Id: Ibdbfe08eb290286fa738010bad1c604e857885cd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| | | | * Fix GC to delete empty fanout directories after repackingMatthias Sohn2019-03-201-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The prune method did not delete empty fanout directories when loose objects moved to a new pack file but only when loose unreferenced objects were pruned. Change-Id: Ia068f4914c54d9cf9f40b75e8ea50759402b5000 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 18:31:17 +0000