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. 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). Oh, and make sure you're using a recent git; older git-svn didn't have the incremental index rebuild. Peter Harris -- 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
