- Apr 28, 2010
-
-
Shawn Pearce authored
The pack files were left open after the test ended, which meant we could not delete them automatically when the test was over. Make sure we close the repositories (and thus their underlying packs) before the tear down finishes. Bug: 310367 Change-Id: I4d2703efa4b2e0c347ea4f4475777899cf71073e Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Apr 27, 2010
-
-
Chris Aniszczyk authored
It is incorrect to use Eclipse.org as the providerName now, we'll use Eclipse JGit. Change-Id: I1621b93d4f401176704e7c43935a5ce0c8ee8419 Signed-off-by:
Chris Aniszczyk <caniszczyk@gmail.com>
-
- Apr 24, 2010
-
-
Robin Rosenberg authored
-
- Apr 23, 2010
-
-
Shawn Pearce authored
If a corrupt loose object is read, UnpackedObjectLoader was disposing of the Inflater, and then attempting to return the disposed Inflater to the InflaterCache. Since the disposed Inflater had its native libz resource deallocated and its reference cleared out, the Inflater threw NullPointerException and refused to reset itself before being put back into the cache. Instead of disposing of the Inflater when corruption is found, do nothing, and allow it to be returned to the cache. The instance will get reset, and should be usable by a future caller. Bug: 310291 Change-Id: I44f2247c08b6e04fa62f8399609341b07508c096 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Apr 20, 2010
-
-
Shawn Pearce authored
* receive-pack-filter: ReceivePack: Clarify the check reachable option ReceivePack: Micro-optimize object lookup when checking connectivity ReceivePack: Correct type of not provided object IndexPack: Tighten up new and base object bookkeeping ReceivePack: Remove need new,base object id properties ReceivePack: Discard IndexPack as soon as possible ReceivePack: fix ensureProvidedObjectsVisible on thin packs Change-Id: I4ef2fcb931f3219872e0519abfcee220191d5133
-
- Apr 17, 2010
-
-
Matthias Sohn authored
-
Matthias Sohn authored
-
Robin Rosenberg authored
-
Shawn Pearce authored
This option was mis-named from day 1. Its not checking that the objects provided by the client are reachable, its actually doing a scan to prove that objects referenced by the client are already reachable through another reference on the server, or were sent as part of the pack from the client. Rename it checkReferencedObjectsAreReachable, since we really are trying to validate that objects referenced by the client's actions are reachable to the client. We also need to ensure we run checkConnectivity() anytime this is enabled, even if the caller didn't turn on fsck for object formats. Otherwise the check would be completely bypassed. Change-Id: Ic352ddb0ca8464d407c6da5c83573093e018af19 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
If we are checking the visibility of everything referenced in the pack that isn't already reachable by a reference, it needs to be in the provided set. Since the provided set lists everything that is in this pack, we can avoid checking to see if the blob exists on disk, because we know it should be there, it was found in the pack we just consumed. Change-Id: Ie3c7746f734d13077242100a68e048f1ac18c34a Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
If a tree was referenced but not provided in the pack, report it as a missing tree and not as a missing blob. Change-Id: Iab05705349cdf0d30cc3f8afc6698a8d2a941343 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
The only current consumer of these collections is ReceivePack, where it needs to test ObjectId equality between a RevObject and an ObjectId. There we were copying from a traditional HashSet<ObjectId> into an ObjectIdSubclassMap<ObjectId>, as the latter can perform hashing using ObjectId's native value support, bypassing RevObject's override on hashCode() and equals(). Instead of doing that copy, directly create ObjectIdSubclassMap instances inside of ReceivePack. We also only need to record the objects that do not appear in the incoming pack, and were therefore copied from the local repositiory in order to complete delta resolution. Instead of listing everything that used an OBJ_REF_DELTA format, list only the objects that we pulled from the destination repository via a normal ObjectLoader. ReceivePack can now discard the IndexPack object, and all of its other data, as soon as these collections are held by the check connectivity method. This frees up memory for the ObjectWalk's own RevObject pool. Change-Id: I22ef71b45c2045a0202e7fd550a770ee1f6f38a6 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Apr 16, 2010
-
-
Shawn Pearce authored
These are more like internal implementation details of how IndexPack works with ReceivePack to validate the incoming object stream. Callers who are embedding the ReceivePack logic in their own application don't really need to know the details of which objects were used for delta bases in the incoming thin pack, or exactly which objects were newly transmitted. Hide these from the API, as exposing them through ReceivePack was an early mistake. Change-Id: I7ee44a314fa19e6a8520472ce05de92c324ad43e Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
The IndexPack object carries a good bit of state within itself about the objects received over the wire. The earlier we can discard it, the sooner the GC is able to reclaim this chunk of memory for other uses. So drop it as soon as we are certain the pack is valid and we have no connectivity concerns. Change-Id: I1e8bc87c2e9183733043622237a064e55957891f Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
If ensureProvidedObjectsVisible is enabled we expected any trees or blobs directly reachable from an advertised reference to be marked with UNINTERESTING. Unfortunately ObjectWalk doesn't bother setting this until the traversal is complete. Even then it won't necessarily set it on every tree if the corresponding commit wasn't popped. When we are going to check the base objects for the received pack, ensure the UNINTERESTING flag gets carried into every immediately reachable tree or blob, because these are the ones that the client might try to use as delta bases in a thin pack. Change-Id: I5d5fdcf07e25ac9fc360e79a25dff491925e4101 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
The Iterator contract says next() shall throw NoSuchElementException if there are no more items remaining in the iteration. We got this wrong when I originally wrote the implementation, so fix it. Change-Id: Iea25e6569ead5c8b3128b8a368c5b2caebec7ecc Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
This class behaves like a cross between a Set and a Map, sometimes we might expect to use the method isEmpty() to test for size() == 0. So implement it, reducing the surprise folks get when they are given one of these objects. Change-Id: I0d68e1243da8e62edf79c6ba4fd925f643e80a88 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
If we need to append less than 20 bytes in order to fix a thin pack and make it complete, we need to set the length of our file back to the actual number of bytes used because the original SHA-1 footer was not completely overwritten. That extra data will confuse the header and footer fixup logic when it tries to read to the end of the file. This isn't a very common case to occur, which is why we've never seen it before. Getting a delta that requires a whole object which uses less than 20 bytes in pack representation is really hard. Generally a delta generator won't make these, because the delta would be bigger than simply deflating the whole object. I only managed to do this with a hand-crafted pack file where a 1 byte delta was pointed to a 1 byte whole object. Normally we try really hard to avoid truncating, because its typically not safe across network filesystems. But the odds of this occurring are very low. This truncation is done on a file we have open for writing, will append more content onto, and is a temporary file that we won't move into position for others to see until we've validated its SHA-1 is sane. I don't think the truncate on NFS issue is something we need to worry about here. Change-Id: I102b9637dfd048dc833c050890d142f43c1e75ae Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Apr 15, 2010
-
-
Shawn Pearce authored
Since cc905e7d "Make Repository.getConfig aware of changed config" its invalid to have a null result from FileBasedConfig.getFile(), as the path is used to stat the location on disk before returning the Config object from Repository.getConfig(). Mock out the isOutdated() method to return false all of the time in the mock test environment, so we don't crash with an NPE when this mock user configuration is being called. Change-Id: I0b4d9cbd346d5dc225ec12674da905c35457fa7c Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Apr 13, 2010
-
-
Robin Rosenberg authored
We can avoid one stat call by trying to perform a directory listing without checking if the reference File is a directory. Attempting a directory listing is defined to return. The other case for null returns from list is when an I/O error occcurs. Both cases are now intepreted as a possible plain reference. I/O errors when reading plain references will be handled (ignored) in scanRef(). Change-Id: I9906ed8c42eab4d6029c781aab87b3b07c1a1d2c Signed-off-by:
Robin Rosenberg <robin.rosenberg@dewire.com>
-
Matthias Sohn authored
-
- Apr 12, 2010
-
-
Jens Baumgart authored
In the current implementation Repository reads user and repository config only at creation point of time. The new implementatiopn checks in Repository.getConfig if user or repository config have changed on disk and reload the config if required. Change-Id: Ibd97515919ef66c6f8aa1a4fe8a11a6711335dad Signed-off-by:
Jens Baumgart <jens.baumgart@sap.com>
-
- Apr 11, 2010
-
-
Shawn Pearce authored
-
Shawn Pearce authored
Conflicts: org.eclipse.jgit.packaging/pom.xml Change-Id: I248a72575ff23fecf7599c06517c909f43f95ee4
-
- Apr 10, 2010
-
-
Matthias Sohn authored
Change-Id: I99bac3376d9460ab94b548bd2f83be6fbc6ecbe3 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
Robin Rosenberg authored
We only need to check file existense if some other stat returns a value that may mean that the file does not exist. File.length() == 0 or File.lastModified() == 0 are two such properties. We use length here. Change-Id: If626b12e7bb4da994b5c086f6a5b7a12c187261c Signed-off-by:
Robin Rosenberg <robin.rosenberg@dewire.com>
-
- Apr 05, 2010
-
-
Robin Rosenberg authored
The JSch bundle in Eclipse 3.4 does not export its packages with version numbers. Use Require-Bundle on version 0.1.37 that comes with Eclipse 3.4 There is no 0.1.37 in the maven repositories so the pom still refers to 0.1.41 so the build can get the compile time dependencies right. Bug: 308031 CQ: 3904 jsch Version: 0.1.37 (using Orbit CQ2014) Change-Id: I12eba86bfbe584560c213882ebba58bf1f9fa0c1 Signed-off-by:
Robin Rosenberg <robin.rosenberg@dewire.com>
-
- Mar 23, 2010
-
-
Marc Strapetz authored
RawParseUtils.parsePersonIdent handles now those invalid byte sequences which would result in IndexOutOfBoundsException and returns null in this case.
-
- Mar 22, 2010
-
-
Shawn Pearce authored
* stable-0.7: Qualify post-0.7.1 builds JGit 0.7.1
-
Shawn Pearce authored
Change-Id: Ifad1a5a6f2909d709fd7834b32b9b9949b2e5633 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
* stable-0.7: Fix EGit deadlock listing branches of SSH remote
-
Shawn Pearce authored
Change-Id: Ica516f1e34335ca7a05b071fd527027b10bb7e73 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Mar 21, 2010
-
-
Shawn Pearce authored
When listing branches, EGit only reads the advertisement and then disconnects. When it closes down the pack channel the remote side is waiting for the client to send our list of commands, or a flush-pkt to let it know there is nothing to do. However if an error thread is open watching the SSH stderr stream, we ask for it to finish before we send the flush-pkt. Unfortunately the thread won't terminate until the main output stream closes, which is waiting for the flush-pkt. A classic network deadlock. If the output stream needs a flush-pkt we send it before we wait for the error stream to close. If the flush-pkt is rejected, we close down the output stream early, assuming that the remote side is broken and we will get error information soon. Change-Id: I8d078a339077756220c113f49d206b1bf295d434 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
* stable-0.7: Qualify post-0.7.0 builds JGit 0.7.0 This is an 'ours' merge to avoid bringing in the 0.7.0 version numbers in the manifest and pom files. Change-Id: Iad6354af57aaa2f233142fbf679489b08c121a71
-
Shawn Pearce authored
Since the API is changing relative to 0.7.0, we'll call our next release 0.8.1. But until that gets released, builds from master will be 0.8.0.qualifier. Change-Id: I921e984f51ce498610c09e0db21be72a533fee88 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
* stable-0.7: tools/version.sh: Update OSGi manifest files Drop CQ 3448 from IP log Change-Id: I8d78d27c48c16a70078bf76b255f8ade8e94db2a
-
Shawn Pearce authored
Change-Id: I5afdc624b28fab37b28dd2cc71d334198672eef3 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Mar 19, 2010
-
-
Shawn Pearce authored
Change-Id: I9b00a4041c19115e81326afd2213b98603f789ad
-
Shawn Pearce authored
Tag the version number and API range in the OSGi manifest files whenever we bump the pom.xml files. Change-Id: I7c38b51f7139c02bef6b0e67d3f9199cbcdc8a39 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Because this is the original contribution made under the project's official license, EMO has tagged it "epl" and dropped it from the project's IP log. Change-Id: I55a2a57c570a555f4c86903767d60ae7cfddacbe Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-