1. 07 Oct, 2012 4 commits
  2. 17 Aug, 2012 3 commits
  3. 16 Aug, 2012 1 commit
  4. 15 Aug, 2012 5 commits
  5. 10 Aug, 2012 2 commits
    • Peter Baumann's avatar
      git svn: reset invalidates the memoized mergeinfo caches · 61b472ed
      Peter Baumann authored
      Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
      git-svn has maintained some private per-repository caches in
      .git/svn/.caches to avoid refetching and recalculating some
      mergeinfo-related information with every 'git svn fetch'.
      
      This memoization can cause problems, e.g consider the following case:
      
      SVN repo:
      
        ... - a - b - c - m  <- trunk
                \        /
                  d  -  e    <- branch1
      
      The Git import of the above repo is at commit 'a' and doesn't know about
      the branch1. In case of an 'git svn rebase', only the trunk of the
      SVN repo is imported. During the creation of the git commit 'm', git svn
      uses the svn:mergeinfo property and tries to find the corresponding git
      commit 'e' to create 'm' with 'c' and 'e' as parents. But git svn rebase
      only imports the current branch so commit 'e' is not imported.
      Therefore git svn fails to create commit 'm' as a merge commit, because one
      of its parents is not known to git. The imported history looks like this:
      
        ... - a - b - c - m  <- trunk
      
      A later 'git svn fetch' to import all branches can't rewrite the commit 'm'
      to add 'e' as a parent and to make it a real git merge commit, because it
      was already imported.
      
      That's why the imported history misses the merge and looks like this:
      
        ... - a - b - c - m  <- trunk
                \
                  d  -  e    <- branch1
      
      Right now the only known workaround for importing 'm' as a merge is to
      force reimporting 'm' again from SVN, e.g. via
      
        $ git svn reset --revision $(git find-rev $c)
        $ git svn fetch
      
      Sadly, this is where the behavior has regressed: git svn reset doesn't
      invalidate the old mergeinfo cache, which is no longer valid for the
      reimport, which leads to 'm' beeing imprted with only 'c' as parent.
      
      As solution to this problem, this commit invalidates the mergeinfo cache
      to force correct recalculation of the parents.
      
      During development of this patch, several ways for invalidating the cache
      where considered. One of them is to use Memoize::flush_cache, which will
      call the CLEAR method on the underlying Memoize persistency implementation.
      Sadly, neither Memoize::Storable nor the newer Memoize::YAML module
      introduced in 68f532f4 could optionally be used implement the
      CLEAR method, so this is not an option.
      
      Reseting the internal hash used to store the memoized values has the same
      problem, because it calls the non-existing CLEAR method of the
      underlying persistency layer, too.
      
      Considering this and taking into account the different implementations
      of the memoization modules, where Memoize::Storable is not in our control,
      implementing the missing CLEAR method is not an option, at least not if
      Memoize::Storable is still used.
      
      Therefore the easiest solution to clear the cache is to delete the files
      on disk in 'git svn reset'. Normally, deleting the files behind the back
      of the memoization module would be problematic, because the in-memory
      representation would still exist and contain wrong data. Fortunately, the
      memoization is active in memory only for a small portion of the code.
      Invalidating the cache by deleting the files on disk if it isn't active
      should be safe.
      Signed-off-by: default avatarPeter Baumann <waste.manager@gmx.de>
      Signed-off-by: Steven Walter's avatarSteven Walter <stevenrwalter@gmail.com>
      Signed-off-by: default avatarEric Wong <normalperson@yhbt.net>
      61b472ed
    • Robert Luberda's avatar
      git svn: handle errors and concurrent commits in dcommit · e48fb750
      Robert Luberda authored
      dcommit didn't handle errors returned by SVN and coped very
      poorly with concurrent commits that appear in SVN repository
      while dcommit was running. In both cases it left git repository
      in inconsistent state: index (which was reset with `git reset
      --mixed' after a successful commit to SVN) no longer matched the
      checkouted tree, when the following commit failed or needed to be
      rebased. See http://bugs.debian.org/676904 for examples.
      
      This patch fixes the issues by:
      - introducing error handler for dcommit. The handler will try
        to rebase or reset working tree before returning error to the
        end user. dcommit_rebase function was extracted out of cmd_dcommit
        to ensure consistency between cmd_dcommit and the error handler.
      - calling `git reset --mixed' only once after all patches are
        successfully committed to SVN. This ensures index is not touched
        for most of the time of dcommit run.
      Signed-off-by: default avatarEric Wong <normalperson@yhbt.net>
      e48fb750
  6. 09 Aug, 2012 2 commits
  7. 08 Aug, 2012 2 commits
  8. 07 Aug, 2012 6 commits
  9. 06 Aug, 2012 15 commits