On Wed, May 07, 2008 at 11:48:17PM -0700, Asheesh Laroia wrote: > On Wed, 7 May 2008, Steven Grimm wrote: > >> In environments where a lot of people are sharing an svn repository using >> git-svn, everyone has identical, but individually maintained, tracking >> branches. > > To further muddy the waters, let me talk about my setup, also one with a > "central git repository" from which all developers clone, and also one > based on a Subversion tree. > > The way I handle it is that, hidden somewhere, I have an account with a > cron job that does this: > > $ git svn fetch > $ git push origin refs/remotes/*:refs/heads/* > $ git push origin refs/remotes/trunk:refs/heads/master > > The first push synchronizes "origin" to have the same branches as this > git-svn copy of the git repository, and the second updates "origin" so that > it has a "master"; without that second step, "git clone" will error out > when it get to its checkout phase. > > Note that in .git/config, the [remote "origin"] section has no "fetch" > parameter. If it did have one, a would end up creating the branch > origin/master on the second push, and origin/origin/master on the third, > and so on. > > After the push, "origin" ends up being a git repository that looks just > like the svn repository we're cloning. When you "git clone" it, the remote > has all the tags and branches of the upstream svn repository; and as the > upstream svn repository updates its branches, the git branches get those > updates. > > I'm not saying this patch shouldn't be accepted; I have no comment on it. I > just want to see what others think of my approach to this workflow. This workflow doesn't seem to provide a way for the developers who clone the "origin" above, to dcommit to svn. Presumably, with the right initialization, Steve's patch would allow all those clones to dcommit to svn directly. I like your automated mirror setup, but IMO, it becomes a lot more useful in conjunction with Steve's patch. -chris -- 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
