You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

.api_filters 16KB

Persist filesystem timestamp resolution and allow manual configuration To enable persisting filesystem timestamp resolution per FileStore add a new config section to the user global git configuration: - Config section is "filesystem" - Config subsection is concatenation of - Java vendor (system property "java.vm.vendor") - runtime version (system property "java.vm.version") - FileStore's name - separated by '|' e.g. "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1" The prefix is needed since some Java versions do not expose the full timestamp resolution of the underlying filesystem. This may also depend on the underlying operating system hence concrete key values may not be portable. - Config key for timestamp resolution is "timestampResolution" as a time value, supported time units are those supported by DefaultTypedConfigGetter#getTimeUnit If timestamp resolution is already configured for a given FileStore the configured value is used instead of measuring the resolution. When timestamp resolution was measured it is persisted in the user global git configuration. Example: [filesystem "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1"] timestampResolution = 1 seconds If locking the git config file fails retry saving the resolution up to 5 times in order to workaround races with another thread. In order to avoid stack overflow use the fallback filesystem timestamp resolution when loading FileBasedConfig which creates itself a FileSnapshot to help checking if the config changed. Note: - on some OSes Java 8,9 truncate to milliseconds or seconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes up to Java 12 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 up to Java 12 Hence do not attempt to manually configure a higher timestamp resolution than supported by the Java version being used at runtime. Bug: 546891 Bug: 548188 Change-Id: Iff91b8f9e6e5e2295e1463f87c8e95edf4abbcf8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
5 years ago
Persist filesystem timestamp resolution and allow manual configuration To enable persisting filesystem timestamp resolution per FileStore add a new config section to the user global git configuration: - Config section is "filesystem" - Config subsection is concatenation of - Java vendor (system property "java.vm.vendor") - runtime version (system property "java.vm.version") - FileStore's name - separated by '|' e.g. "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1" The prefix is needed since some Java versions do not expose the full timestamp resolution of the underlying filesystem. This may also depend on the underlying operating system hence concrete key values may not be portable. - Config key for timestamp resolution is "timestampResolution" as a time value, supported time units are those supported by DefaultTypedConfigGetter#getTimeUnit If timestamp resolution is already configured for a given FileStore the configured value is used instead of measuring the resolution. When timestamp resolution was measured it is persisted in the user global git configuration. Example: [filesystem "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1"] timestampResolution = 1 seconds If locking the git config file fails retry saving the resolution up to 5 times in order to workaround races with another thread. In order to avoid stack overflow use the fallback filesystem timestamp resolution when loading FileBasedConfig which creates itself a FileSnapshot to help checking if the config changed. Note: - on some OSes Java 8,9 truncate to milliseconds or seconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes up to Java 12 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 up to Java 12 Hence do not attempt to manually configure a higher timestamp resolution than supported by the Java version being used at runtime. Bug: 546891 Bug: 548188 Change-Id: Iff91b8f9e6e5e2295e1463f87c8e95edf4abbcf8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
5 years ago
Persist minimal racy threshold and allow manual configuration 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>
4 years ago
Persist filesystem timestamp resolution and allow manual configuration To enable persisting filesystem timestamp resolution per FileStore add a new config section to the user global git configuration: - Config section is "filesystem" - Config subsection is concatenation of - Java vendor (system property "java.vm.vendor") - runtime version (system property "java.vm.version") - FileStore's name - separated by '|' e.g. "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1" The prefix is needed since some Java versions do not expose the full timestamp resolution of the underlying filesystem. This may also depend on the underlying operating system hence concrete key values may not be portable. - Config key for timestamp resolution is "timestampResolution" as a time value, supported time units are those supported by DefaultTypedConfigGetter#getTimeUnit If timestamp resolution is already configured for a given FileStore the configured value is used instead of measuring the resolution. When timestamp resolution was measured it is persisted in the user global git configuration. Example: [filesystem "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1"] timestampResolution = 1 seconds If locking the git config file fails retry saving the resolution up to 5 times in order to workaround races with another thread. In order to avoid stack overflow use the fallback filesystem timestamp resolution when loading FileBasedConfig which creates itself a FileSnapshot to help checking if the config changed. Note: - on some OSes Java 8,9 truncate to milliseconds or seconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes up to Java 12 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 up to Java 12 Hence do not attempt to manually configure a higher timestamp resolution than supported by the Java version being used at runtime. Bug: 546891 Bug: 548188 Change-Id: Iff91b8f9e6e5e2295e1463f87c8e95edf4abbcf8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
5 years ago
Measure minimum racy interval to auto-configure FileSnapshot 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>
4 years ago
Persist minimal racy threshold and allow manual configuration 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>
4 years ago
Measure minimum racy interval to auto-configure FileSnapshot 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>
4 years ago
Persist minimal racy threshold and allow manual configuration 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>
4 years ago
Measure minimum racy interval to auto-configure FileSnapshot 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>
4 years ago
Measure minimum racy interval to auto-configure FileSnapshot 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>
4 years ago
Persist minimal racy threshold and allow manual configuration 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>
4 years ago
Persist minimal racy threshold and allow manual configuration 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>
4 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382
  1. <?xml version="1.0" encoding="UTF-8" standalone="no"?>
  2. <component id="org.eclipse.jgit" version="2">
  3. <resource path="src/org/eclipse/jgit/dircache/DirCacheEntry.java" type="org.eclipse.jgit.dircache.DirCacheEntry">
  4. <filter id="1142947843">
  5. <message_arguments>
  6. <message_argument value="5.1.9"/>
  7. <message_argument value="getLastModifiedInstant()"/>
  8. </message_arguments>
  9. </filter>
  10. <filter id="1142947843">
  11. <message_arguments>
  12. <message_argument value="5.1.9"/>
  13. <message_argument value="mightBeRacilyClean(Instant)"/>
  14. </message_arguments>
  15. </filter>
  16. <filter id="1142947843">
  17. <message_arguments>
  18. <message_argument value="5.1.9"/>
  19. <message_argument value="setLastModified(Instant)"/>
  20. </message_arguments>
  21. </filter>
  22. </resource>
  23. <resource path="src/org/eclipse/jgit/errors/PackInvalidException.java" type="org.eclipse.jgit.errors.PackInvalidException">
  24. <filter id="1142947843">
  25. <message_arguments>
  26. <message_argument value="4.5.7"/>
  27. <message_argument value="PackInvalidException(File, Throwable)"/>
  28. </message_arguments>
  29. </filter>
  30. <filter id="1142947843">
  31. <message_arguments>
  32. <message_argument value="4.5.7"/>
  33. <message_argument value="PackInvalidException(String, Throwable)"/>
  34. </message_arguments>
  35. </filter>
  36. </resource>
  37. <resource path="src/org/eclipse/jgit/gitrepo/RepoCommand.java" type="org.eclipse.jgit.gitrepo.RepoCommand$DefaultRemoteReader">
  38. <filter id="338792546">
  39. <message_arguments>
  40. <message_argument value="org.eclipse.jgit.gitrepo.RepoCommand.DefaultRemoteReader"/>
  41. <message_argument value="readFile(String, String, String)"/>
  42. </message_arguments>
  43. </filter>
  44. <filter id="338792546">
  45. <message_arguments>
  46. <message_argument value="org.eclipse.jgit.gitrepo.RepoCommand.DefaultRemoteReader"/>
  47. <message_argument value="readFileFromRepo(Repository, String, String)"/>
  48. </message_arguments>
  49. </filter>
  50. </resource>
  51. <resource path="src/org/eclipse/jgit/gitrepo/RepoCommand.java" type="org.eclipse.jgit.gitrepo.RepoCommand$RemoteReader">
  52. <filter id="403804204">
  53. <message_arguments>
  54. <message_argument value="org.eclipse.jgit.gitrepo.RepoCommand.RemoteReader"/>
  55. <message_argument value="readFileWithMode(String, String, String)"/>
  56. </message_arguments>
  57. </filter>
  58. </resource>
  59. <resource path="src/org/eclipse/jgit/lib/ConfigConstants.java" type="org.eclipse.jgit.lib.ConfigConstants">
  60. <filter id="1142947843">
  61. <message_arguments>
  62. <message_argument value="5.1.13"/>
  63. <message_argument value="CONFIG_JMX_SECTION"/>
  64. </message_arguments>
  65. </filter>
  66. <filter id="1142947843">
  67. <message_arguments>
  68. <message_argument value="5.1.13"/>
  69. <message_argument value="CONFIG_KEY_PACKED_GIT_LIMIT"/>
  70. </message_arguments>
  71. </filter>
  72. <filter id="1142947843">
  73. <message_arguments>
  74. <message_argument value="5.1.13"/>
  75. <message_argument value="CONFIG_KEY_PACKED_GIT_MMAP"/>
  76. </message_arguments>
  77. </filter>
  78. <filter id="1142947843">
  79. <message_arguments>
  80. <message_argument value="5.1.13"/>
  81. <message_argument value="CONFIG_KEY_PACKED_GIT_OPENFILES"/>
  82. </message_arguments>
  83. </filter>
  84. <filter id="1142947843">
  85. <message_arguments>
  86. <message_argument value="5.1.13"/>
  87. <message_argument value="CONFIG_KEY_PACKED_GIT_USE_STRONGREFS"/>
  88. </message_arguments>
  89. </filter>
  90. <filter id="1142947843">
  91. <message_arguments>
  92. <message_argument value="5.1.13"/>
  93. <message_argument value="CONFIG_KEY_PACKED_GIT_WINDOWSIZE"/>
  94. </message_arguments>
  95. </filter>
  96. <filter id="1142947843">
  97. <message_arguments>
  98. <message_argument value="5.1.9"/>
  99. <message_argument value="CONFIG_FILESYSTEM_SECTION"/>
  100. </message_arguments>
  101. </filter>
  102. <filter id="1142947843">
  103. <message_arguments>
  104. <message_argument value="5.1.9"/>
  105. <message_argument value="CONFIG_KEY_MIN_RACY_THRESHOLD"/>
  106. </message_arguments>
  107. </filter>
  108. <filter id="1142947843">
  109. <message_arguments>
  110. <message_argument value="5.1.9"/>
  111. <message_argument value="CONFIG_KEY_TIMESTAMP_RESOLUTION"/>
  112. </message_arguments>
  113. </filter>
  114. </resource>
  115. <resource path="src/org/eclipse/jgit/lib/GitmoduleEntry.java" type="org.eclipse.jgit.lib.GitmoduleEntry">
  116. <filter id="1109393411">
  117. <message_arguments>
  118. <message_argument value="4.7.5"/>
  119. <message_argument value="org.eclipse.jgit.lib.GitmoduleEntry"/>
  120. </message_arguments>
  121. </filter>
  122. </resource>
  123. <resource path="src/org/eclipse/jgit/lib/ObjectChecker.java" type="org.eclipse.jgit.lib.ObjectChecker">
  124. <filter id="1142947843">
  125. <message_arguments>
  126. <message_argument value="4.7.5"/>
  127. <message_argument value="getGitsubmodules()"/>
  128. </message_arguments>
  129. </filter>
  130. </resource>
  131. <resource path="src/org/eclipse/jgit/revwalk/DepthWalk.java" type="org.eclipse.jgit.revwalk.DepthWalk">
  132. <filter id="403804204">
  133. <message_arguments>
  134. <message_argument value="org.eclipse.jgit.revwalk.DepthWalk"/>
  135. <message_argument value="getDeepenNotFlag()"/>
  136. </message_arguments>
  137. </filter>
  138. <filter id="404000815">
  139. <message_arguments>
  140. <message_argument value="org.eclipse.jgit.revwalk.DepthWalk"/>
  141. <message_argument value="getDeepenNots()"/>
  142. </message_arguments>
  143. </filter>
  144. <filter id="404000815">
  145. <message_arguments>
  146. <message_argument value="org.eclipse.jgit.revwalk.DepthWalk"/>
  147. <message_argument value="getDeepenSince()"/>
  148. </message_arguments>
  149. </filter>
  150. </resource>
  151. <resource path="src/org/eclipse/jgit/storage/file/WindowCacheConfig.java" type="org.eclipse.jgit.storage.file.WindowCacheConfig">
  152. <filter id="1142947843">
  153. <message_arguments>
  154. <message_argument value="5.1.13"/>
  155. <message_argument value="isPackedGitUseStrongRefs()"/>
  156. </message_arguments>
  157. </filter>
  158. <filter id="1142947843">
  159. <message_arguments>
  160. <message_argument value="5.1.13"/>
  161. <message_argument value="setPackedGitUseStrongRefs(boolean)"/>
  162. </message_arguments>
  163. </filter>
  164. </resource>
  165. <resource path="src/org/eclipse/jgit/storage/file/WindowCacheStats.java" type="org.eclipse.jgit.storage.file.WindowCacheStats">
  166. <filter id="337809484">
  167. <message_arguments>
  168. <message_argument value="org.eclipse.jgit.storage.file.WindowCacheStats"/>
  169. <message_argument value="4"/>
  170. <message_argument value="8"/>
  171. </message_arguments>
  172. </filter>
  173. </resource>
  174. <resource path="src/org/eclipse/jgit/storage/pack/PackConfig.java" type="org.eclipse.jgit.storage.pack.PackConfig">
  175. <filter id="336658481">
  176. <message_arguments>
  177. <message_argument value="org.eclipse.jgit.storage.pack.PackConfig"/>
  178. <message_argument value="DEFAULT_MINSIZE_PREVENT_RACY_PACK"/>
  179. </message_arguments>
  180. </filter>
  181. <filter id="336658481">
  182. <message_arguments>
  183. <message_argument value="org.eclipse.jgit.storage.pack.PackConfig"/>
  184. <message_argument value="DEFAULT_WAIT_PREVENT_RACY_PACK"/>
  185. </message_arguments>
  186. </filter>
  187. <filter id="1142947843">
  188. <message_arguments>
  189. <message_argument value="5.1.8"/>
  190. <message_argument value="DEFAULT_MINSIZE_PREVENT_RACY_PACK"/>
  191. </message_arguments>
  192. </filter>
  193. <filter id="1142947843">
  194. <message_arguments>
  195. <message_argument value="5.1.8"/>
  196. <message_argument value="DEFAULT_WAIT_PREVENT_RACY_PACK"/>
  197. </message_arguments>
  198. </filter>
  199. <filter id="1142947843">
  200. <message_arguments>
  201. <message_argument value="5.1.8"/>
  202. <message_argument value="doWaitPreventRacyPack(long)"/>
  203. </message_arguments>
  204. </filter>
  205. <filter id="1142947843">
  206. <message_arguments>
  207. <message_argument value="5.1.8"/>
  208. <message_argument value="getMinSizePreventRacyPack()"/>
  209. </message_arguments>
  210. </filter>
  211. <filter id="1142947843">
  212. <message_arguments>
  213. <message_argument value="5.1.8"/>
  214. <message_argument value="isWaitPreventRacyPack()"/>
  215. </message_arguments>
  216. </filter>
  217. <filter id="1142947843">
  218. <message_arguments>
  219. <message_argument value="5.1.8"/>
  220. <message_argument value="setMinSizePreventRacyPack(long)"/>
  221. </message_arguments>
  222. </filter>
  223. <filter id="1142947843">
  224. <message_arguments>
  225. <message_argument value="5.1.8"/>
  226. <message_argument value="setWaitPreventRacyPack(boolean)"/>
  227. </message_arguments>
  228. </filter>
  229. </resource>
  230. <resource path="src/org/eclipse/jgit/transport/RemoteSession.java" type="org.eclipse.jgit.transport.RemoteSession">
  231. <filter id="404000815">
  232. <message_arguments>
  233. <message_argument value="org.eclipse.jgit.transport.RemoteSession"/>
  234. <message_argument value="getFtpChannel()"/>
  235. </message_arguments>
  236. </filter>
  237. </resource>
  238. <resource path="src/org/eclipse/jgit/transport/TransferConfig.java" type="org.eclipse.jgit.transport.TransferConfig">
  239. <filter id="1159725059">
  240. <message_arguments>
  241. <message_argument value="5.1.4"/>
  242. <message_argument value="TransferConfig(Config)"/>
  243. </message_arguments>
  244. </filter>
  245. <filter id="1159725059">
  246. <message_arguments>
  247. <message_argument value="5.1.4"/>
  248. <message_argument value="TransferConfig(Repository)"/>
  249. </message_arguments>
  250. </filter>
  251. </resource>
  252. <resource path="src/org/eclipse/jgit/transport/http/HttpConnection.java" type="org.eclipse.jgit.transport.http.HttpConnection">
  253. <filter id="403804204">
  254. <message_arguments>
  255. <message_argument value="org.eclipse.jgit.transport.http.HttpConnection"/>
  256. <message_argument value="getHeaderFields(String)"/>
  257. </message_arguments>
  258. </filter>
  259. </resource>
  260. <resource path="src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java" type="org.eclipse.jgit.treewalk.WorkingTreeIterator">
  261. <filter id="1142947843">
  262. <message_arguments>
  263. <message_argument value="5.1.9"/>
  264. <message_argument value="getEntryLastModifiedInstant()"/>
  265. </message_arguments>
  266. </filter>
  267. </resource>
  268. <resource path="src/org/eclipse/jgit/treewalk/WorkingTreeIterator.java" type="org.eclipse.jgit.treewalk.WorkingTreeIterator$Entry">
  269. <filter id="336695337">
  270. <message_arguments>
  271. <message_argument value="org.eclipse.jgit.treewalk.WorkingTreeIterator.Entry"/>
  272. <message_argument value="getLastModifiedInstant()"/>
  273. </message_arguments>
  274. </filter>
  275. <filter id="1142947843">
  276. <message_arguments>
  277. <message_argument value="5.1.9"/>
  278. <message_argument value="getLastModifiedInstant()"/>
  279. </message_arguments>
  280. </filter>
  281. </resource>
  282. <resource path="src/org/eclipse/jgit/util/FS.java" type="org.eclipse.jgit.util.FS">
  283. <filter id="1142947843">
  284. <message_arguments>
  285. <message_argument value="4.5.6"/>
  286. <message_argument value="fileAttributes(File)"/>
  287. </message_arguments>
  288. </filter>
  289. <filter id="1142947843">
  290. <message_arguments>
  291. <message_argument value="5.1.9"/>
  292. <message_argument value="getFileStoreAttributes(Path)"/>
  293. </message_arguments>
  294. </filter>
  295. <filter id="1142947843">
  296. <message_arguments>
  297. <message_argument value="5.1.9"/>
  298. <message_argument value="lastModifiedInstant(File)"/>
  299. </message_arguments>
  300. </filter>
  301. <filter id="1142947843">
  302. <message_arguments>
  303. <message_argument value="5.1.9"/>
  304. <message_argument value="lastModifiedInstant(Path)"/>
  305. </message_arguments>
  306. </filter>
  307. <filter id="1142947843">
  308. <message_arguments>
  309. <message_argument value="5.1.9"/>
  310. <message_argument value="setAsyncFileStoreAttributes(boolean)"/>
  311. </message_arguments>
  312. </filter>
  313. <filter id="1142947843">
  314. <message_arguments>
  315. <message_argument value="5.1.9"/>
  316. <message_argument value="setLastModified(Path, Instant)"/>
  317. </message_arguments>
  318. </filter>
  319. </resource>
  320. <resource path="src/org/eclipse/jgit/util/FS.java" type="org.eclipse.jgit.util.FS$Attributes">
  321. <filter id="1142947843">
  322. <message_arguments>
  323. <message_argument value="5.1.9"/>
  324. <message_argument value="getLastModifiedInstant()"/>
  325. </message_arguments>
  326. </filter>
  327. </resource>
  328. <resource path="src/org/eclipse/jgit/util/FS.java" type="org.eclipse.jgit.util.FS$FileStoreAttributes">
  329. <filter id="1142947843">
  330. <message_arguments>
  331. <message_argument value="5.1.9"/>
  332. <message_argument value="FileStoreAttributes"/>
  333. </message_arguments>
  334. </filter>
  335. </resource>
  336. <resource path="src/org/eclipse/jgit/util/FileUtils.java" type="org.eclipse.jgit.util.FileUtils">
  337. <filter id="1142947843">
  338. <message_arguments>
  339. <message_argument value="5.1.8"/>
  340. <message_argument value="touch(Path)"/>
  341. </message_arguments>
  342. </filter>
  343. </resource>
  344. <resource path="src/org/eclipse/jgit/util/Monitoring.java" type="org.eclipse.jgit.util.Monitoring">
  345. <filter id="1109393411">
  346. <message_arguments>
  347. <message_argument value="5.1.13"/>
  348. <message_argument value="org.eclipse.jgit.util.Monitoring"/>
  349. </message_arguments>
  350. </filter>
  351. </resource>
  352. <resource path="src/org/eclipse/jgit/util/SimpleLruCache.java" type="org.eclipse.jgit.util.SimpleLruCache">
  353. <filter id="1109393411">
  354. <message_arguments>
  355. <message_argument value="5.1.9"/>
  356. <message_argument value="org.eclipse.jgit.util.SimpleLruCache"/>
  357. </message_arguments>
  358. </filter>
  359. </resource>
  360. <resource path="src/org/eclipse/jgit/util/Stats.java" type="org.eclipse.jgit.util.Stats">
  361. <filter id="1109393411">
  362. <message_arguments>
  363. <message_argument value="5.1.9"/>
  364. <message_argument value="org.eclipse.jgit.util.Stats"/>
  365. </message_arguments>
  366. </filter>
  367. </resource>
  368. <resource path="src/org/eclipse/jgit/util/SystemReader.java" type="org.eclipse.jgit.util.SystemReader">
  369. <filter id="1142947843">
  370. <message_arguments>
  371. <message_argument value="5.1.9"/>
  372. <message_argument value="getSystemConfig()"/>
  373. </message_arguments>
  374. </filter>
  375. <filter id="1142947843">
  376. <message_arguments>
  377. <message_argument value="5.1.9"/>
  378. <message_argument value="getUserConfig()"/>
  379. </message_arguments>
  380. </filter>
  381. </resource>
  382. </component>