Re: Trying to sync two svn repositories with git-svn (repost)
- From
- Josef Wolf <jw@raven.inka.de>
- Date
- May 15, 2009, 17:52 UTC
- 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:
Show 12 quoted lines
> On Thu, May 14, 2009 at 5:41 PM, Josef Wolf <jw@raven.inka.de> 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.
Show 10 quoted lines
> > 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)