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

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

On Fri, May 15, 2009 at 03:05:14PM -0400, Avery Pennarun wrote:
> On Fri, May 15, 2009 at 1:52 PM, Josef Wolf <jw@raven.inka.de> wrote:
> > 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.
> 
> 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.

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