Re[3]: [PATCH 4/5] git-svn: fix bottleneck in stash_placeholder_list()

Hi Eric. I'm out of spare time and I still unable to import my repo. The code of SVN.pm is too complex. Please help me. Here's the list of my issues:

* I think git-svn doesn't handle the case, when a tag is deleted.
  I expected it to rename the ref from "tags/tagname" to
  "tags/tagname@rev", but that doesn't happen.
  If a tag is replaced, there's no way to tell what was the previous
  state of that tag: git-svn just rewrites the ref.
  On the contrary, the temporary refs (with "@rev" suffix), used for
  re-import subdir tags are kept after successful reimport, although
  they have no usage.

* As I said already, I have 25k revisions and 200 tags created from
  subdirs in trunk. This increases the import time from 2h to 12h.
  I would bear it, if it had to be done once, but fetching a new
  revision may cause re-import of all 25k revisions too.
  You should implement some mechanism to find the parent branches of
  subdir tags. Maybe the unused refs I mentioned in the previous issue
  are good candidates for that, but I would name them somehow
  different to distinguish with deleted/replaced tags/branches.

* There are mistake commits in the svn history, similar to this:
    ------------------------------------------------------------------------
    r21255 | xxx_xxxxxx_xxxxxxxxx | 2012-03-02 18:46:30 +0300 (Fri, 02 Mar 2012) | 1 line
    Changed paths:
      A /tags/dmagentenabler-4.1.31/DMAgent (from /tags:20998)
    
    Delivery 4.1.31
    ------------------------------------------------------------------------
  git-svn tries to creates a tag, containing dirs with other tags.
  Technically, behaves correctly, but it hangs, because of the size of
  the commit.
  To solve it, I had to edit the svn dump file:

     Node-path: tags/dmagentenabler-4.1.31/DMAgent
     Node-kind: dir
     Node-action: add
    -Node-copyfrom-rev: 20998
    -Node-copyfrom-path: tags
    +Prop-content-length: 10
    +Content-length: 10
    +
    +PROPS-END
     
     
     Revision-number: 21256

  It creates an empty dir, instead of copying. Since the author
  noticed the mistake, he immediately deleted the dir in the next
  revision, so it works.