From: Josef Wolf Date: Sun, 17 May 2009 11:24:49 GMT Subject: Re: Trying to sync two svn repositories with git-svn (repost) Message-ID: <20090517112449.GT15420@raven.wolf.lan> In-Reply-To: <32541b130905151205h6ca89d85q97e72ce23bf233ee@mail.gmail.com> On Fri, May 15, 2009 at 03:05:14PM -0400, Avery Pennarun wrote: > On Fri, May 15, 2009 at 1:52 PM, Josef Wolf 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 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.