| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
DfsPackfile used to have only one constructor and it is invoked from 3
locations. Now we can construct DfsPackFiles with different bitmap
loaders, so it is helpful to concentrate the instantiation in one location.
Create DfsPackFile instances in the object database. This let
subclasses choose how to initialize those instances.
Change-Id: Ibb2ad86865154b6e7f0d5d26e8f533e0b5586246
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current code reads the bitmap index from the pack extension and loads
all bitmaps into memory, with its IO and memory cost. We could
consider to store the bitmaps on e.g. a database and load them on
demand.
Abstract the loading of the PackBitmapIndex in an interface that can
be implemented with other backends.
Change-Id: Ib5f64d05954708ea5325feea7088a8df229b36a5
|
|
|
|
| |
Change-Id: I0d81fda5edde5348e765eebc39bd9293fba51e91
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
getObjectSize reads the size from the first bytes of the object in the
pack, using IO. For blobs and depending on the configuration, the size
could be available in the object size index.
Try to get the size from the object size index if available. Read from
the pack otherwise.
Note that GC uses #getObjectSize from the existing pack to write the
next object size index.
Change-Id: Ia999290c06d061cb53aa8c0a2b28b1a9761567ef
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit db5ce6b5c24408ae27eb6fa0b6289d51b129baeb.
Reason to revert: This change utilizes the RewriteGenerator even in
absence of a path, making the walk lengthy.
Change-Id: I5ffa6e8fead328191348c1e46828bf8c75ae1e42
|
|\ \
| |/
|/|
| |
| |
| |
| |
| | |
* stable-6.8:
Delete org.eclipse.jgit.ssh.apache.agent/bin/.project
Allow to discover bitmap on disk created after the packfile
Change-Id: I08095dfaefb963876d993383cb35acc6b75d7691
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* stable-6.7:
Delete org.eclipse.jgit.ssh.apache.agent/bin/.project
Allow to discover bitmap on disk created after the packfile
Change-Id: I01749bae6f46d1a8ebd25b890e667cc092f3a659
|
| | |\
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* stable-6.6:
Delete org.eclipse.jgit.ssh.apache.agent/bin/.project
Allow to discover bitmap on disk created after the packfile
Change-Id: I2bbc8c9a4ed45d37fa7ba63b2afd5511b6cf47a2
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When the bitmap file was created *after* a packfile had been
loaded into the memory, JGit was unable to discover them.
That happed because of two problems:
1. The PackDirectory.getPacks() does not implement the usual
while loop that is scanning through the packs directory
as in the other parts of JGit.
2. The scan packs does not look for newly created bitmap files
if the packfile is already loaded in memory.
Implement the normal packfiles scanning whenever the PackDirectory
needs to return a list of packs, and make sure that any reused
Pack object would have its associated bitmap properly refreshed
from disk.
Adapt the assertions in GcConcurrentTest with the rescanned list
of Pack from the objects/packs directory.
Bug: jgit-15
Change-Id: I2ed576cefd78a0e128b175228a59c9af51523d7b
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Original implementation by Han-Wen Nienhuys in Gerrit [1].
[1] https://gerrit-review.googlesource.com/c/gerrit/+/235169
Bug: jgit-24
Change-Id: I745f8c1c07de013a68168b91c2d9962d530d07bf
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If we try to delete a tmp file and it already doesn't exist, then
there's no problem and we don't need to throw an exception. This is
especially true for these existing cases using FileUtils.RETRY because
any missing files on retries are already considered successes. Not
throwing the exception quiets some logs and improves overall exception
handling.
Change-Id: Ia6e06ba042c5920d5cd9f8db2e1d829affa3d796
Signed-off-by: Nasser Grainawi <quic_nasserg@quicinc.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When multiple JGit clients are instantiated concurrently, they may try
to create the same symlink at the same time. When that happens, the
second thread will return an error (because the symlink already exists)
and that `FS` instance will think that symlinks are not supported,
causing havoc.
Change-Id: I362b933ff63a1471e3a5d70cc8c35eb2f25cc0dd
Signed-off-by: Motiejus Jakštys <motiejus@jakstys.lt>
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* changes:
Errorprone EscapedEntity: Do not use HTML entities inside @code javadoc
ChangedPathFilter: Suppress warning about backing array (errorprone)
|
| | | | |
| | | | |
| | | | |
| | | | | |
Change-Id: I8e577a23e7fbe22a3024ad62144e7f19eec465c3
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Errorprone warns about direct access to the underlying array.
That is the intention of this code, and those ByteBuffers are created
with ByteBuffer#wrap() so it should be safe.
Change-Id: Ic8e8b288f08ac794cf7f09dfccfefcba0a4685bf
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
* changes:
RawParseUtils.nextLfSkippingSplitLines: fulfil contract as stated
[gpg] Refactor the GpgSignatureVerifier
RawParseUtils: utility method to get a header value
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
If there is no newline after the last header, the method is supposed to
return the buffer length, but it returned buffer.length - 1.
Change-Id: I9225d6a35a002244c246bc8781ceaf4369fb9a60
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add a new method verify(GpgConfig, byte[], byte[]) and deprecate the
existing verify(byte[], byte[]). Some implementations of the interface
may need the GpgConfig.
Factor out extracting the raw armored signature from commits or tags
into an abstract AbstractGpgSignatureVerifier class so that different
implementations don't have to re-implement that bit. Call the new verify
method, passing along the GpgConfig.
This makes the GPG interfaces more versatile and facilitates
implementing an alternate GpgSignatureVerifier.
Change-Id: I9cf093caa9fdebede801d665f2591cd9b275e1fd
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The new method takes care of removing the leading blanks on continuation
lines in multi-line headers.
Change-Id: Id5a8063512a2abc3177c104d6ba8fa50d0dc6352
|
|\ \ \ \ \
| | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* stable-6.8:
RefDirectory: Do not unlock until after deleting loose ref
Add missing javadoc description for declared exception
SnapshottingRefDirectory: Invalidate snapshot after locking ref for update
SnapshottingRefDir: Replace lambas with method refs
SnapshottingRefDir: Reduce casts with overrides
[errorprone] Fix wrong comparison which always evaluated to false
[errorprone] Remove unnecessary comparison
Change-Id: I1d65c41292779dd5f8f46bc0adefbfc9a62ba2ce
|
| |\ \ \ \
| | | |/ /
| | |/| |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* stable-6.7:
RefDirectory: Do not unlock until after deleting loose ref
Add missing javadoc description for declared exception
SnapshottingRefDirectory: Invalidate snapshot after locking ref for update
SnapshottingRefDir: Replace lambas with method refs
SnapshottingRefDir: Reduce casts with overrides
[errorprone] Fix wrong comparison which always evaluated to false
[errorprone] Remove unnecessary comparison
Change-Id: Ic6312bd3b2b1db38a287ebc7f31062251341438a
|
| | |\ \ \
| | | | |/
| | | |/|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* stable-6.6:
RefDirectory: Do not unlock until after deleting loose ref
Add missing javadoc description for declared exception
SnapshottingRefDirectory: Invalidate snapshot after locking ref for update
SnapshottingRefDir: Replace lambas with method refs
SnapshottingRefDir: Reduce casts with overrides
Change-Id: Ic5f3c46e5557d0bd143694bd6020b67b6ec8f22e
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fix a potential race condition where we would remove our loose ref lock
file before deleting the loose ref itself. This race could result in the
current thread deleting a loose ref newly written by another thread.
Other callers seem to be following the correct pattern, but improve the
method naming to try to help future callers.
Change-Id: I80cebe4788edd855e15381336d980c41498fca80
Signed-off-by: Nasser Grainawi <quic_nasserg@quicinc.com>
|
| | | | |
| | | | |
| | | | |
| | | | | |
Change-Id: I16305bc15d2ddff1ce055772a711658ef81858e2
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
update
When using the SnapshottingRefDirectory, if a thread has already read
packed-refs, then another actor updates packed-refs, the original
thread may create an update that is based on the old cached/snapshotted
packed-refs content. That update could effectively perform a forced
update unintentionally because it is unaware of the new content.
This seems particularly likely to happen in a scenario where a loose
ref was just packed. If the ref was loose, our thread would see the
current ref value (because we don't snapshot loose refs and always read
them from disk), but since there is no loose ref, we expect to find the
current value in packed-refs. However, (before this change) we rely
on our snapshot of packed-refs which does not contain the updated ref
value.
Invalidating the cache after the loose ref is locked ensures that the
ref value does not change again before we read it to perform the update.
Bug: jgit-21
Change-Id: Id10900a99bfd0401a1b9c39d997093af0289649e
Signed-off-by: Nasser Grainawi <quic_nasserg@quicinc.com>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Method references are shorter and easier to read in this case.
Change-Id: Ia6809fa0e3f282acbe7b7f7e3813a34f3cf40c43
Signed-off-by: Nasser Grainawi <quic_nasserg@quicinc.com>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Overriding getRefDirectory() and getRefDatabase() lets us skip casting
to SnapshottingRefDirectory in several places.
Change-Id: I61ba12fb6f066b1a9c4ea5ec9538978cbf040acd
Signed-off-by: Nasser Grainawi <quic_nasserg@quicinc.com>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
org.eclipse.jgit/src/org/eclipse/jgit/internal/storage/commitgraph/GraphObjectIndex.java:59:
error: [ComparisonOutOfRange] ints may have a value in the range
-2147483648 to 2147483647; therefore, this comparison to
Integer.MAX_VALUE will always evaluate to false
if (table[k] > Integer.MAX_VALUE) {
^
See https://errorprone.info/bugpattern/ComparisonOutOfRange
We need to check if variable `uint` of type `long` exceeds the maximum
possible int value before casting it to `int` below.
This was introduced in Ib5c0d6678cb242870a0f5841bd413ad3885e95f6
Change-Id: I675d594f523084be4c1678328cc343065e32d998
(cherry picked from commit 916200e278ebeaa2602b5dc23143c8eedf11858b)
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Raised by errorprone:
org.eclipse.jgit/src/org/eclipse/jgit/lib/CommitConfig.java:406: error:
[ComparisonOutOfRange] chars may have a value in the range 0 to 65535;
therefore, this comparison to 0 will always evaluate to true
if (ch >= 0 && ch < inUse.length) {
^
see https://errorprone.info/bugpattern/ComparisonOutOfRange
Change-Id: I9625aa7894a34dbffd77d39a40c6e285c86b56d5
(cherry picked from commit cf5ec856bda907c0537ce5a80246b9ab18195c8b)
|
| |\| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* stable-6.7:
Improve handling of NFS stale handle errors
Fix handling of missing pack index file
Add tests for handling pack files removal during fetch
Change-Id: I409d1dc3354ad65c048d2c40f39071a1207246c6
|
| | |\| |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* stable-6.6:
Improve handling of NFS stale handle errors
Fix handling of missing pack index file
Add tests for handling pack files removal during fetch
Change-Id: Ie00984319d68beeffcbdb6bb323fbeb94a118e5c
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Mark packfile as invalid when NFS stale handle error occurs.
This should fix broken fetch operations when the repo is located on the
NFS system and is GC'ed on a separate system (or process). Which may
result in the index, pack or bitmap file being removed when they are
accessed from the fetch operation.
Bug: 573770
Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com>
Change-Id: I70217bfb93bf7421ea2c1d74cbe4f15c76d9c098
(cherry picked from commit c701c01b49d92993f1c3df0a0e26a2dd68b8cec1)
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As demonstrated in
`UploadPackHandleDeletedPackFile.testV2IdxFileRemovedDuringUploadPack`
the fetch operation will fail when the pack index file is removed.
This is due to a wrapping of `FileNotFoundException` (which is a
subclass of `IOExeption`) in an `IOException` at PackIndex L#68. This
is then changing the behaviour of error handling in
`Pack.file.getBitmapIndex()` where the `FileNotFoundException` is
swallowed and allows the fetch process to continue. With FNFE being
wrapped in IOE, this blows up and breaks the fetch operation.
Simply rethrowing `FileNotFoundException` from `PackFile.open()` fixes
the broken fetch operation. This will also mark the whole pack as
invalid in the `IOException` handler in `Pack.idx()` method.
Change-Id: Ibe321aa1af21d26500e1cb2eb3464cc99a6dbc62
Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com>
(cherry picked from commit e0910eda3ea1c474b4cf9b00ac698f739a982f8c)
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In https://review.gerrithub.io/c/eclipse-jgit/jgit/+/1174407, I changed the bitmap selection algorithm to cap the number of branches included in the bitmap.
There was a bug in that change. When the selection algorithm iterates
over the commits in a branch B, it automatically includes a bitmap for
the tip of any other branch C that happens to be on B. So even though we never iterated over C, we would still index the tip commit of C.
Keep a list of the "excessive" branch tips and check that the commit is not in there before generating a bitmap. We only skip tips that would be selected as a result of being a tip. If it would be selected for some other reason (e.g. it is one of the first 100 commits in master) then it is not skipped.
Change-Id: Ic8b4f82e816eac649a47c8918a41ed4ff0d877cd
|
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
During shutdown the JGitText class may already be unloaded causing
NoClassDefFoundError.
Bug: jgit-17
Change-Id: I657b5a508efc8b3778be346d640f4e4d69abd5c5
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If rebasing runs into a conflict when applying a root commit from an
independent branch, there is no parent commit. Write an empty patch
file in that case like C git does.
Bug: jgit-6
Change-Id: I315313673d2abf29639d7d96c958d599961ba276
Signed-off-by: Thomas Wolf <twolf@apache.org>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Mark packfile as invalid when NFS stale handle error occurs.
This should fix broken fetch operations when the repo is located on the
NFS system and is GC'ed on a separate system (or process). Which may
result in the index, pack or bitmap file being removed when they are
accessed from the fetch operation.
Bug: 573770
Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com>
Change-Id: I70217bfb93bf7421ea2c1d74cbe4f15c76d9c098
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As demonstrated in
`UploadPackHandleDeletedPackFile.testV2IdxFileRemovedDuringUploadPack`
the fetch operation will fail when the pack index file is removed.
This is due to a wrapping of `FileNotFoundException` (which is a
subclass of `IOExeption`) in an `IOException` at PackIndex L#68. This
is then changing the behaviour of error handling in
`Pack.file.getBitmapIndex()` where the `FileNotFoundException` is
swallowed and allows the fetch process to continue. With FNFE being
wrapped in IOE, this blows up and breaks the fetch operation.
Simply rethrowing `FileNotFoundException` from `PackFile.open()` fixes
the broken fetch operation. This will also mark the whole pack as
invalid in the `IOException` handler in `Pack.idx()` method.
Change-Id: Ibe321aa1af21d26500e1cb2eb3464cc99a6dbc62
Signed-off-by: Dariusz Luksza <dariusz.luksza@gmail.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Originally I wanted to support a feature similar to `-x` options from
https://git-scm.com/docs/git-cherry-pick#_options.
The idea was to append original commit hash in this format:
```
my original commit message
(cherry picked from commit 75355897dc28e9975afed028c1a6d8c6b97b2a3c)
```
This can be useful information in some integrations.
I decided to make it in a more generic way
and pass custom `CherryPickCommitMessageProvider` implementation.
One of the two default implementations can append original commit hash
Change-Id: Id664e8438b0b76c5cb9b58113887eec04aa6f611
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This method was introduced in 8116f66b9c.
Change-Id: Ifd3341a03464a1d7164c176cf3a6cf83f45a2747
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
and remove unused API problem filters.
Change-Id: Ia6f4fcc98b786e3e4b65f9e42cc60bbf6ca7c289
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* stable-6.8:
Introduce a PriorityQueue sorting RevCommits by commit timestamp
Remove org.eclipse.jgit.benchmark/.factorypath
Update jmh to 1.37 for org.eclipse.jgit.benchmark
Change-Id: Ifdd88eed34be3a1f4897b468392fd86bbc3f3a64
|
| |\| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* stable-6.7:
Introduce a PriorityQueue sorting RevCommits by commit timestamp
Remove org.eclipse.jgit.benchmark/.factorypath
Update jmh to 1.37 for org.eclipse.jgit.benchmark
Change-Id: I5d49a9dc7da17b83243229d4d8d3b9ee0a063e65
|
| | |\|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* stable-6.6:
Introduce a PriorityQueue sorting RevCommits by commit timestamp
Remove org.eclipse.jgit.benchmark/.factorypath
Update jmh to 1.37 for org.eclipse.jgit.benchmark
Change-Id: I76ebca527e523f124bfe81c821169c790eddccb6
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The DateRevQueue uses a tailor-made algorithm to keep
RevCommits sorted by reversed commit timestamp, which has a O(n*n/2)
complexity and caused the explosion of the Git fetch times to
tens of seconds.
The standard Java PriorityQueue provides a O(n*log(n)) complexity
and scales much better with the increase of the number of
RevCommits.
Introduce a new implementation DateRevPriorityQueue of the DateRevQueue
based on PriorityQueue.
Enable usage of the new DateRevPriorityQueue implementation by setting
the system property REVWALK_USE_PRIORITY_QUEUE=true. By default the old
implementation DateRevQueue is used.
Benchmark results:
```
(numCommits) (usePriorityQueue) Mode Cnt Score Error Units
5 true avgt 10 39,4 ± 6,1 ns/op
5 false avgt 10 14,1 ± 2,2 ns/op
10 true avgt 10 29,7 ± 3,5 ns/op
10 false avgt 10 13,2 ± 2,0 ns/op
50 true avgt 10 50,4 ± 5,3 ns/op
50 false avgt 10 18,6 ± 0,2 ns/op
100 true avgt 10 58,3 ± 5,0 ns/op
100 false avgt 10 20,5 ± 0,8 ns/op
500 true avgt 10 51,7 ± 2,6 ns/op
500 false avgt 10 43,3 ± 0,5 ns/op
1000 true avgt 10 49,2 ± 2,4 ns/op
1000 false avgt 10 62,7 ± 0,2 ns/op
5000 true avgt 10 48,8 ± 1,5 ns/op
5000 false avgt 10 228,3 ± 0,5 ns/op
10000 true avgt 10 44,2 ± 0,9 ns/op
10000 false avgt 10 377,6 ± 2,7 ns/op
50000 true avgt 10 50,3 ± 1,6 ns/op
50000 false avgt 10 637,0 ± 111,8 ns/op
100000 true avgt 10 61,8 ± 4,4 ns/op
100000 false avgt 10 965,1 ± 268,0 ns/op
500000 true avgt 10 127,2 ± 7,9 ns/op
500000 false avgt 10 9610,2 ± 184,8 ns/op
```
Memory allocation results:
```
Number of commits loaded: 850 000
Custom implementation: 378 245 120 Bytes
Priority queue implementation: 340 495 616 Bytes
```
Bug: 580137
Change-Id: I8b33df6e9ee88933098ecc81ce32bdb189715041
Signed-off-by: Luca Milanesio <luca.milanesio@gmail.com>
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If there are too many branches then the bitmap
indexing selects only the tip commits of the least active
branches to reduce the amount of bitmaps to load on request.
This can still be a problem if the number of inactive branches
rival or exceed the total number of commits selected
for the active branches.
Limit the number of branches that receive only-tip bitmaps.
This reduces the memory pressure of loading all the bitmaps,
and allows us to model the size of the bitmap index without
considering the number of branches.
Bitmaps are generated for branches in order of most recent commit,
and follow these rules:
* The first {@code DEFAULT_BITMAP_EXCESSIVE_BRANCH_COUNT} most active
branches have full bitmap coverage.
* The {@code DEFAULT_BITMAP_EXCESSIVE_BRANCH_COUNT} to {@code
DEFAULT_BITMAP_EXCESSIVE_BRANCH_TIP_COUNT} most active branches have
only the tip commit covered.
* The remaining branches have no bitmap coverage.
To prevent effecting existing repositories, the default value is set
at Integer.MAX_VALUE.
Change-Id: I7cc53c898cdc04953b95669be0b069543e10c6f8
|
|\ \ \ \ \ |
|