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