[SciPy-dev] The future of SciPy and its development infrastructure

[Pauli Virtanen]

Mon, 23 Feb 2009 15:11:06 -0600, Robert Kern wrote:

> On Mon, Feb 23, 2009 at 15:06, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> 
>> I think git-svn takes care of most of the branching problem on a local
>> basis. Where it fall down, IMHO, is in testing a branch on the
>> builtbots and sharing a branch among two or three people.
> 
> Why is that? Push your git branch to github.

git-svn relies much on rebasing (for merging with SVN), and AFAIK doesn't 
work well in a multi-user scenario. Quote from the manual page:

	The recommended method of exchanging code between git branches
	and users is git-format-patch and git-am, or just dcommiting to
	the SVN repository.

That is, the recommended way to collaborate when using git-svn is to send 
patches via mail. Also, if you want to merge, there are caveats:

	Running git-merge or git-pull is NOT recommended on a branch you
	plan to dcommit from. Subversion does not represent merges in any
	reasonable or useful fashion; so users using Subversion cannot see
	any merges you've made. Furthermore, if you merge or pull from a
	git branch that is a mirror of an SVN branch, dcommit may commit
	to the wrong branch.

So I don't think it's very simple to use it for sharing work with people. 
Working on an SVN branch is IMO better than this.

    ***

I'm wondering if we would benefit from an official, pull-only, 
automatically updating, Git mirror of the SVN repository:

- Easy "feature branches" also for those who don't have SVN commit rights.

- Rebasing against SVN is not necessary, merges will just work.

- Easier to work with than dealing with patches.

Some issues turn up when changes are committed back to SVN:

- There's some minor manual work before dcommit works, if you clone
  a git-svn repository from somewhere else:

  http://subtlegradient.com/articles/2008/04/22/cloning-a-git-svn-clone

  But this needs to be done only once.

- cherry-pick + rebase is likely necessary before changes can be
  committed to SVN.

- Merge is necessary on the feature branch, if further work needs to be
  done on it.

The last point is probably the biggest factor undermining usability of 
this workflow. But this still probably would beat updating patches, and 
it does not seem to be any worse than SVN branches.

-- 
Pauli Virtanen