Re: git export to svn

From: Warren Harris <warrensomebody@gmail.com>
Date: Oct 29, 2008, 03:40 UTC
Message-ID: <9CE5F946-B783-4D0F-993B-C0187E2E2DAF@gmail.com>
In-Reply-To: <20081026171519.GD3612@atjola.homenet>

Björn - Thanks again for your help...

On Oct 26, 2008, at 10:15 AM, Björn Steinbrink wrote:

Show 8 quoted lines

>>
>> Since I'm trying to export my git repo to svn, the svn repo is
>> completely empty.
>
> OK, the "r58084" made me think that your code is based on something  
> that
> is already in the SVN repo. But apperently, that's just a shared svn
> repo, right?

Right

Show 42 quoted lines

>
> This should do and uses a graft to simplify the process a bit:
>
> Initialize git-svn:
> git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2
>
> The --prefix gives you remote tracking branches like "svn/trunk" which
> is nice because you don't get ambiguous names if you call your local
> branch just "trunk" then. And -s is a shortcut for the standard
> trunk/tags/branches layout.
>
>
> Fetch the initial stuff from svn:
> git svn fetch
>
> Now look up the hash of your root commit (should show a single  
> commit):
> git rev-list --parents master | grep '^.\{40\}$'
>
> Then get the hash of the empty trunk commit:
> git rev-parse svn/trunk
>
> Create the graft:
> echo <root-commit-hash> <svn-trunk-commit-hash> >> .git/info/grafts
>
> Now, "gitk" should show svn/trunk as the first commit on which your
> master branch is based.
>
> Make the graft permanent:
> git filter-branch -- ^svn/trunk --all
>
> Drop the graft:
> rm .git/info/grafts
>
> gitk should still show svn/trunk in the ancestry of master
>
> Linearize your history on top of trunk:
> git svn rebase
>
> And now "git svn dcommit -n" should tell you that it is going to  
> commit
> to trunk.

This worked. The only downside was that all of our svn users subscribed to the checkins mailing list got a flood of messages from me, but otherwise it worked like a charm. (I see that the original git commit dates were not preserved in svn, but that doesn't matter too much...)

Show 20 quoted lines

>
>
>
> Alternatively, if rebase gives just too many conflicts, you can do:
>
> git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2
> git svn fetch
> git checkout -b trunk svn/trunk
> git merge master
> git svn dcommit
>
> That will just create a single huge commit in svn. But the history  
> will
> be retained in git. You can then work on the new "trunk" branch or  
> move
> your master branch, so it points to the same commit as trunk and then
> drop the "trunk" branch or whatever. It just matters that your new  
> work
> is based upon the dcommited merge commit, so "svn/trunk" is in your
> branch's history.

This didn't work for me. (I had tried the first procedure on a test tree, then this one on a different test tree, and ultimately went back to the first procedure for my real git repo.) I ended up with an empty svn tree. For the record, here's what happened:

$ git svn fetch
W: Ignoring error from SVN, path probably does not exist: (175002): RA  
layer request failed: REPORT of '/svn/!svn/bc/100': Could not read  
chunk size: Secure connection truncated (https://svn)
W: Do not be alarmed at the above message git-svn is just searching  
aggressively for old history.
This may take a while on large repositories
r58382 = 9b9d5f01e4a3aca714eb5f61a9f05ab657cc7bc5 (svn/trunk)
Checked out HEAD:
   https://svn/svn/test3/trunk r58382

$ git checkout -b trunk svn/trunk Switched to a new branch "trunk"

$ git merge master Already up-to-date.

$ git svn dcommit Committing to https://svn/svn/test3/trunk ...

$ cd tmp/svn-test3/

$ svn co https://svn/svn/test3/trunk Checked out revision 58385.

$ ls -al trunk/ total 88 drwxr-xr-x 11 warren staff 374 Oct 28 18:15 . drwxr-xr-x 3 warren staff 102 Oct 28 18:15 .. drwxr-xr-x 9 warren staff 306 Oct 28 18:15 .svn

Now one thing that might be different than what you prescribed is that our svn repo uses different conventions for branches and tags, so I didn't use 'git svn init -s', although I doubt that matters.

Anyway, I'm up and running in svn with your first procedure, so my problem is solved. Thanks.

Warren