On Fri, May 15, 2009 at 1:52 PM, Josef Wolf <jw@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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? 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." >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html