Migrating a git repository to subversion

Migrating a git repository to subversion

[Alf Mikula]

I'm a relatively new (2 weeks) user of Git, and so far I really love
it, and I want to educate my co-workers about it.

Having said that, I want to demonstrate git's git<--->svn
capabilities, and currently everybody here has and understands
Subversion.  So, I want to initialize a Subversion repository with my
git history from my local git repository.  Here's what I tried:

1. Create a new, empty subversion project with trunk/tags/branches subdirs.
2. git svn clone http://myhost.com/path/to/project --stdlayout
3. git pull ../git_project
4. git svn dcommit


This put all my files into Subversion, but under a single commit.  Is
there a step I'm missing that would allow git to commit all my
individual git commits to the Subversion repository?  I've done a
bunch of searches, but all the docs seem to focus on cloning an
existing svn repository, as opposed to exporting git repositories to
Subversion.

Thanks in advance,

-Alf

Re: Migrating a git repository to subversion

[Avery Pennarun]

On 5/15/08, Alf Mikula <amikula@gmail.com> wrote:
>  1. Create a new, empty subversion project with trunk/tags/branches subdirs.
>  2. git svn clone http://myhost.com/path/to/project --stdlayout
>  3. git pull ../git_project
>  4. git svn dcommit
>
>  This put all my files into Subversion, but under a single commit. [...]

Step 3 created a "merge commit", which connected the (presumably, but
not necessarily, empty) repository from step 2 to the other one in
step 3.  git-svn doesn't know how to break apart a merge into its
parts (mostly because it's theoretically impossible to do in the
general case :)) so it just makes a single svn commit.

The way people usually deal with this when using git-svn is they use
"git rebase" to simplify their history and eliminate the need for
merge commits.  This makes git-svn much happier, but unfortunately
makes future git merging a bit more complicated.

Anyway, to answer your question: add a new step 3.5 that's something like:

  git rebase WHATEVER

Where WHATEVER is the name of the last commit git-svn created in step 2.

Have fun,

Avery

Re: Migrating a git repository to subversion

[Björn Steinbrink]

On 2008.05.15 19:19:13 -0400, Avery Pennarun wrote:
> On 5/15/08, Alf Mikula <amikula@gmail.com> wrote:
> >  1. Create a new, empty subversion project with trunk/tags/branches subdirs.
> >  2. git svn clone http://myhost.com/path/to/project --stdlayout
> >  3. git pull ../git_project
> >  4. git svn dcommit
> >
> >  This put all my files into Subversion, but under a single commit. [...]
> 
> Step 3 created a "merge commit", which connected the (presumably, but
> not necessarily, empty) repository from step 2 to the other one in
> step 3.  git-svn doesn't know how to break apart a merge into its
> parts (mostly because it's theoretically impossible to do in the
> general case :)) so it just makes a single svn commit.
> 
> The way people usually deal with this when using git-svn is they use
> "git rebase" to simplify their history and eliminate the need for
> merge commits.  This makes git-svn much happier, but unfortunately
> makes future git merging a bit more complicated.
> 
> Anyway, to answer your question: add a new step 3.5 that's something like:
> 
>   git rebase WHATEVER
> 
> Where WHATEVER is the name of the last commit git-svn created in step 2.

In this case, "git svn rebase" handles figuring out what WHATEVER should
be. That said, I'd suggest something different/bigger to show off git's
power. Creating a linear history is not really impressive, especially
when you go on and compare the svn and git repos afterwards.

I'd create a svn repo with trunk, tags, branches like you have done,
import that via git-svn. Then add a few commits to trunk, dcommit them.
Then create a branch in _svn_ [1]. Use "git svn fetch" to get that into
your git repo, do some commits on that branch, dcommit them, do some
commits on trunk, dcommit them. Then checkout trunk, merge the other
branch, and dcommit the result. Then repeat that, so you got two merges
on trunk.

If you then look at your history in gitk (for example), you'll see the
merges just fine, while the svn history has no clue about it, except for
the commit message. If you do that "live", you can also show off the
history after the first merge, and show that the second merge needs no
crappy -r123:154 option to figure out what exactly needs to be merged
like svn does, because git actually records merges.

The results on the svn side of things are the same as if you had done
the merges there, and being able to compare that quite directly to how
git does it is nice.

Björn

[1] Here's a small script that creates a branch in the svn repo (using
the svn executable) from the most recent svn commit that is in your
current git branch (yeah, it's rather ugly):

#!/bin/sh
if test "$1" = ''
then
	echo "Usage: git-svn-branch <branch_name>"
	exit 127
fi

CURRENT=$(git rev-list --first-parent --pretty=format:%b HEAD | grep -m1 -o 'git-svn-id: [^ ]*' | sed -e 's/git-svn-id: //')

SRC=${CURRENT%@*}
REV=${CURRENT#*@}
URL=$(git config --get svn-remote.svn.url)

URL=$(echo -n "$URL" | sed -e 's!//.*@!//!')
DST="$URL/$(git config --get svn-remote.svn.branches | grep -o '^[^:]*' | sed -e "s/\*/$1/")"

svn cp -r "$REV" "$SRC" "$DST" -m "Create branch $1"

Re: Migrating a git repository to subversion

[Linus Torvalds]

On Thu, 15 May 2008, Alf Mikula wrote:
> 
> Having said that, I want to demonstrate git's git<--->svn
> capabilities, and currently everybody here has and understands
> Subversion.  So, I want to initialize a Subversion repository with my
> git history from my local git repository.  Here's what I tried:

Hmm. I don't think there is any git2svn thing, but if your history is 
linear (which is really the only thing SVN can handle, since SVN doesn't 
really do "merges" in the git sense at all), you could just write some 
silly script to extract the patches one by one and commit them using SVN.

Or use "tailor", which should be able to convert from pretty much anything 
into pretty much anything (again, assuming it's linear).

Or, and this gets extra points for being disgusting, use "git-cvsserver" 
to serve a remote CVS repo, then cvssuck to create a local CVS repo out of 
it, and then do cvs2svn to create a SVN repo. Ta-daa!

(Ok, that last one really is too ugly to live, but if it works, it really 
sounds like the true rube-goldberg way to do it, and should be done just 
because it is there, to paraphrase George Mallory).

			Linus

Re: Migrating a git repository to subversion

[Martin Langhoff]

On Fri, May 16, 2008 at 3:01 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, 15 May 2008, Alf Mikula wrote:
>> Having said that, I want to demonstrate git's git<--->svn
>> capabilities, and currently everybody here has and understands
>> Subversion.  So, I want to initialize a Subversion repository with my
>> git history from my local git repository.  Here's what I tried:
>
> Hmm. I don't think there is any git2svn thing, but if your history is
> linear (which is really the only thing SVN can handle, since SVN doesn't
> really do "merges" in the git sense at all), you could just write some
> silly script to extract the patches one by one and commit them using SVN.

The git svn rebase trick described earlier does almost exactly what Alf wants.

> Or, and this gets extra points for being disgusting, use "git-cvsserver"
> to serve a remote CVS repo, then cvssuck to create a local CVS repo out of
> it, and then do cvs2svn to create a SVN repo. Ta-daa!

Ugh. Evil man.



m
-- 
 martin.langhoff@gmail.com
 martin@laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff

Re: Migrating a git repository to subversion

[Alf Mikula]

> The git svn rebase trick described earlier does almost exactly what Alf wants.

You're absolutely right.  With the rebase, I have my history (which so
far is linear) in the SVN repository, and I can continue using git
locally and pushing my commits back to Subversion.  I also want to try
Björn's suggestions about merging SVN branches.  While Subversion
fixed the most annoying problems in CVS, I think it got a lot of
branching, merging, and tagging wrong.  Maybe using git to handle
merging will make a nice band-aid.

Anyway, thanks to all for the suggestions!

-Alf

Re: Migrating a git repository to subversion

[Imran M Yousuf]

On Fri, May 16, 2008 at 5:08 AM, Alf Mikula <amikula@gmail.com> wrote:
> I'm a relatively new (2 weeks) user of Git, and so far I really love
>  it, and I want to educate my co-workers about it.
>
>  Having said that, I want to demonstrate git's git<--->svn
>  capabilities, and currently everybody here has and understands
>  Subversion.  So, I want to initialize a Subversion repository with my
>  git history from my local git repository.  Here's what I tried:
>
>  1. Create a new, empty subversion project with trunk/tags/branches subdirs.
>  2. git svn clone http://myhost.com/path/to/project --stdlayout

I would just create another local branch and merge the tracking branch
into it, then rebase the branch with the master branch and then do the
svn dcommit. If the 'git svn clone' 'd repo is bare I think it should
commit the individual commits.

Best regards,

Imran

>  3. git pull ../git_project
>  4. git svn dcommit
>
>
>  This put all my files into Subversion, but under a single commit.  Is
>  there a step I'm missing that would allow git to commit all my
>  individual git commits to the Subversion repository?  I've done a
>  bunch of searches, but all the docs seem to focus on cloning an
>  existing svn repository, as opposed to exporting git repositories to
>  Subversion.
>
>  Thanks in advance,
>
>  -Alf
>  --
>  To unsubscribe from this list: send the line "unsubscribe git" in
>  the body of a message to majordomo@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557