From: Warren Harris Date: Wed, 29 Oct 2008 03:40:21 GMT Subject: Re: git export to svn 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: >> >> 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 > > 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 >> .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...) > > > > 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