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

[Josef Wolf <jw@raven.inka.de>]

On Thu, May 14, 2009 at 05:57:00PM -0400, Avery Pennarun wrote:
> On Thu, May 14, 2009 at 5:41 PM, Josef Wolf <jw@raven.inka.de> wrote:
> > 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.

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