Re: Git -> SVN importing

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Feb 3, 2009, 17:29 UTC
Message-ID: <alpine.LNX.1.00.0902031213540.19665@iabervon.org>
In-Reply-To: <c115fd3c0902030717u6a8f3bbck3027cf74715c79a4@mail.gmail.com>

On Tue, 3 Feb 2009, Tim Visher wrote:

Show 15 quoted lines

> Hello Everyone,
> 
> In light of company decisions that are yet to be known, we may in the
> future be stuck using svn.  My team and I really want to experiment
> with Git, but one of the concerns that my supervisor brought up was
> that in the future we want to be sure that we can relatively
> painlessly bring the history into svn if required.  Obviously, it's
> expected that we would loose the local branching history, but we would
> want at least the published information to be sucked back into svn
> without change, if that's possible.
> 
> I figured that someone would have to have done this before since
> git-svn is so magical.  However, I thought I'd ask.
> 
> What's the story?

What other people have done in similar situations is use git on their workstations as an extra-nice svn client, keeping the official history svn-compatible (and actually stored in svn) until relevant management is convinced that git is the way to go. I don't think anybody's written code to import a general git history as well as possible into svn.

The fundamental issue is that svn doesn't have any way to represent that a branch's history includes two sets of commits which were done in parallel, and it's impossible to automatically distribute merge conflict resolutions over the series that led to the merge, which means that you can't really produce a reasonable representation of the intermediate steps on the second branch.

That is, you'd not only lose the local branching history, but some of the middle commits in the resulting linear history would be bogus, with content which is not like what the author actually did.

	-Daniel
*This .sig left intentionally blank*