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

On Fri, May 15, 2009 at 03:05:14PM -0400, Avery Pennarun wrote:

On Fri, May 15, 2009 at 1:52 PM, Josef Wolf [off-list ref] wrote:

quoted

On Thu, May 14, 2009 at 05:57:00PM -0400, Avery Pennarun wrote:

quoted

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

quoted

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.

Yeah, I see...  But this step is here _only_ to get the existing svn
repositories in sync again.  After cherry-picking and dcommitting, those
cherry-pick repositories would be wiped.  They have no real history.  The
steps I outlined in my previous mail wouldn't even create any files in
the .git/refs subdirectory.

Hmm, getting them in sync the first time seems to be "easy"
(relatively), in that you've already done it, right?

No.  I have a perl script to do the cherry-picking and to resolve
conflicts.  Because of this, I can try out different methods to do the
sync.  And of course, I'd like to do it in a way that produces the least
problems in the future, since this is a one-shot thing.

quoted

quoted

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

The problem here is that it does not match the work flow.  IMHO, my work
flow is very similar to the work flow of the kernel, so I fail to see why
it can not work.  See the analogies:

kernel: Submodule maintainers are committing into private repositories
me:     People are committing into private repositories

kernel: Those commits are forwarded to Linus's repository
me:     Those commits are forwarded to the public repository

kernel: Maintainers receive commits for other submodules from linus
me:     Commits are distributed from public to private repositories

There is one critical difference here: if someone merges from Linus
and then Linus merges back from them, then the two resulting
repositories will be *identical* (at least, the trees will be; if the
second merge uses --no-ff, the histories will be very slightly
different, but not importantly so).

If someone has patches that they don't want to send back to Linus, and
those patches are intermixed with ones they *do* want to send back,
then they either have to cherry pick them over to a separate branch
(which Linus can then pull), or equivalently they email individual
patches to Linus, or they need to rebase a lot, or they need to just
put their "finished" patches onto a separate branch and keep the
unfinished ones somewhere else that Linus won't pull.

Does any description exist how this process works in detail?

Rebasing is (I think) actually the most common solution to this
problem, but it doesn't help if you're using svn.  svn has no concept
of rebasing.  (git svn rebase uses git rebase, but it's not really for
the same purpose.)

In the long term, I am willing to get rid of svn.  But I have to create
a migration path, so I need to keep git+svn in parallel for a couple of
months.