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

From: Josef Wolf <jw@raven.inka.de>
Date: May 13, 2009, 22:22 UTC
Message-ID: <20090513222243.GQ15420@raven.wolf.lan>
In-Reply-To: <32541b130905131028i5c4b1a31j7f760f8157507df6@mail.gmail.com>

Thanks for your patience, Avery! I would be completely lost here without your help..

On Wed, May 13, 2009 at 01:28:04PM -0400, Avery Pennarun wrote:

Show 9 quoted lines

> 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?

They _are_ already added. I try to outline what happens based on the graph I posted in my previous mail:

  # move cherries from svn-1 to svn-2
  #
  git svn fetch svn-1
  git checkout svn-2
  [ cherry-picking, creates 67446..0a742 ]
  git merge --no-ff -s ours svn-1 -m 'merge ours svn-1 to svn-2' # 5d9a0
  git checkout svn-2/trunk
  git merge --no-ff svn-2 -m 'merge svn-1 to svn-2'              # f80d2
  git svn dcommit

This sequence moves cherries 67446..0a742 to svn-2/trunk and creates 5d9a0+f80d2 67446..0a742 are now ancestors of svn-2/trunk a5cf3..c3ff2 are _not_ ancestors of svn-2/trunk (they don't even exist yet)

  # move cherries from svn-1 to svn-2
  #
  git svn fetch svn-2
  git checkout svn-1
  [ cherry-picking, creates a5cf3..c3ff2 ]
  git merge --no-ff -s ours svn-2 -m 'merge ours svn-2 to svn-1' # 2379d
  git checkout -q svn-1/trunk
  git merge --no-ff svn-1 -m 'merge svn-2 to svn-1'              # 693fa
  git svn dcommit --no-rebase

This sequence moves cherries a5cf3..c3ff2 to svn-1/trunk and creates 2379d+693fa a5cf3..c3ff2 are now ancestors of svn-1/trunk 67446..0a742 are also ancestors of svn-1/trunk since 5d9a0 pulls them in.

Please notice the asymmetry here. If I try to merge another change to svn-2 at this point, dcommit tries to pull the cherries a5cf3..c3ff2. Since those cherries came initially from 17156..e0772, they are already included literally in the current tree and I get a lot of conflicts, To tell git about the fact that those cherries are already available in svn-2/trunk, I try yet another merge set of commands:

  git checkout svn-2
  git merge --no-ff -s ours svn-1

This works fine, a5cf3..c3ff2 are now recorded as ancestors of svn-2 and will no longer be picked on future merges.

  git checkout svn-2/trunk
  git merge --no-ff -s ours svn-1
  git svn dcommit

And _this_ is the dcommit I was talking about in the paragraph you cited above. This dcommit notices that the resulting tree is identical to the tree already in svn, since it was merged with "-s ours" and no real change was done in the mean time. So dcommit just resets and a5cf3..c3ff2 are still not marked as ancestors of svn-2/trunk and would be pulled again at the next merge attempt, resulting in conflicts.

> 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.

The cherries _are_ moved in both directions. But the ancestry is not yet adopted because at the time of the move from svn-1 to svn-2 the cherries that were picked from svn-2 did not exist. Therefore dcommit wants to move them to svn-2 (where the textual contents of those cherries already are).

Show 10 quoted lines

> 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

Ah, I see :-)  You can do a _lot_ with git if you know _how_ to do it ;-)

Yes, that helps a little bit: all the cherries are now ancestors of both remote branches and both local branches. But after this, all dcommits complain about outdated transactions although there were no commits to the svn repositories in the meantime:

  $ git merge --no-ff -s ours svn-1
  Merge made by ours.               
  $ echo >>Makefile
  $ git add Makefile
  $ git commit --amend -m 'Force merge ours svn-1 to svn-2/trunk'
  Created commit ae455ca: Force merge ours svn-1 to svn-2/trunk
  $ git svn dcommit
  Committing to file:///var/tmp/builds/git-sync/svn/svn-2/trunk ...
          M       Makefile                                               
  Committed r1260                                                          
          M       Makefile                                               
  r1260 = 372579ff221a151f026eef42213e52e1b9bb9d47 (svn-2/trunk)   
  No changes between current HEAD and refs/remotes/svn-2/trunk     
  Resetting to the latest refs/remotes/svn-2/trunk                 
  $ git checkout svn-2
  Previous HEAD position was 372579f... Force merge ours svn-1 to svn-2/trunk
  Switched to branch "svn-2"                                                    
  $ git svn fetch svn-1
  $ git merge --no-ff svn-1
  Already up-to-date.       
  $ git svn dcommit
  Committing to file:///var/tmp/builds/git-sync/svn/svn-2/trunk ...
  Transaction is out of date: File '/trunk/policy.pl' is out of date at /usr/lib64/git/git-svn line 469

Gitk shows that svn-2 is no longer an ancestor of svn-2/trunk. Might this be the reason for the "transaction out of date"? How do I recover from that?

Show 11 quoted lines

> > 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.

I am not sure this is a bug. I have still the feeling that I am doing something wrong. Maybe I should not try to throw two svn remotes onto a single git repository? Maybe I should create a separate repository for every direction?