matplotlib-devel Mailing List for matplotlib

On Jan 7, 2008 2:37 PM, Eric Firing <ef...@ha...> wrote:
> (At the moment I can't compile the branch--I just sent Mike a message
> about that off the list, with voluminous output.)
>
> It seems like what is needed is not exactly a merge operation but simply
> a renaming of the trunk and the branch. Maybe some doc files need to be
> merged, but that is about it. Correct?
Sorry if I used sloppy terminology, all I mean is that Michael's stuff
will become the HEAD of the svn trunk, and the current HEAD of the
trunk will become a branch. No merge will be necessary since Michael
has been merging all changes in the HEAD into his branch on a ongoing
basis. I don't actually know how one does this move in svn, but I
have faith that Michael does.
> All this brings to mind the discussion taking place over the last week
> on the numpy list regarding switching from svn to bzr or hg.
> http://thread.gmane.org/gmane.comp.python.numeric.general/18130
> (I have been using hg locally for a couple years, and I like it.) The
> motivation is the greater ease of branching and merging with distributed
> VCS systems in comparison to SVN. In the numpy list discussion, it
> sounds like all participants except Travis favor making the switch.
I'm personally -1 on this. I prefer to keep things as simple as
possible and do not see the need for a lot of branching, though there
is clearly a need for some. svn is the standard version control
system and has the best install base (now on OS X and all linux
systems), making it easiest for users to get checkouts. If numpy,
ipython and scipy all decide to move, I would probably be inclined to
go along with it for consistency between these packages, but I
wouldn't be leading the charge. I have never felt the need for a
distributed version control system, personally, though some swear by
it. It is probably because mpl has always just had a trunk with no
branches, and I'd like to stick to that as much as possible,
Michael, how onerous was it for you to do the merges using svn -- this
seems to be the most significant problem with svn in my reading of
David's summary.
JDH

John et al.,
(At the moment I can't compile the branch--I just sent Mike a message 
about that off the list, with voluminous output.)
It seems like what is needed is not exactly a merge operation but simply 
a renaming of the trunk and the branch. Maybe some doc files need to be 
merged, but that is about it. Correct?
In any case, I will be happy to see the move take place, and I think we 
already agreed that this is a good time to do it.
All this brings to mind the discussion taking place over the last week 
on the numpy list regarding switching from svn to bzr or hg.
http://thread.gmane.org/gmane.comp.python.numeric.general/18130
 (I have been using hg locally for a couple years, and I like it.) The 
motivation is the greater ease of branching and merging with distributed 
VCS systems in comparison to SVN. In the numpy list discussion, it 
sounds like all participants except Travis favor making the switch.
For us to make such a change would require switching the repo host from 
sourceforge to something else--I suspect Enthought would be happy to 
host us.
Apart from the initial effort and spinup required--and I don't mean to 
dismiss that as trivial--I think that using a suitable DVCS would 
facilitate progress with mpl. If so, is it crazy to do it as part of a 
major branch/trunk switch, or does that perhaps make it easier?
Comments?
Eric
John Hunter wrote:
> Now that the 0.91.2 release is out, I am inclined to merge Michael's
> transforms branch into the trunk. Since many people rely on svn, we
> probably need to advertise this move broadly, with a news item on the
> web page and announcements on the mailing lists, with instructions on
> how to checkout the 0.91 maintenance branch (which does not exist but
> would be created as the maintenance branch). There was some
> suggestion earlier that we leave Michael's work on a branch, but I
> think we need to get it on the trunk so developers and svn users will
> get it by default which will help us move more rapidly in shaking out
> the remaining bugs and problems.
> 
> Michael, since you know more about this than anyone, you should
> probably spearhead the svn reorganization and let people know when the
> changes become effective with some advance notice. I will update the
> website with pointers to the relevant docs (your API_CHANGES and
> Changelog and the relevant svn commands and anything else you think we
> will need).
> 
> If this seems like a reasonable plan, perhaps we should shoot for
> doing this in a day or two. If any of you think this is the wrong
> approach, let us know.
> 
> JDH
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Now that the 0.91.2 release is out, I am inclined to merge Michael's
transforms branch into the trunk. Since many people rely on svn, we
probably need to advertise this move broadly, with a news item on the
web page and announcements on the mailing lists, with instructions on
how to checkout the 0.91 maintenance branch (which does not exist but
would be created as the maintenance branch). There was some
suggestion earlier that we leave Michael's work on a branch, but I
think we need to get it on the trunk so developers and svn users will
get it by default which will help us move more rapidly in shaking out
the remaining bugs and problems.
Michael, since you know more about this than anyone, you should
probably spearhead the svn reorganization and let people know when the
changes become effective with some advance notice. I will update the
website with pointers to the relevant docs (your API_CHANGES and
Changelog and the relevant svn commands and anything else you think we
will need).
If this seems like a reasonable plan, perhaps we should shoot for
doing this in a day or two. If any of you think this is the wrong
approach, let us know.
JDH

We have uploaded source and binary releases of matplotlib-0.91.2 to
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=566411.
Thanks to Charlie Moad for doing the release.
This is a bugfix release and includes several important fixes listed
below.
2008年01月06日 Released 0.91.2 at revision 4802
2007年12月26日 Reduce too-late use of matplotlib.use() to a warning
 instead of an exception, for backwards compatibility - EF
2007年12月25日 Fix bug in errorbar, identified by Noriko Minakawa - EF
2007年12月25日 Changed masked array importing to work with the upcoming
 numpy 1.05 (now the maskedarray branch) as well as with
 earlier versions. - EF
2007年12月16日 rec2csv saves doubles without losing precision. Also, it
 does not close filehandles passed in open. - JDH,ADS
2007年12月13日 Moved rec2gtk to matplotlib.toolkits.gtktools and rec2excel
 to matplotlib.toolkits.exceltools - JDH
2007年12月12日 Support alpha-blended text in the Agg and Svg backends -
 MGD
2007年12月10日 Fix SVG text rendering bug. - MGD
2007年12月10日 Increase accuracy of circle and ellipse drawing by using an
 8-piece bezier approximation, rather than a 4-piece one.
 Fix PDF, SVG and Cairo backends so they can draw paths
 (meaning ellipses as well). - MGD
2007年12月07日 Issue a warning when drawing an image on a non-linear axis. - MGD
2007年12月06日 let widgets.Cursor initialize to the lower x and y bounds
 rather than 0,0, which can cause havoc for dates and other
 transforms - DSD
2007年12月06日 updated references to mpl data directories for py2exe - DSD
2007年12月06日 fixed a bug in rcsetup, see bug 1845057 - DSD
2007年12月05日 Fix how fonts are cached to avoid loading the same one
multiple times.
 (This was a regression since 0.90 caused by the refactoring of
 font_manager.py) - MGD
2007年12月05日 Support arbitrary rotation of usetex text in Agg backend. - MGD
2007年12月04日 Support '|' as a character in mathtext - MGD