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 <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...)
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--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
