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

Hi Jonathan,

Jonathan Nieder writes:

Ramkumar Ramachandra wrote:

quoted

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:

[...]

quoted

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?

Hm. I didn't imagine that it would be *that* difficult. The challenge
is to design an invertible mapping function by encapsulating
incompatibilities (or inconsistencies) bit-by-bit using hacks like
notes for the additional information. I'll think about this a little
more and get back to it in a few days.

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

Interesting, but I don't necessarily see why this is useful.

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

Wow. That IS super-cool, but I'd have to stretch my imagination quite
a bit to find a usecase for this. I actually find this inelegant (and
probably even grotesque) on many levels, so no- absolutely not
interested in this.

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

Dunno, and I don't like this.

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?

Again, no usecase. I'm not looking for making SVN do Git wizardry-
there's always Git for that. SVN is a simple book-keeping system, and
I want to keep it that way.

(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").

Let me guess: you're targeting git-svn like functionality with all the
dcommit/ rebase ugliness? I'm looking for a slightly nicer way, not
too much more; (I) is just a sort of "ideal" target- it's just nice to
think about it that way. It's needn't be entirely realistic.

-- Ram