Hmm, I tried "svnmerge.py avail" from the branch after committing to the trunk. I see now that I should have committed to the branch first (which seems an inversion to me). Duly noted for the future, though.
Still working on seamless git-svn and svnmerge.py integration, Andrew John Hunter wrote: > On Fri, Jan 16, 2009 at 12:38 PM, Andrew Straw <straw...@astraw.com> wrote: >> John Hunter wrote: >>> Andrew, since you are the original author of the isnan port, could you >>> patch the branch and the trunk to take care of this? >> Done in r6791 and r6792. >> >> Sorry for the trouble. >> >> Now I just hope we don't get a problem with "long long", although now if >> _ISOC99_SOURCE is defined, we'll preferentially use "int64_t" out of >> <stdint.h>, so I should think this is more portable on sane platforms. >> >> This one of many reasons why I stick to Python... > > Thanks Andrew for applying this, and Georg, I forgot to mention in my > last post thanks especially for tracking down this nasty bug. Andrew, > for future reference, when fixing a bug on the branch, it is best to > svnmerge it onto the rather than committing it separately since > subsequent merges will bring it over an confuse the commit log. > Instructions at > > http://matplotlib.sourceforge.net/devel/coding_guide.html#using-svnmerge > > Thanks again! > JDH > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
