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

On Tue, 2010-10-19 at 12:12 +0530, Ramkumar Ramachandra wrote:

Hi Stephen,

Stephen Bash writes:

...

quoted

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.