On Wed, Feb 25, 2009 at 08:02:45PM -0500, Peter Harris wrote: > On Wed, Feb 25, 2009 at 6:24 PM, Josef Wolf wrote: > > And IMHO, there's one catch: to synchronize, I need to tightly > > coordinate the work on git-svn-repos with the work on its clones. The > > clones are not reachable most of the time, so tightly coordinating > > would slow down the flow of changesets extremely. > > Not sure if it helps, but for what it's worth, I use a circular setup: > git-svn-repos is updated from subversion-repos (by cron), but is > otherwise read-only. cloneN can pull from git-svn-repos (since > git-pull is a whole lot faster than git svn fetch, especially for the > initial clone), but has to "git svn dcommit" to push changes back > upstream. > > This configuration puts any potential rebase conflicts back into the > hands of cloneN. Thanks for the suggestion, Peter! I guess this would really solve the problem. > No need to coordinate clones, aside from each clone > needing to know how to work in a "commits will be rebased by upstream" > type of environment (which isn't unique to git-svn). Hmm, what does that exactly mean? Chances are that the reason for my problem is that _I_ am the one who don't know that... > Oh, and make sure > you're using a recent git; older git-svn didn't have the incremental > index rebuild. jw@raven:/home/jw> git --version git version 1.6.0.2 jw@raven:/home/jw> Is that OK? -- 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
