On Thu, May 14, 2009 at 5:41 PM, Josef Wolf <jw@xxxxxxxxxxxxx> wrote: > On Thu, May 14, 2009 at 02:35:18AM -0400, Avery Pennarun wrote: >> No criss-cross merges, no insanity, no question about whether it's correct. > > Indeed, this looks pretty simple. But AFAICS, this works only when > starting out with a virgin repository. In my situation, public is > currently empty and have to be constructed from scratch by picking > from the privates. Not exactly; you simply produce a "public" repository however you want to produce it. One easy way would be to copy one of the existing svn branches, cherry pick and revert whatever commits you want, and call it public. The prior history of that branch doesn't matter to the algorithm. > 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. So if you think this will fix it, you're probably missing something :) > 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.) > At first glance, this seems to work. But there's the drawback that I > have to keep track of what have been merged manually. So there's > certainly room for improvement :) Right, the crossmerge() function in the script I sent is designed to avoid that. > I will have to play a little bit with this script to get a better > understanding how it works. But from the description, I got the > impression that it matches my (current) work flow pretty good: > Currently, initial changes are done in some private repository and > propagated to the other repositories from there. The only exception > is that currently, there's no such thing as a "public" repository. The public repository is nothing special and doesn't require any work from you; it's simply maintained automatically from the private branches. (Of course, if you start doing all your changes in the public repository, life gets a little simpler.) 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