- Jun 07, 2010
-
-
Chris Aniszczyk authored
The JGit feature's build.properties was referring to a notice.html instead of license.html Change-Id: I642e2a05d1be58b1d47fd9701edf1a0f2bfa3660 Signed-off-by:
Chris Aniszczyk <caniszczyk@gmail.com>
-
Chris Aniszczyk authored
The Eclipse Foundation requires the standard SULA be present in every feature. We had the license present via edl-v10.html but we were missing the SULA via the license.html file. The fix is to simply add the SULA. Change-Id: I75b43ce098f544b95181755b5cc81a9b1dee6391 Signed-off-by:
Chris Aniszczyk <caniszczyk@gmail.com>
-
- Jun 05, 2010
-
-
Matthias Sohn authored
Building jgit with pde.build was broken without resources. Bug:315823 Change-Id: I45be510ada068b3ffab0feb30ec60f2c96a5ca32 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- Jun 02, 2010
-
-
Shawn Pearce authored
Change-Id: Id86e5876b2f684b2a272c07061a276b054ba410d Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Change-Id: I3d4ac7d0617a3575019e2ed748ed2a298a988340 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Change-Id: I3103c54a2a525f5f190cf35b63394dad6d02cc5e Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- Jun 01, 2010
-
-
Shawn Pearce authored
-
- May 29, 2010
-
-
Matthias Sohn authored
Change-Id: I91f249422efbb6aea0491e276ccfe00f5ae7d212 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- May 28, 2010
-
-
Shawn Pearce authored
Wayne changed the schema to no longer be dependent upon the Bugzilla notion of a contribution, but instead be more generic and better support systems like Gerrit Code Review. Update our output to use the <contribution> element and include a link to the change in Gerrit. Change-Id: Ibc8a436918bd8e7597dc17743824201a74bce09b Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
This element documents other Eclipse projects that are consumed by this project. JGit doesn't consume any projects, but its sister project EGit does. Change-Id: Ie922d27c580f6742e2acb051815a381af48df7ca Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Change-Id: I552e77e434487ece9a600de9e09bc17066579773 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
If the last field of our IPzilla query comes back empty, we were skipping over and not including it in the result List, causing an IndexOutOfBoundsException when it was read into our data model. If the last field is empty, actually add the empty string. Change-Id: Ib18b335990c73e036b185199d0004f4ffc395867 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Change-Id: I08b2cdd147ad6f3c67795f2e75a5b5d2ce2fb20f Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- May 27, 2010
-
-
Shawn Pearce authored
The J2SE NIO APIs require that FileChannel close the underlying file descriptor if a thread is interrupted while it is inside of a read or write operation on that channel. This is insane, because it means we cannot share the file descriptor between threads. If a thread is in the middle of the FileChannel variant of IO.readFully() and it receives an interrupt, the pack will be automatically closed on us. This causes the other threads trying to use that same FileChannel to receive IOExceptions, which leads to the pack getting marked as invalid. Once the pack is marked invalid, JGit loses access to its entire contents and starts to report MissingObjectExceptions. Because PackWriter must ensure that the chosen pack file stays available until the current object's data is fully copied to the output, JGit cannot simply reopen the pack when its automatically closed due to an interrupt being sent at the wrong time. The pack may have been deleted by a concurrent `git gc` process, and that open file descriptor might be the last reference to the inode on disk. Once its closed, the PackWriter loses access to that object representation, and it cannot complete sending the object the client. Fortunately, RandomAccessFile's readFully method does not have this problem. Interrupts during readFully() are ignored. However, it requires us to first seek to the offset we need to read, then issue the read call. This requires locking around the file descriptor to prevent concurrent threads from moving the pointer before the read. This reduces the concurrency level, as now only one window can be paged in at a time from each pack. However, the WindowCache should already be holding most of the pages required to handle the working set for a process, and its own internal locking was already limiting us on the number of concurrent loads possible. Provided that most concurrent accesses are getting hits in the WindowCache, or are for different repositories on the same server, we shouldn't see a major performance hit due to the more serialized loading. I would have preferred to use a pool of RandomAccessFiles for each pack, with threads borrowing an instance dedicated to that thread whenever they needed to page in a window. This would permit much higher levels of concurrency by using multiple file descriptors (and file pointers) for each pack. However the code became too complex to develop in any reasonable period of time, so I've chosen to retrofit the existing code with more serialization instead. Bug: 308945 Change-Id: I2e6e11c6e5a105e5aef68871b66200fd725134c9 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- May 24, 2010
-
-
Stefan Lay authored
Merges the current head with one other commit. In this first iteration the merge command supports only fast forward and already up-to-date. Change-Id: I0db480f061e01b343570cf7da02cac13a0cbdf8f Signed-off-by:
Stefan Lay <stefan.lay@sap.com> Signed-off-by:
Christian Halstrick <christian.halstrick@sap.com> Signed-off-by:
Chris Aniszczyk <caniszczyk@gmail.com>
-
- May 20, 2010
-
-
Christian Halstrick authored
The CommitCommand should take care to create a merge commit if the file $GIT_DIR/MERGE_HEAD exists. It should then read the parents for the merge commit out of this file. It should also take care that when commiting a merge and no commit message was specified to read the message from $GIT_DIR/MERGE_MSG. Finally the CommitCommand should remove these files if the commit succeeded. Change-Id: I4e292115085099d5b86546d2021680cb1454266c Signed-off-by:
Christian Halstrick <christian.halstrick@sap.com>
-
- May 19, 2010
-
-
Saša Živkov authored
Ensures all translations exist in the root locale. Change-Id: Ic8a8bdfd4a06c6d1ebd1e85a8082a32c82d155c7
-
Saša Živkov authored
The strings are externalized into the root resource bundles. The resource bundles are stored under the new "resources" source folder to get proper maven build. Strings from tests are, in general, not externalized. Only in cases where it was necessary to make the test pass the strings were externalized. This was typically necessary in cases where e.getMessage() was used in assert and the exception message was slightly changed due to reuse of the externalized strings. Change-Id: Ic0f29c80b9a54fcec8320d8539a3e112852a1f7b Signed-off-by:
Sasa Zivkov <sasa.zivkov@sap.com>
-
Shawn Pearce authored
In close() method of SshFetchConnection and SshPushConnection errorThread.join() can wait forever if JSch will not close the channel's error stream. Join with a timeout, and interrupt the copy thread if its blocked on data that will never arrive. Bug: 312863 Change-Id: I763081267653153eed9cd7763a015059338c2df8 Reported-by:
Dmitry Neverov <dmitry.neverov@gmail.com> Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Dmitry Neverov authored
If we get an interrupt during an IO operation (src.read or dst.write) caused by the flush() method incrementing the flush counter, ensure we restart the proper section of code. Just ignore the interrupt and continue running. Bug: 313082 Change-Id: Ib2b37901af8141289bbac9807cacf42b4e2461bd Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- May 17, 2010
-
-
Shawn Pearce authored
The number of bytes to copy was truncated to an int, but the pack's copyToStream() method expected to be passed a long here. Pass through the long so we don't truncate a giant object. Change-Id: I0786ad60a3a33f84d8746efe51f68d64e127c332 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- May 16, 2010
-
-
Shawn Pearce authored
Rather than holding onto the PackedObjectLoader, only hold the PackFile and the object offset. During a reuse copy that is all we should need to complete a reuse, and the other parts of the PackedObjectLoader just waste memory. This change reduces the per-object memory usage of a PackWriter by 32 bytes on a 32 bit JVM using only OFS_DELTA formatted objects. The savings is even larger (by another 20 bytes) for REF_DELTAs. This is close to a 50% reduction in the size of ObjectToPack, making it rather worthwhile to do. Beyond the memory reduction, this change will help to make future refactoring work easier. We need to redo the API used to support copying data, and disconnecting it from the PackedObjectLoader is a good first step. Change-Id: I24ba4e621e101f14e79a16463aec5379f447aa9b Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Rather than keep track of both the position of the object, and the position of its data, just keep track of the number of bytes used by the object's header in the pack. This shaves 4 bytes out of the size of the PackedObjectLoader instances. We also can defer the addition instruction to the materialize() operation, avoiding it entirely if the caller never actually uses the loader. This may be relevant for PackWriter invocations, where only 1 loader gets chosen for a given object, even though the object may appear on disk in more than one pack file. Error reporting is now simplified, as we can rely on the object offset rather than its data offset. This is the value displayed by pack debugging tools like `git verify-pack -v`, so its better to use that in our own errors. Because nobody needs getDataOffset() now, we can drop that from the public API. Change-Id: Ic639c0d5a722315f4f5c8ffda6e26643d90e5f42 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- May 15, 2010
-
-
Shawn Pearce authored
Since we use this code twice, pull it into a private method. Let the compiler/JIT worry about whether or not this logic should be inlined into the call sites. Change-Id: Ia44fb01e0328485bcdfd7af96835d62b227a0fb1 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
Originally when I wrote this code I had hoped to use OffsetCache to also implement the UnpackedObjectCache. But it turns out they need rather different code, and it just wasn't worth trying to reuse the OffsetCache base class. Before doing any major refactoring or code cleanups here, squash the two classes together and delete OffsetCache. As WindowCache is our only subclass, this is pretty simple to do. We also get a minor code reduction due to less duplication between the two classes, and the JIT should be able to do a better job of optimization here as we can define types up front rather than relying on generics that erase back to java.lang.Object. Change-Id: Icac8bda01260e405899efabfdd274928e98f3521 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
When we read the object header we copy 20 bytes from the pack data, then start parsing out the type and the inflated size. For most objects, this is only going to require 3 bytes, which is sufficient to represent objects with inflated sizes of up to 2^16. The local buffer however still has 17 bytes remaining in it, and that can be used to satisfy the OBJ_OFS_DELTA header. We shouldn't need to worry about walking off the end of the buffer here, because delta offsets cannot be larger than 64 bits, and that requires only 9 bytes in the OFS_DELTA encoding. Assuming worst-case scenarios of 9 bytes for the OFS_DELTA encoding, the pack file itself must be approaching 2^64 bytes, an infeasible size to store on any current technology. However, even if this were the case we still have 11 bytes for the type/size header. In that encoding we can represent an object as large as 2^74 bytes, which is also an infeasible size to process in JGit. So drop the second read here. The data offsets we pass into the ObjectLoaders being constructed need to be computed individually now. This saves a local variable, but pushes the addition operation into each branch of the switch. Change-Id: I6cf64697a9878db87bbf31c7636c03392b47a062 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- May 13, 2010
-
-
Shawn Pearce authored
JSch may hang or abort with the timeout if JGit connects before its obtained the streams. Instead defer the connect() call until after the streams have been configured. Bug: 312383 Change-Id: I7c3a687ba4cb69a41a85e2b60d381d42b9090e3f Reported-by:
Dmitry Neverov <dmitry.neverov@gmail.com> Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Shawn Pearce authored
If a flush() gets delivered at the same time that we are blocking while writing to an interruptable stream, the copy thread will abort assuming its a stream error. Instead ignore the interrupt, and retry the write. Change-Id: Icbf62d1b8abe0fabbb532dbee088020eecf4c6c2 Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
Dmitry Neverov authored
It is possible to miss flush() invocation in StreamCopyThread. In this case some data will not be sent to remote host and we will wait forever (or until timeout) in src.read(). Use a counter to keep track of the flush requests. Change-Id: Ia818be9b109a1674d9e2a9c78e125ab248cfb75b Signed-off-by:
Shawn O. Pearce <spearce@spearce.org>
-
- May 12, 2010
-
-
Christian Halstrick authored
The commit command is added using the new Git class. Currently this supports only the author and commit-message option. Change-Id: I13152575b5b03f6f9e816d0747e7a8c5c6fccade Signed-off-by:
Christian Halstrick <christian.halstrick@sap.com>
-
- May 11, 2010
-
-
Matthias Sohn authored
-
Jonathan Gossage authored
There is a serious problem with the Maven Javadoc plugin. Please see http://jira.codehaus.org/browse/MJAVADOC-275 for details. This problem is fixed by using maven-javadoc-plugin V2.7 instead of maven-javadoc-plugin v2.6.1.
-
Matthias Sohn authored
Change-Id: I86f292039f1b8e499baf05238f55b1d550d098a5 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
Matthias Sohn authored
EGit Tycho builds on build.eclipse.org frequently hit corrupted artifacts which leads to broken builds. Cleaning up these corrupted files is tedious since it requires file system access on the build server. Hence we want to switch to use job-local m2 repositories. This requires that build artifacts are shared between the jgit and egit build jobs via p2. Therefore the bundle org.eclipse.jgit.junit needs to be exposed via p2 repository. Change-Id: I0ccd7763eede117cb68240fdd25f13d6e6f6a2c1 Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
- May 10, 2010
-
-
Christian Halstrick authored
Added a new package org.eclipse.jgit.api and a builder-style API for jgit. Added also the first implementation for two git commands: Commit and Log. This API is intended to be used by external components when functionalities of the standard git commands are required. It will also help to ease writing JGit tests. For internal usages this API may often not be optimal because the git commands are doing much more than required or they expect parameters of an unappropriate type. Change-Id: I71ac4839ab9d2f848307eba9252090c586b4146b Signed-off-by:
Christian Halstrick <christian.halstrick@sap.com>
-
- May 08, 2010
-
-
Robin Rosenberg authored
-
Robin Rosenberg authored
-
Robin Rosenberg authored
Currently, if the Index contains a file in more than one stage, only the last entry (containing the highest stage) will be registered in GitIndex. For applications it can be useful to not only know about the highest stage, but also which other stages are present, e.g. to detect the type of conflict the file is in. Change-Id: I2d4ff9f6023335d9ba6ea25d8e77c8e283ae53cb Signed-off-by:
Robin Rosenberg <robin.rosenberg@dewire.com>
-
Christian Halstrick authored
The repository state tells in which state the repo is and also which actions are currently allowed. The state MERGING is telling that a commit is not possible. But this is only true in the case of unmerged paths in the index. When we are merging but have resolved all conflicts then we are in a special state: We are still merging (means the next commit should have multiple parents) but a commit is now allowed. Since the MERGING state "canCommit()" cannot be enhanced to return true/false based on the index state (MERGING is an enum value which does not have a reference to the repository its state it is representing) I had to introduce a new state MERGING_RESOLVED. This new state will report that a commit is possible. CAUTION: there might be the chance that users of jgit previously blindly did a plain commit (with only one parent) when the RepositoryState allowed them to do so. With this change these users will now be confronted with a RepositoryState which says a commit is possible but before they can commit they'll have to check the MERGE_MESSAGE and MERGE_HEAD files and use the info from these files. Change-Id: I0a885e2fe8c85049fb23722351ab89cf2c81a431 Signed-off-by:
Christian Halstrick <christian.halstrick@sap.com> Signed-off-by:
Matthias Sohn <matthias.sohn@sap.com>
-
Robin Rosenberg authored
-