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

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

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?  So it's a
one-time thing, doesn't need automation, and you already figured that
part out.  So it seems like a non-issue one way or the other.

Once that is done, I can declare one of the existing repositories as
public and pull it via git-svn into a freshly created repos.  The other
repos can then be recreated by cloning and applying patches.  No svn
involved anymore here.

Yes, that works fine.  Nothing stopping you from declaring one or the
other svn repos to be identical to "public."

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.

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

The only differences I can see are:
- size of the project (obviously)
- convert from multiple svn repos instead of bitkeeper
- private repostories have to keep local patches (but I guess maintainers
 do that also)

That last one is the source of all your problems.  That said, the
script I provided *does* let you do this, if you're brave.

Have fun,

Avery