From: Josef Wolf Date: Fri, 15 May 2009 17:52:03 GMT Subject: Re: Trying to sync two svn repositories with git-svn (repost) Message-ID: <20090515175203.GS15420@raven.wolf.lan> In-Reply-To: <32541b130905141457u196e1a68w8250489b88eb83c4@mail.gmail.com> 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. 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)