On Wed, 7 May 2008, Steven Grimm wrote:

quoted text
> 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.

-- Asheesh.

-- 
What happened last night can happen again.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html