Skip to content
Snippets Groups Projects
  1. Jun 07, 2010
  2. Jun 05, 2010
  3. Jun 02, 2010
  4. Jun 01, 2010
  5. May 29, 2010
  6. May 28, 2010
  7. May 27, 2010
    • Shawn Pearce's avatar
      Don't use interruptable pread() to access pack files · 16419dad
      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: default avatarShawn O. Pearce <spearce@spearce.org>
      16419dad
  8. May 24, 2010
  9. May 20, 2010
    • Christian Halstrick's avatar
      Added merge support to CommitCommand · 6ca9843f
      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: default avatarChristian Halstrick <christian.halstrick@sap.com>
      6ca9843f
  10. May 19, 2010
    • Saša Živkov's avatar
      Test root locale translations · 3c667b32
      Saša Živkov authored
      Ensures all translations exist in the root locale.
      
      Change-Id: Ic8a8bdfd4a06c6d1ebd1e85a8082a32c82d155c7
      3c667b32
    • Saša Živkov's avatar
      Externalize strings from JGit · f3d8a8ec
      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: default avatarSasa Zivkov <sasa.zivkov@sap.com>
      f3d8a8ec
    • Shawn Pearce's avatar
      Fix SSH deadlock during OutOfMemoryError · 2e961989
      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: default avatarDmitry Neverov <dmitry.neverov@gmail.com>
      Signed-off-by: default avatarShawn O. Pearce <spearce@spearce.org>
      2e961989
    • Dmitry Neverov's avatar
      Fix race condition in StreamCopyThread · b3247ba5
      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: default avatarShawn O. Pearce <spearce@spearce.org>
      b3247ba5
  11. May 17, 2010
  12. May 16, 2010
    • Shawn Pearce's avatar
      Reduce the size of PackWriter's ObjectToPack instances · b6d0586b
      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: default avatarShawn O. Pearce <spearce@spearce.org>
      b6d0586b
    • Shawn Pearce's avatar
      Reduce size of PackedObjectLoader by dropping long to int · cb5bc195
      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: default avatarShawn O. Pearce <spearce@spearce.org>
      cb5bc195
  13. May 15, 2010
    • Shawn Pearce's avatar
      Factor out duplicate Inflater setup in WindowCursor · 9c4d42e9
      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: default avatarShawn O. Pearce <spearce@spearce.org>
      9c4d42e9
    • Shawn Pearce's avatar
      Squash OffsetCache into WindowCache · d8f20745
      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: default avatarShawn O. Pearce <spearce@spearce.org>
      d8f20745
    • Shawn Pearce's avatar
      Avoid unnecessary second read on OBJ_OFS_DELTA headers · 3cb59216
      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: default avatarShawn O. Pearce <spearce@spearce.org>
      3cb59216
  14. May 13, 2010
  15. May 12, 2010
  16. May 11, 2010
  17. May 10, 2010
    • Christian Halstrick's avatar
      Add builder-style API to jgit and Commit & Log cmd · f3fb5824
      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: default avatarChristian Halstrick <christian.halstrick@sap.com>
      f3fb5824
  18. May 08, 2010
    • Robin Rosenberg's avatar
      541ad72a
    • Robin Rosenberg's avatar
    • Robin Rosenberg's avatar
      A stages field and getter for GitIndex entry introduced · a496410d
      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: default avatarRobin Rosenberg <robin.rosenberg@dewire.com>
      a496410d
    • Christian Halstrick's avatar
      Added MERGING_RESOLVED repository state · b9ab040b
      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: default avatarChristian Halstrick <christian.halstrick@sap.com>
      Signed-off-by: default avatarMatthias Sohn <matthias.sohn@sap.com>
      b9ab040b
    • Robin Rosenberg's avatar
      Merge "Lock down maven plugin versions" · 0f2d50b6
      Robin Rosenberg authored
      0f2d50b6
Loading