Re: Converting to Git using svn-fe (Was: Speeding up the initial git-svn fetch)

Ramkumar Ramachandra wrote:

Also, since we're aiming for a two-way mapping, it's going to be
significantly more challenging: we will need a mapping function that
can be inverted perfectly.

Sounds interesting!  Let's see how much I can narrow scope/dash hopes.
:)

First of dreams is the possibility of using git as a replacement for
svnsync, to get semantically identical SVN repositories like so:

[...]

SVN repository 1 -> dumpfile -> Git repository
Git repository -> dumpfile' -> SVN repository 2

in a way that svn tools can look at repo 2 as a basically perfect
replacement for repo 1.  This means copying svnsync properties,
rename tracking info, svn properties, etc.

I. Some people might want that, and I wouldn't want to stop them
   trying (maybe using notes, perhaps even the mythical tree-based
   form) but I'm not interested in it at all.  Is it a goal for you?

Second would be the possibility of using an SVN repository as a
conduit for communication between git repositories:

Git repository 1 -> fast-export stream -> SVN repository
SVN repository -> dumpfile -> Git repository 2

II. It would be super cool to be able to transport arbitrary git
    objects via svn (maybe using custom properties and fabricated
    temporary branches named after the first commit after a fork
    point).  Perhaps some people could host git projects on Google
    Code this way.  Is that a goal?

Git 1 -> SVN 1 -> Git 2 -> SVN 2 -> Git 3

III. Perhaps only the subset of git objects with certain properties
     should be considered safe to transport via an SVN repository
     (e.g.:

      - author matches committer
      - timestamps are New York time
      - author address is of the format username <username>
      - filenames are valid UTF-8

     ).  And maybe any existing git repository can be painlessly
     transformed to consist only of such commits.  Is that a model
     to strive for?

SVN 1 -> Git 1 -> SVN 2 -> Git 2 -> SVN 3

IV. Maybe only some svn changes would be considered safe to
    transport via git: no weird properties, no tracked renames
    not involved in branches/merges, all branches named after the
    git commit id of the first rev after the fork point, ...
    And maybe any existing svn repository can be painlessly
    transformed to consist only of such revisions.  Is that a goal?

(As you might have guessed, my answers are "no, no, no, and no, at
least at first, but it is fun to imagine how a person would go about
achieving these things anyway").

Hope that clarifies something,
Jonathan