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

[Will Palmer <wmpalmer@gmail.com>]

On Tue, 2010-10-19 at 12:12 +0530, Ramkumar Ramachandra wrote:
> Hi Stephen,
> 
> Stephen Bash writes:
...
> > 
> > I have 32 SVN revs in my history that touch multiple Git commit
> > objects.  The simplest example is
> >   svn mv svn://svnrepo/branches/badBranchName svn://svnrepo/branches/goodBranchName
> > which creates a single SVN commit that touches two branches
> > (badBranchName will have all it's contents deleted, goodBranchName
> > will have an "empty commit" as described above).  The more devious
> > version is the SVN rev where a developer checked out / (yes, I'm not
> > kidding) and proceeded to modify a single file on all branches in
> > one commit.  In our case, that one SVN rev touches 23 git commit
> > objects.  And while the latter is somewhat a corner case, the former
> > is common and probably needs to be dealt with appropriately (it's
> > kind of a stupid operation in Git-land, so maybe it can just be
> > squashed).
> 
> Ouch! Thanks for the illustrative example- I understand now. We have
> to bend backwards to perform a one-to-one mapping. It's finally struck
> me- one-to-one mapping is nearly impossible to achieve, and I don't
> know if it makes sense to strive for it anymore. Looks like Jonathan
> got it earlier.

It's been a while since I was involved in this discussion, so maybe the
design has changed by now, but I was under the impression that there
would be one "one-to-one" mapping branch (which would never be checked
out), containing the history of /, and that the "real" git branches,
tags, etc, would be based on the trees originally referenced by the root
checkout, with git-notes (or similar) being used to track the weirdness
in mappings. How does the "multiple branches touched in a single commit"
complicate anything other than the heuristics for automatic branch
detection (which I assume nobody is at the stage of talking about yet).

I suppose we wouldn't be talking, technically, about a one-to-one
mapping in that case, as we would be turning "one" svn revision into
"many" git branches, but in the conceptual sense of "one svn repository
equals one git repository", I don't see this as being impossible, or so
difficult that it shouldn't be striven-for.

Something else which is at least semi-common in svn is to treat a folder
both as a "directory" and a "branch", which the "checking out /" example
would just be an extreme example of. Think in terms of git branches
being a "view" of the history, with some mapper sitting between each
view and "root" checkout.