Re: git export to svn

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2008.10.25 13:29:50 -0700, Warren Harris wrote:
> I tried a fetch, but still no luck:
>
> $ 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
> r58084 = c01dadf89b552077da132273485e7569d8694518 (trunk)
> 	A	...
> r58088 = 7916f3a02ad6c759985bd9fb886423c373a72125 (trunk)
>
> $ git svn rebase
> Unable to determine upstream SVN information from working tree history

Means that your current branch is not based on what git-svn has fetched,
which is expected when you use "svn init" + "svn fetch" after you
already started working.

What's the actual relationship between your local history and the
history you fetched from svn?

If your local stuff started from revision X, which you manually imported
from svn, you can just rebase it:

git rebase --onto <svn-revision-X> <your-revision-X>


If you have a bunch of merges in your local history, you might want to
merge your stuff into the svn-based branch instead. When you dcommit,
the svn repo will only see one big "do it all" commit though.

For that, you would create a graft, so that your first "real" local
commit gets the svn revision X commit as its parent. That is, from:

S---S---SX---S---S---S (svn)

LX--------L---L---L---L (local)

You want to go to:

S---S---SX---S---S---S (svn)
         \
LX        L---L---L---L (local)


Where 'S' means that the commit came from SVN, and L means that it is a
"local" commit. SX and LX are the commits that have the same tree
attached (same directories/files), but have a different hash due to how
they were created. The graft overrides the parent-child relation for the
first "L" commit, so that it actually appears as being branched off of SX.

And then, you'd merge local into svn, so you get:

S---S---SX---S---S---S--M (svn)
         \             /
LX        L---L---L---L (local)



If possible, go with the rebase though. That at least gives a somewhat
reasonable history in the svn repo as well. Also note that when you go
with the merge way, make sure that the svn branch is totally uptodate
before you merge and that the merge commit is the only one to be
dcommitted. Otherwise, funny stuff might happen, and rebase might kick
in anyway, I don't exactly remember what git-svn does, but it wasn't
pleasant :-)

Björn