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

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

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.

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.

quoted

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

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

I can't believe all changes spring into life in linus's repository.

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)