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

On Wed, May 06, 2009 at 03:23:40PM -0400, Avery Pennarun wrote:

On Wed, May 6, 2009 at 2:52 PM, Josef Wolf [off-list ref] wrote:

quoted

Here's what I have at this point:

            ------------------S1TRUNK
           /                 /
  --hs1--O1--c2...c2-------S1
           \              /
            `+++++++.    /
                     \  /
  --hs2--O2--c1...c1--S2
           \            \
            -------------S2TRUNK

  hs1, hs2:         history imported from svn-1 and svn2, respectively
  O1, O2:           the svn-1-orig and svn-2-orig tags
  c1, c2:           cherries picked from hs1 and hs2, respectively
  S1, S2:           svn-1 and svn-2, the local tracking branches
  S1TRUNK, S2TRUNK: the remotes/svn-X/trunk branches

I would have expected a symmetrical diagram.  But it turns out that the
connection marked with plusses is still at O1 instead of S1.  So it takes
no wonder that the c2 cherries get re-applied to the s2 branch on the
next merge.

That's a well-drawn diagram, but unfortunately I'm still confused.
What is the "connection marked with plusses" and does it have a name?

Well, the whole history (including this connection) was created by the
commands I posted.  The only exception are hs1 and hs2, which were
imported from the svn repositories (but they are linear).

AFAICS, this connection was created by the very first merge after the
cherry-picking from hs1 (the cherries marked as c1..c1).  After importing
the svn repositories, I've done this:

  git checkout svn-2                # S2 in the diagram above, but used
                                    #    to be identical to O2 at that time
  [ cherry-picking c1...c1 ]        # S2 now moved to its place in diagram
  git merge --no-ff -s ours svn-1   # S1 in the diagram above, but used
                                    #    to be identical to O1 at the
                                    #    time of that merge, This merge
                                    #    creates the mystical
                                    #    "connection marked with plusses"

Then we've done the "detached head" merge, that created the S2TRUNK

  git checkout svn-2/trunk    # S2TRUNK was at O2 at that time
  git merge --no-ff svn-2
  git svn dcommit             # moves S2TRUNK to the place in the diagram

Now take care of the other direction:

  git checkout svn-1                # S1 in the diagram above, but still
                                    #    identical to O1 at that time
  [ cherry-picking c2...c2 ]        # S1 now moved to its place in diagram
  git merge --no-ff -s ours svn-2   # S2 in the diagram above.  Unlike S1,
                                    #    S2 already _is_ at the place where
                                    #    it is drawn in the diagram.  So
                                    #    this merge creates the connection
                                    #    S2->S1

Now we do the "detached head" merge, that creates the S1TRUNK

  git checkout svn-1/trunk    # S1TRUNK was at O1 at that time
  git merge --no-ff svn-1
  git svn dcommit             # moves S1TRUNK to the place in the diagram

So the "connection marked with plusses" is basically the counterpart of
the "S2->S1" connection.  But while "S2->S1" got its proper position at
the time it was created, the plus-connection was created before the c2
cherries.  And it was never adjusted.  AFAICS, those two connections
should be symmetrical: "S1->S2" and "S2->S1".

It *looks* to me like both S1TRUNK and S2TRUNK should be okay, but
it's hard to tell what has actually happened here.

Yes, the trunks (and the svn repositories) look pretty good at _that_
point in time.  But the next merge on S2TRUNK moves all the modifications
done by the c2 cherries down to S2TRUNK.

If you could post a screenshot of 'gitk --all' it might help.

IMHO, Screenshots are not of much help here.  That's why I posted

  http://www.spinics.net/lists/git/msg102609.html

The svn histories are about 1250 commits each.  The cherry-pickings are
about 350 commits each.  This gives histories running in parallel for
long distances.  Add to this gitk's tendency to change lanes at every
occasion:  There's no chance to get multiple screen shots (the interesting
branch/merge-points, as I described in the thread referenced above) in
sync.  There's many opportunities to get confused.  At least for me, as a
newbie to git.