Andrew Straw wrote:
For the past month or two, I've been experimenting with using git to
interact with the MPL subversion repository. The bottom line is that I I
haven't been able to create any kind of one-to-one mapping between git
branches and svnmerge.py branches. As we're using svnmerge.py on top of
subversion to manage the trunk and release branches, I see this as a
pretty fatal flaw.
I basically agree with Andrew, but I want to elaborate on this point for those who haven't been trying this stuff out for themselves.
I documented how to use svn maintenance branches from git, and this is in the matplotlib source, but doesn't seem to have pushed out to the sourceforge site. This might be due to the automatic doc updating being turned off recently -- I haven't followed that thread closely. Because of this, I don't know if Andrew's comments aren't taking that into account... he could have reached the same conclusion either way... 
It is possible to work on maintenance branches from git, but I haven't figured out a way to do the merging without svnmerge.py. I've worked this way for a while, and yes it's kludgy, but not too bad. I just keep a SVN checkout of the trunk around specifically for running svnmerge.py. So there is a one-to-one mapping between svn branches and git branches, it's just not a bidirectional one-to-one mapping, and unfortunately any advantages to git's merging tools are useless in that situation. But, honestly, I haven't really missed them.
So, while I can use git to interact with the trunk (and create and use
my own feature branches locally using git), and while using git is very
nice for browsing history or bisecting the revision in which a bug
cropped up, I think I've reached a point where I don't think interaction
with svnmerge.py's branches is going to work without investing more time
than I'm willing to give into understanding (and possibly improving)
git-svn.
My own gut feeling is that while a pure DVCS environment might be nice someday, the compromises of git-svn makes the whole thing sort of +0 for me. I can't say that I've felt much more productive using it over raw svn/svnmerge.py with matplotlib. So I, too, am giving it a pass for now, but for slightly different reasons.
So, therefore, I'd say the issue of using a distributed version control
system for MPL has not reached any real conclusion. Thus, we may want to
visit this issue at some point. Perhaps once Python and/or numpy have
made decisions. The Python-dev team seems to be working this out right
now: PEP 374 – Choosing a distributed VCS for the Python project | peps.python.org
I like the approach the PEP (Brett Cannon) is taking. I think it makes a lot of sense to let those dedicated and smart core Python folks do some trailblazing for us
Mike
···
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA