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

On Thu, May 14, 2009 at 5:41 PM, Josef Wolf [off-list ref] wrote:

On Thu, May 14, 2009 at 02:35:18AM -0400, Avery Pennarun wrote:

quoted

No criss-cross merges, no insanity, no question about whether it's correct.

Indeed, this looks pretty simple.  But AFAICS, this works only when
starting out with a virgin repository.  In my situation, public is
currently empty and have to be constructed from scratch by picking
from the privates.

Not exactly; you simply produce a "public" repository however you want
to produce it.  One easy way would be to copy one of the existing svn
branches, cherry pick and revert whatever commits you want, and call
it public.  The prior history of that branch doesn't matter to the
algorithm.

So here's my second plan:
1. instead of doing the cherry-picking in a single repository, it might
  be helpful to do it in separate repositories: one repository for each
  direction.  While there are still two remote svn repositories in each
  svn repository, there is no need for criss-cross anymore.  The flow
  of the data is in one direction and it seems (at least at first glance)
  I can use git-svn-rebase to get a linear history.

it's still criss-crossing, it's just less obvious that way.  One
repository is exactly the same as two repositories in git; all that
matters is the branch histories.  So if you think this will fix it,
you're probably missing something :)

2. After the synchronization is done, I would merge the two repositories
  into a third one to create the public repository.  Since this will be
  a pure git environment, I hope that the problems that are caused svn's
  lack of merge support will vanish.

I'd say that basically none of your problems have anything to do with
svn's lack of merge support, and everything to do with the fact that
you aren't doing all your changes first on a 'public' branch and then
merging from there into the private branches.  (That's really not so
hard to do in svn either, and would save a ton of confusion.)

At first glance, this seems to work.  But there's the drawback that I
have to keep track of what have been merged manually.  So there's
certainly room for improvement :)

Right, the crossmerge() function in the script I sent is designed to avoid that.

I will have to play a little bit with this script to get a better
understanding how it works.  But from the description, I got the
impression that it matches my (current) work flow pretty good:
Currently, initial changes are done in some private repository and
propagated to the other repositories from there.  The only exception
is that currently, there's no such thing as a "public" repository.

The public repository is nothing special and doesn't require any work
from you; it's simply maintained automatically from the private
branches.  (Of course, if you start doing all your changes in the
public repository, life gets a little simpler.)

Have fun,

Avery