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: http://www.python.org/dev/peps/pep-0374/ > 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 ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
