1. 12 2月, 2008 1 次提交
  2. 07 2月, 2008 1 次提交
  3. 04 2月, 2008 2 次提交
  4. 22 1月, 2008 1 次提交
  5. 13 1月, 2008 1 次提交
    • E
      git-svn: handle leading/trailing whitespace from svnsync revprops · 98fa5b68
      Eric Wong 提交于
      Repositories generated by svnsync cannot be relied on to have
      properly set revprops without newlines in UUIDs and URLs.  There
      may be broken versions of svnsync out there that append extra
      newlines to UUIDs, or the revprops could've been changed by
      repository administrators at any time, too.
      
      At least one repository we've come across has an embedded
      newline erroneously set in the svnsync-uuid prop.  This is bad
      because the trailing newline is taken as another record by the
      Git.pm library, and the wantarray detection causes tmp_config()
      to return an array with an empty-but-existing second element.
      
      We will now strip leading and trailing whitespace both before
      setting and after reading the uuid and url for svnsync values.
      We will also force tmp_config to return a single scalar when
      reading existing values.
      
      SVN UUIDs should never have whitespace in them, and SVN
      repository URLs should be URI-escaped, so neither of those
      values we ever see in git-svn should actually have whitespace
      in them.
      
      Thanks to Dennis Schridde for the bug report and Junio for
      helping diagnose this.
      Signed-off-by: NEric Wong <normalperson@yhbt.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      98fa5b68
  6. 10 1月, 2008 1 次提交
  7. 08 1月, 2008 2 次提交
  8. 03 1月, 2008 2 次提交
  9. 19 12月, 2007 3 次提交
    • E
      git-svn: avoid warning when run without arguments · 540424b2
      Eric Wong 提交于
      While we're in the area, finish writing a halfway-written
      comment describing what that block does...
      Signed-off-by: NEric Wong <normalperson@yhbt.net>
      540424b2
    • E
      git-svn: workaround a for broken symlinks in SVN · 7fc35e0e
      Eric Wong 提交于
      It's possible for bad clients to commit symlinks without the
      5-character "link " prefix in symlinks.  So guard around this
      bug in SVN and make a best effort to create symlinks if the
      "link " prefix is missing.
      
      More information on this SVN bug is described here:
        http://subversion.tigris.org/issues/show_bug.cgi?id=2692
      
      To be pedantic, there is still a corner case that neither we nor
      SVN can handle:  If somebody made a link using a broken SVN
      client where "link " is the first part of its path, e.g.
      "link sausage", then we'd end up having a symlink which points
      to "sausage" because we incorrectly stripped the "link ".
      Hopefully this hasn't happened in practice, but if it has,
      it's not our fault SVN is broken :)
      
      Thanks to Benoit Sigoure and Sverre Johansen for reporting
      and feedback.
      Signed-off-by: NEric Wong <normalperson@yhbt.net>
      7fc35e0e
    • E
      git-svn: avoid leaving leftover committer/author info in rebase · ad94802a
      Eric Wong 提交于
      We set the 6 environment variables for controlling
      committer/author email/name/time for every commit.
      
      We do this in the parent process to be passed to
      git-commit-tree, because open3() doesn't afford us the control
      of doing it only in the child process.  This means we leave them
      hanging around in the main process until the next revision comes
      around and all 6 environment variables are overwridden again.
      
      Unfortunately, for the last commit, leaving them hanging around
      means the git-rebase invocation will pick it up, rewriting the
      rebased commit with incorrect author information.  This should fix
      it.
      Signed-off-by: NEric Wong <normalperson@yhbt.net>
      ad94802a
  10. 15 12月, 2007 1 次提交
    • E
      git-svn: handle our top-level path being deleted and later re-added · 12a6d752
      Eric Wong 提交于
      Previously, git-svn would ignore cases where the path we're
      tracking is removed from the repository.  This was to prevent
      heads with follow-parent from ending up with a tree full of
      empty revisions (and thus breaking rename detection).
      
      The previous behavior is fine until the path we're tracking
      is re-added later on, leading to the old files being merged
      in with the new files in the directory (because the old
      files were never marked as deleted)
      
      We will now only remove all the old files locally that were
      deleted remotely iff we detect the directory we're in is being
      created from scratch.
      
      Thanks for Marcus D. Hanwell for the bug report and
      Peter Baumann for the analysis.
      Signed-off-by: NEric Wong <normalperson@yhbt.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      12a6d752
  11. 14 12月, 2007 2 次提交
  12. 11 12月, 2007 3 次提交
    • J
      git-svn: get color config from --get-colorbool · cd459e3f
      Jeff King 提交于
      git-config recently learned a --get-colorbool option. By
      using it, we will get the same color=auto behavior that
      other git commands have.
      
      Specifically, this fixes the case where "color.diff = true"
      meant "always" in git-svn, but "auto" in other programs.
      Signed-off-by: NJeff King <peff@peff.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      cd459e3f
    • E
      git-svn: reinstate old rev_db optimization in new rev_map · 66ab84b9
      Eric Wong 提交于
      This reinstates an old optimization in .rev_db which
      stored the highest revision number we scanned, allowing
      us to avoid scanning the SVN log for those revisions
      again in a subsequent invocation.
      
      This means the last 24-byte record in a .rev_map file
      can be a 4-byte SVN revision number with 20-bytes of
      zeroes representing a non-existent commit.  This record
      can and will be overwritten when a new commit iff
      the commit is all zeroes.
      Signed-off-by: NEric Wong <normalperson@yhbt.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      66ab84b9
    • E
      git-svn: replace .rev_db with a more space-efficient .rev_map format · 060610c5
      Eric Wong 提交于
      Migrations are done automatically on an as-needed basis when new
      revisions are to be fetched.  Stale remote branches do not get
      migrated, yet.
      
      However, unless you set noMetadata or useSvkProps it's safe to
      just do:
      
        find $GIT_DIR/svn -name '.rev_db*' -print0 | xargs rm -f
      
      to purge all the old .rev_db files.
      
      The new format is a one-way migration and is NOT compatible with
      old versions of git-svn.
      
      This is the replacement for the rev_db format, which was too big
      and inefficient for large repositories with a lot of sparse history
      (mainly tags).
      
      The format is this:
      
        - 24 bytes for every record,
          * 4 bytes for the integer representing an SVN revision number
          * 20 bytes representing the sha1 of a git commit
      
        - No empty padding records like the old format
      
        - new records are written append-only since SVN revision numbers
          increase monotonically
      
        - lookups on SVN revision number are done via a binary search
      
        - Piping the file to xxd(1) -c24 is a good way of dumping it for
          viewing or editing, should the need ever arise.
      
      As with .rev_db, these files are disposable unless noMetadata or
      useSvmProps is set.
      Signed-off-by: NEric Wong <normalperson@yhbt.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      060610c5
  13. 01 12月, 2007 5 次提交
  14. 22 11月, 2007 4 次提交
  15. 18 11月, 2007 5 次提交
  16. 12 11月, 2007 2 次提交
  17. 06 11月, 2007 1 次提交
    • E
      git-svn: fix dcommit clobbering when committing a series of diffs · c74d9acf
      Eric Wong 提交于
      Our revision number sent to SVN is set to the last revision we
      committed if we've made any previous commits in a dcommit
      invocation.
      
      Although our SVN Editor code uses the delta of two (old) trees
      to generate information to send upstream, it'll still send
      complete resultant files upstream; even if the tree they're
      based against is out-of-date.
      
      The combination of sending a file that does not include the
      latest changes, but set with a revision number of a commit we
      just made will cause SVN to accept the resultant file even if it
      was generated against an old tree.
      
      More trouble was caused when fixing this because we were
      rebasing uncessarily at times.  We used git-diff-tree to check
      the imported SVN revision against our HEAD, not the last tree we
      committed to SVN.  The unnecessary rebasing caused merge commits
      upstream to SVN to fail.
      Signed-off-by: NEric Wong <normalperson@yhbt.net>
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      c74d9acf
  18. 04 11月, 2007 1 次提交
  19. 17 10月, 2007 2 次提交