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

Will Palmer [off-list ref] writes:

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

quoted

Stephen Bash writes:

...

quoted

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 think there might be a problem in that in git commit is defined by
its parents and its final state, while revision in Subversion is IIRC
defined by change.  Isn't it?

-- 
Jakub Narebski
Poland
ShadeHawk on #git