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

[Ramkumar Ramachandra <artagnon@gmail.com>]

Hi Jonathan,

Jonathan Nieder writes:
> 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?

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