matplotlib-devel Mailing List for matplotlib

Hi,
>> >> What have been the proposed solutions to dealing with basemap's data?
>> >
>> > Separate repo?
I just fished up some previous discussions:
http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8275
http://comments.gmane.org/gmane.comp.python.matplotlib.devel/8461
Do I remember correctly that a plan was needed to keep track of the
relationship of matplotlib-proper, the sample data and basemap, when
they are not part of the same repository?
See y'all,
Matthew

On Jan 22, 2011 2:28 PM, "Eric Firing" <ef...@ha...> wrote:
>
> On 01/22/2011 07:06 AM, Darren Dale wrote:
> > On Sat, Jan 22, 2011 at 11:55 AM, Benjamin Root<ben...@ou...> wrote:
> >> On Sat, Jan 22, 2011 at 10:26 AM, Darren Dale<dsd...@gm...>
 wrote:
> >>>
> >>> On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
> >>> <fri...@gm...> wrote:
> >>>> Hi,
> >>>>
> >>>> I want to set up a git mirror for matplotlib, but I 1) have some
minor
> >>>> problems and 2) want to know what others think about this.
> >>>
> >>> Late last year, I did some work to convert the svn repository to git.
> >>> The code to d the conversion is available at
> >>> https://github.com/darrendale/mpl2git . The resulting git repo is
> >>> available at https://github.com/darrendale/matplotlib . I have not
> >>> pursued the project further because there did not seem to be enough
> >>> interest in migrating from svn/sourceforge to git/github to justify
> >>> investing more of my time in the project.
> >>>
> >>>> I'm a native git user and I don't know how to use svn properly.
> >>>
> >>> I read that as "uninterested in learning how to use svn", and such
> >>> sentiment is probably a fact of life as many (most?) open source
> >>> projects move to DVC. In my opinion, matplotlib is likely to draw more
> >>> contributors if it lowers barriers to entry and uses a DVCS that is
> >>> growing in popularity, like git/github.
> >>>
> >>> Darren
> >>>
> >>
> >> In discussions with Ryan May on the prospect of switching over to git,
it
> >> sounds like we have a "Bike Shed" problem where we (the main
developers)
> >> agree that we agree that a bike shed should be built, but we can't
agree on
> >> the color to paint it...
> >
> > In my view, the issue has nothing to do with bikeshedding.
>
> Agreed. We *did* agree to move to git, and the only problem was that
> most of us lack the expertise and time to be of much help in actually
> getting it done. I think there was a bit of a hangup over the question
> of migrating the bug tracking; but I suspect we could agree that this is
> a secondary question, and that any such migration, if desired, can be
> done at leisure *after* taking the primary step of switching the code
repo.
>
> >
> >> I think the main source of the huge download size is the data that is
coming
> >> from the basemap toolkit. I do not think that it would be a good thing
to
> >> have everyone and their mother needing to do a 'git clone' on their
computer
> >> and find they have to pull down 500+ MB of stuff to get matplotlib. It
is
> >> because of this that a straight-forward migration from svn to
matplotlib
> >> won't be possible.
> >
> > The git repo at https://github.com/darrendale/matplotlib does not
> > include anything from basemap.
>
> The key point being that you are converting matplotlib/trunk/matplotlib,
> not matplotlib/trunk; the latter is what includes py4science, toolkits
> (including basemap), sample_data, etc. I think this is the right
approach.
>
> This doesn't all have to be perfect; it just has to be good enough. I
> suspect your conversion is good enough. If you are reasonably
> confident, then I think that if you go ahead and set up a github repo as
> the new official source tree, along with posting whatever notices are
> needed for anyone accessing the svn tree, the active developers will say
> "thank you!", and it will be done.
Thanks Eric, that's encouraging. I am reasonably confident, but in the
spirit of code review/cya, I would feel better if another dev chimed in that
they were also reasonably confident without having to take my word for it.
> The other person who has been most interested in the nuts and bolts of
> the conversion is Andrew Straw. Although he is evidently very short of
> mpl time these days, you might want to try to contact him directly to
> see if he has thought of anything you might have overlooked.
>
> I would like to be included in the group with git write access, unless
> there is a clear decision to restrict this group to a very small core of
> gatekeepers.
>
> Eric
>
> >
> >> What have been the proposed solutions to dealing with basemap's data?
> >
> > Separate repo?
> >
>
>
------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a 49ドル USD value)!
> Finally, a world-class log management solution at an even better
price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Jan 22, 2011 3:38 PM, "Friedrich Romstedt" <fri...@gm...>
wrote:
>
> 2011年1月22日 Eric Firing <ef...@ha...>:
> > This doesn't all have to be perfect; it just has to be good enough. I
> > suspect your conversion is good enough. If you are reasonably
> > confident, then I think that if you go ahead and set up a github repo as
> > the new official source tree, along with posting whatever notices are
> > needed for anyone accessing the svn tree, the active developers will say
> > "thank you!", and it will be done.
> >
> > The other person who has been most interested in the nuts and bolts of
> > the conversion is Andrew Straw. Although he is evidently very short of
> > mpl time these days, you might want to try to contact him directly to
> > see if he has thought of anything you might have overlooked.
> >
> > I would like to be included in the group with git write access, unless
> > there is a clear decision to restrict this group to a very small core of
> > gatekeepers.
>
> To support Darren's conversion work, here are the links to some numpy
> discussions which might be, I think, of interest here:
>
> [Numpy-discussion] curious about how people would feel about moving to
github:
> http://thread.gmane.org/gmane.comp.python.numeric.general/38133
>
> [Numpy-discussion] Technicalities of the SVN -> GIT transition:
> http://thread.gmane.org/gmane.comp.python.numeric.general/38263
>
> [Numpy-discussion] First shot at svn->git conversion:
> http://thread.gmane.org/gmane.comp.python.numeric.general/39443
>
> [Numpy-discussion] update on the transition to git/github:
> http://thread.gmane.org/gmane.comp.python.numeric.general/39102
>
> [Numpy-discussion] Github migration?:
> http://thread.gmane.org/gmane.comp.python.numeric.general/40020
>
> [Numpy-discussion] Can we freeze the subversion repository and move to
> github this week?:
>
http://mail.scipy.org/pipermail/numpy-discussion/2010-September/thread.html#52744
> (this thread is apparently lost on gmane)
>
> [Numpy-discussion] Numpy SVN frozen; move to Git:
>
http://mail.scipy.org/pipermail/numpy-discussion/2010-September/thread.html#52811
> (lost on Gmane too)
>
> [Numpy-discussion] Commit rights on github:
> http://thread.gmane.org/gmane.comp.python.numeric.general/40812
>
> [Numpy-discussion] Development workflow:
> http://thread.gmane.org/gmane.comp.python.numeric.general/40816
>
> [Numpy-discussion] Another merge at github:
> http://thread.gmane.org/gmane.comp.python.numeric.general/40967
>
> [Numpy-discussion] whitespace in git repo:
> http://thread.gmane.org/gmane.comp.python.numeric.general/41013
>
> Okay, I think that's it.
>
> I remember there were some problems getting the complete svn history
> correctly transferred (it should be in above), but I cannot tell
> specifics; we would have to ask on the numpy list for this.
I used Pauli's work on numpy as a template to convert the mpl tell, and I am
fairly confident that the history was correctly transferred. svn2git seems
to have improved since numpy made the leap, and appears to have handled the
merge of the transforms branch correctly, which may have been a considerable
stress-test for the conversion routines.
That said, I would be more comfortable saying "lets do this" if I heard from
more of the debate that the drop looks ok.
> Also, there was lots of discussion how to design the commit rights
> (somewhere included above); since on github "pull requests" can be
> filed, getting changes in with a committer different from the author
> is simple. Cf. http://github.com/numpy/ (list of members of the
> github organization).
>
> It is possible to register "organization" accounts on GitHub, with
> several members.
>
> Friedrich
>
>
------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a 49ドル USD value)!
> Finally, a world-class log management solution at an even better
price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

2011年1月22日 Benjamin Root <ben...@ou...>:
> Finally got around to committing this. I committed it to the maintenance
> branch in r8933 and merged into the development branch in r8934.
Okay, I agree on this, but I will work on it again once the git
transition is complete, or similar.
Thanks,
Friedrich

2011年1月22日 Eric Firing <ef...@ha...>:
> This doesn't all have to be perfect; it just has to be good enough. I
> suspect your conversion is good enough. If you are reasonably
> confident, then I think that if you go ahead and set up a github repo as
> the new official source tree, along with posting whatever notices are
> needed for anyone accessing the svn tree, the active developers will say
> "thank you!", and it will be done.
>
> The other person who has been most interested in the nuts and bolts of
> the conversion is Andrew Straw. Although he is evidently very short of
> mpl time these days, you might want to try to contact him directly to
> see if he has thought of anything you might have overlooked.
>
> I would like to be included in the group with git write access, unless
> there is a clear decision to restrict this group to a very small core of
> gatekeepers.
To support Darren's conversion work, here are the links to some numpy
discussions which might be, I think, of interest here:
[Numpy-discussion] curious about how people would feel about moving to github:
http://thread.gmane.org/gmane.comp.python.numeric.general/38133
[Numpy-discussion] Technicalities of the SVN -> GIT transition:
http://thread.gmane.org/gmane.comp.python.numeric.general/38263
[Numpy-discussion] First shot at svn->git conversion:
http://thread.gmane.org/gmane.comp.python.numeric.general/39443
[Numpy-discussion] update on the transition to git/github:
http://thread.gmane.org/gmane.comp.python.numeric.general/39102
[Numpy-discussion] Github migration?:
http://thread.gmane.org/gmane.comp.python.numeric.general/40020
[Numpy-discussion] Can we freeze the subversion repository and move to
github this week?:
http://mail.scipy.org/pipermail/numpy-discussion/2010-September/thread.html#52744
(this thread is apparently lost on gmane)
[Numpy-discussion] Numpy SVN frozen; move to Git:
http://mail.scipy.org/pipermail/numpy-discussion/2010-September/thread.html#52811
(lost on Gmane too)
[Numpy-discussion] Commit rights on github:
http://thread.gmane.org/gmane.comp.python.numeric.general/40812
[Numpy-discussion] Development workflow:
http://thread.gmane.org/gmane.comp.python.numeric.general/40816
[Numpy-discussion] Another merge at github:
http://thread.gmane.org/gmane.comp.python.numeric.general/40967
[Numpy-discussion] whitespace in git repo:
http://thread.gmane.org/gmane.comp.python.numeric.general/41013
Okay, I think that's it.
I remember there were some problems getting the complete svn history
correctly transferred (it should be in above), but I cannot tell
specifics; we would have to ask on the numpy list for this.
Also, there was lots of discussion how to design the commit rights
(somewhere included above); since on github "pull requests" can be
filed, getting changes in with a committer different from the author
is simple. Cf. http://github.com/numpy/ (list of members of the
github organization).
It is possible to register "organization" accounts on GitHub, with
several members.
Friedrich

On 1/22/11 10:26 AM, Darren Dale wrote:
> On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
> <fri...@gm...> wrote:
>> Hi,
>>
>> I want to set up a git mirror for matplotlib, but I 1) have some minor
>> problems and 2) want to know what others think about this.
>
> Late last year, I did some work to convert the svn repository to git.
> The code to d the conversion is available at
> https://github.com/darrendale/mpl2git . The resulting git repo is
> available at https://github.com/darrendale/matplotlib . I have not
> pursued the project further because there did not seem to be enough
> interest in migrating from svn/sourceforge to git/github to justify
> investing more of my time in the project.
>
>> I'm a native git user and I don't know how to use svn properly.
>
> I read that as "uninterested in learning how to use svn", and such
> sentiment is probably a fact of life as many (most?) open source
> projects move to DVC. In my opinion, matplotlib is likely to draw more
> contributors if it lowers barriers to entry and uses a DVCS that is
> growing in popularity, like git/github.
+1. There have been several times I've wanted to fix something in the 
documentation, and would have via github if it had been available. As 
it was, I sent an email to the list and someone else did it for me. In 
my case, the fixes got in, but it took more time and effort for me and 
presumably also for the people making the fix (compared to just 
responding to a pull request, for example). I do remember debating 
whether it was worth the trouble to report the typo when I realized I 
had to send an email describing exactly where the typo was.
Thanks,
Jason

On 01/22/2011 07:06 AM, Darren Dale wrote:
> On Sat, Jan 22, 2011 at 11:55 AM, Benjamin Root<ben...@ou...> wrote:
>> On Sat, Jan 22, 2011 at 10:26 AM, Darren Dale<dsd...@gm...> wrote:
>>>
>>> On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
>>> <fri...@gm...> wrote:
>>>> Hi,
>>>>
>>>> I want to set up a git mirror for matplotlib, but I 1) have some minor
>>>> problems and 2) want to know what others think about this.
>>>
>>> Late last year, I did some work to convert the svn repository to git.
>>> The code to d the conversion is available at
>>> https://github.com/darrendale/mpl2git . The resulting git repo is
>>> available at https://github.com/darrendale/matplotlib . I have not
>>> pursued the project further because there did not seem to be enough
>>> interest in migrating from svn/sourceforge to git/github to justify
>>> investing more of my time in the project.
>>>
>>>> I'm a native git user and I don't know how to use svn properly.
>>>
>>> I read that as "uninterested in learning how to use svn", and such
>>> sentiment is probably a fact of life as many (most?) open source
>>> projects move to DVC. In my opinion, matplotlib is likely to draw more
>>> contributors if it lowers barriers to entry and uses a DVCS that is
>>> growing in popularity, like git/github.
>>>
>>> Darren
>>>
>>
>> In discussions with Ryan May on the prospect of switching over to git, it
>> sounds like we have a "Bike Shed" problem where we (the main developers)
>> agree that we agree that a bike shed should be built, but we can't agree on
>> the color to paint it...
>
> In my view, the issue has nothing to do with bikeshedding.
Agreed. We *did* agree to move to git, and the only problem was that 
most of us lack the expertise and time to be of much help in actually 
getting it done. I think there was a bit of a hangup over the question 
of migrating the bug tracking; but I suspect we could agree that this is 
a secondary question, and that any such migration, if desired, can be 
done at leisure *after* taking the primary step of switching the code repo.
>
>> I think the main source of the huge download size is the data that is coming
>> from the basemap toolkit. I do not think that it would be a good thing to
>> have everyone and their mother needing to do a 'git clone' on their computer
>> and find they have to pull down 500+ MB of stuff to get matplotlib. It is
>> because of this that a straight-forward migration from svn to matplotlib
>> won't be possible.
>
> The git repo at https://github.com/darrendale/matplotlib does not
> include anything from basemap.
The key point being that you are converting matplotlib/trunk/matplotlib,
not matplotlib/trunk; the latter is what includes py4science, toolkits 
(including basemap), sample_data, etc. I think this is the right approach.
This doesn't all have to be perfect; it just has to be good enough. I 
suspect your conversion is good enough. If you are reasonably 
confident, then I think that if you go ahead and set up a github repo as 
the new official source tree, along with posting whatever notices are 
needed for anyone accessing the svn tree, the active developers will say 
"thank you!", and it will be done.
The other person who has been most interested in the nuts and bolts of 
the conversion is Andrew Straw. Although he is evidently very short of 
mpl time these days, you might want to try to contact him directly to 
see if he has thought of anything you might have overlooked.
I would like to be included in the group with git write access, unless 
there is a clear decision to restrict this group to a very small core of 
gatekeepers.
Eric
>
>> What have been the proposed solutions to dealing with basemap's data?
>
> Separate repo?
>

On Sat, Jan 22, 2011 at 11:55 AM, Benjamin Root <ben...@ou...> wrote:
> On Sat, Jan 22, 2011 at 10:26 AM, Darren Dale <dsd...@gm...> wrote:
>>
>> On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
>> <fri...@gm...> wrote:
>> > Hi,
>> >
>> > I want to set up a git mirror for matplotlib, but I 1) have some minor
>> > problems and 2) want to know what others think about this.
>>
>> Late last year, I did some work to convert the svn repository to git.
>> The code to d the conversion is available at
>> https://github.com/darrendale/mpl2git . The resulting git repo is
>> available at https://github.com/darrendale/matplotlib . I have not
>> pursued the project further because there did not seem to be enough
>> interest in migrating from svn/sourceforge to git/github to justify
>> investing more of my time in the project.
>>
>> > I'm a native git user and I don't know how to use svn properly.
>>
>> I read that as "uninterested in learning how to use svn", and such
>> sentiment is probably a fact of life as many (most?) open source
>> projects move to DVC. In my opinion, matplotlib is likely to draw more
>> contributors if it lowers barriers to entry and uses a DVCS that is
>> growing in popularity, like git/github.
>>
>> Darren
>>
>
> In discussions with Ryan May on the prospect of switching over to git, it
> sounds like we have a "Bike Shed" problem where we (the main developers)
> agree that we agree that a bike shed should be built, but we can't agree on
> the color to paint it...
In my view, the issue has nothing to do with bikeshedding.
> I think the main source of the huge download size is the data that is coming
> from the basemap toolkit. I do not think that it would be a good thing to
> have everyone and their mother needing to do a 'git clone' on their computer
> and find they have to pull down 500+ MB of stuff to get matplotlib. It is
> because of this that a straight-forward migration from svn to matplotlib
> won't be possible.
The git repo at https://github.com/darrendale/matplotlib does not
include anything from basemap.
> What have been the proposed solutions to dealing with basemap's data?
Separate repo?

On Sat, Jan 22, 2011 at 10:26 AM, Darren Dale <dsd...@gm...> wrote:
> On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
> <fri...@gm...> wrote:
> > Hi,
> >
> > I want to set up a git mirror for matplotlib, but I 1) have some minor
> > problems and 2) want to know what others think about this.
>
> Late last year, I did some work to convert the svn repository to git.
> The code to d the conversion is available at
> https://github.com/darrendale/mpl2git . The resulting git repo is
> available at https://github.com/darrendale/matplotlib . I have not
> pursued the project further because there did not seem to be enough
> interest in migrating from svn/sourceforge to git/github to justify
> investing more of my time in the project.
>
> > I'm a native git user and I don't know how to use svn properly.
>
> I read that as "uninterested in learning how to use svn", and such
> sentiment is probably a fact of life as many (most?) open source
> projects move to DVC. In my opinion, matplotlib is likely to draw more
> contributors if it lowers barriers to entry and uses a DVCS that is
> growing in popularity, like git/github.
>
> Darren
>
>
In discussions with Ryan May on the prospect of switching over to git, it
sounds like we have a "Bike Shed" problem where we (the main developers)
agree that we agree that a bike shed should be built, but we can't agree on
the color to paint it...
I think the main source of the huge download size is the data that is coming
from the basemap toolkit. I do not think that it would be a good thing to
have everyone and their mother needing to do a 'git clone' on their computer
and find they have to pull down 500+ MB of stuff to get matplotlib. It is
because of this that a straight-forward migration from svn to matplotlib
won't be possible.
What have been the proposed solutions to dealing with basemap's data?
Ben Root

On Mon, Jan 10, 2011 at 7:46 AM, Friedrich Romstedt <
fri...@gm...> wrote:
> 2011年1月8日 Benjamin Root <ben...@ou...>:
> > The changes look ok to me so far. It looks to be mostly a
> re-organization
> > of existing logic and some consolidation of code. My only concerns are
> the
> > creation of two new functions. Besides the obvious issues with potential
> > namespace collisions in other parts of the code that might do an 'from cm
> > import *', my main issue is that these functions are probably really only
> > meant for internal use and should probably start with an underscore. We
> can
> > always un-underscore them in a later release...
>
> I agree on that the functions are kind of internal. Atm they do not
> reach their aim of generating cmaps from arbitrary specifications
> (generate_cmap can only handle known cmaps by name). It seems to me I
> was too fast and did not think it thoroughly through :-/.
>
> I'm not really satisfied with the current state of the patch with the
> informations you gave at hand. I wrote this patch as it is because I
> assumed functions like ``revcmap`` are supposed to stay
> backward-compatible.
>
> If backward compatibility isn't an issue for this functions, so why
> not going ahead and rewriting the functions so that they deliver some
> useful functionality instead of only helping functionality. And if
> there are non-public stuff functions remaining, we could place an
> __all__ at the top of the file, to prevent them being imported by
> ``from cm import *``.
>
> > I will do a bit more testing to see if I can break it, but barring that,
> I
> > will commit a slightly modified version of the patch later today.
>
> :-/ You are too fast for me.
>
> In fact I think this functions belong to
> colors.LinearSegmentedColormap. Reversing should be a method of that
> one, and they should accept directly all kind of specifications at
> initialisation time.
>
> So what parts should stay backwards compatible and which are we able to
> change?
>
> * Do we have to keep LinearSegmentedColormap.from_list() or should it
> be simply an alias for its __init__()?
> * What is the callable-functionality in cm.revcmap for? It can
> handle callable value items, but where's this used in mpl?
> * And, as said, do we have to keep this list-and-dicitionary mangling
> functions outside of LinearSegmentedColormap? I.e., can we replace it
> by reversing fully-fledged Colormaps, instead of reversing their
> tuple-or-dict specs?
>
> Friedrich
>
Finally got around to committing this. I committed it to the maintenance
branch in r8933 and merged into the development branch in r8934.
Ben Root

On Sat, Jan 22, 2011 at 9:09 AM, Friedrich Romstedt
<fri...@gm...> wrote:
> Hi,
>
> I want to set up a git mirror for matplotlib, but I 1) have some minor
> problems and 2) want to know what others think about this.
Late last year, I did some work to convert the svn repository to git.
The code to d the conversion is available at
https://github.com/darrendale/mpl2git . The resulting git repo is
available at https://github.com/darrendale/matplotlib . I have not
pursued the project further because there did not seem to be enough
interest in migrating from svn/sourceforge to git/github to justify
investing more of my time in the project.
> I'm a native git user and I don't know how to use svn properly.
I read that as "uninterested in learning how to use svn", and such
sentiment is probably a fact of life as many (most?) open source
projects move to DVC. In my opinion, matplotlib is likely to draw more
contributors if it lowers barriers to entry and uses a DVCS that is
growing in popularity, like git/github.
Darren

On Tue, Jan 18, 2011 at 12:27 AM, Jae-Joon Lee <lee...@gm...> wrote:
> Dear Matplotlib developers,
>
> Attached is a patch to improve the functionality of legend.
> The two biggest changes are as follows,
>
> * Drawing of legend is delegated to "legend handlers".
> * Introduces a new "Container" class. This is primarily to support
> legend of complex plots (e.g., bar, errorbar, etc).
>
> The first change is to ease the creation of customized legends. See
> "legend_demo_custom_handler.py" for example.
> The second change is to support legend of complex plots. Axes
> instances now have a "containers" attribute. And this is only intended
> to be used for generating a legend. For example, "bar" plots create a
> series of Rectangle patches. Previously, it returned a list of these
> patches. With the current change, it creates a container object of
> these rectangle patches and return it instead. As the container class
> is derived from a tuple, it should be backward-compatible.
> Furthermore, the container object is added to the Axes.containers
> attributes. And legend command use this "container" attribute to
> properly create a legend for the bar.
>
> A two example figures are attached.
>
> As this patch introduces relatively significant changes. I wanted to
> get some comments from others before I commit.
> The change will be divided into four commits.
>
> Regards,
>
> -JJ
>
>
Nice. I will look through it this week and see if I can break it.
Ben Root

Hi,
I want to set up a git mirror for matplotlib, but I 1) have some minor
problems and 2) want to know what others think about this.
I'm a native git user and I don't know how to use svn properly. So I
try everything to avoid svn. Furthermore, I like git so much that I
don't want to give it up when developing for matplotlib.
As is well-known, there *is* already a git mirror for mpl, using
svnmerge.py, i.e., http://github.com/astraw/matplotlib. Anyway, this
repo seems to be not actively maintained for monthes. The last comit
on branch trunk is from Nov 12, 2010.
Yesterday I tried git-svn on the matplotlib sf repo, and it took quite
a long time (already ~500 MB), but it stopped with some error message:
RA layer request failed: REPORT of
'/svnroot/matplotlib/!svn/vcc/default': SSL negotiation failed:
Connection reset by peer (https://matplotlib.svn.sourceforge.net) at
/usr/local/libexec/git-core/git-svn line 5061
I could imagine the sf server treated me as some DoS user.
I attach a part of the log of how I initialised the git repo (without
the middle part), and also some tees of $git branch -a and $git log
trunk | head -n 150.
I realised that I used different options to git svn init (i.e., I used
--std-layout) than stated on
http://matplotlib.sourceforge.net/devel/coding_guide.html#using-git,
but I cannot see why I should use --trunk=trunk/matplotlib
--prefix=svn/. From the logs of $git svn fetch, it looks good.
If there is no feedback until today eve here in Germany (in ~6 hrs),
I'll try again today evening to $git svn fetch some more of the repo.
If there is positive feedback, I'll consider writing to the github
guys to give me ~2 Gigs of storage for the mirror. If there is
negative feedback, I'll consider giving the project up. Note, that it
is inevitable for me to publish the mirror when Ben and I want to use
it (for some project we have since a few monthes on mpl).
I would suggest to always put git changes *on top* of svn changes, so
no use of $git merge trunk, but always $git rebase. This is the only
way to make usable diffs which can go in into svn on sf as far as I
can see.
There is a general problem which will pertain all git users: Once the
changes went via svn into the sf repo, they reappear on the github
mirror, causing conflicts in the branches on github where they
originally came from. The solution to this would be clear, but I
think there will be no way to get a consensus to switch from svn to
git on mpl completely.
Friedrich