Re: Trying to sync two svn repositories with git-svn (repost)

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 13, 2009, 17:28 UTC
Message-ID: <32541b130905131028i5c4b1a31j7f760f8157507df6@mail.gmail.com>
In-Reply-To: <20090513120922.GP15420@raven.wolf.lan>

On Wed, May 13, 2009 at 8:09 AM, Josef Wolf <jw@raven.inka.de> wrote:

> Now here's the problem:  This last dcommit does simply a reset, because
> nothing has changed since the last dcommit.  So a5cf3..c3ff2 are _not_
> marked as ancestors of svn-2/trunk, causing those cherries to be rebased
> at the next dcommit with real changes.

I find this a *bit* curious, since each dcommit should be adding the cherry-picked changes you just now picked from the opposite branch, right? If you weren't going to change anything, then you wouldn't have needed to do the cherry picks at all; you could have just done a merge -s ours in both directions in the first place.

Anyway, regardless of the above, AFAIK there's no way to force svn to make an empty commit, which is a problem in this case. You can make a nonempty commit, though; I've done this in the past by just adding a newline to the end of some arbitrary file. Basically:

git merge -s ours whatever echo >>Makefile git add Makefile git commit --amend git svn dcommit

Silly, but it works.

> Unfortunately, dcommit doesn't seem to have an option to force rebase
> instead of resetting.

Well, in fact it *is* rebasing, which throws away the extra commit because it thinks that commit didn't do anything. I've experienced this problem a few times in the past, but I knew what was happening and I figured my case was too rare to matter. Perhaps not.

This could be considered a bug in git-svn, so I cc:'d Eric Wong, who I think is the main git-svn developer. Anyway, try the workaround above.

Good luck,

Avery