Andrew Straw wrote:
This is a good point. My preferred option is that we jettison all the
stuff that is not going to be shipped with MPL 1.0 from the git repo.
(More correctly - we build a git repo without that stuff ever going in.)
We can keep the old svn tree around and migrate the other projects to
git as desired. I think this is what's present in
http://github.com/astraw/matplotlib . Or am I missing something?
No, that is what you have, and I agree that this strategy makes sense.
I just wanted to make sure everyone understood, and make the plan explicit.
It looks like Andrew has trunk/matplotlib. There is other stuff in
trunk that definitely should not be migrated, and some stuff that
* trunk/py4science, which is a project Fernando and I have been
working on for several years but is not specific to mpl (it only uses
mpl). We will eventually migrate this into it's own repo, but this
is not an mpl project and should not be migrated.
* trunk/course - looks like a very old and no longer used py4science
dir. Should probably be simply deleted and not frozen
*trunk/htdocs - the old mpl site docs. Should live somewhere for
archival purposes in case there is a useful code snippet in there, but
certainly does not need to be in git or the new repo. It could live
frozen in the sf repo.
* trunk/sampledata - this is important. The mpl trunk examples use
this to pull example data. We will need to migrate this -- we could
leave it in sf svn, but it might be preferable to have one version
control system. Whatever we do here, we will need to update
matplotlib.cbook.get_sample_data to work with the new system.
Definitely an argument for getting all this migration sorted out
before a trunk release.
* trunk/sampledoc_tut - this is the source code for the
http://matplotlib.sf.net/sampledoc tutorial which shows how to build
mpl like sites using sphinx and associated extensions. Related to mpl
in that it uses the plot directive etc, but is by no means integral.
I can eventually port this to a new repo if there is any reason to.
* trunk/scipy06 should probably be deleted
* trunk/toolkits - should probably be migrated (Andrew you have not
migrated this right?). One nice thing about having the toolkits in
the same svn repo as the main codebase was for revision tagging, so
basemap svn commits are synched with a trunk/matplotlib state. How
should we proceed with the toolkits repo? Jeff?
* trunk/users_guide - the old latex source for the mpl user's guide.
Deprecated but should not be deleted. Same treatment as trunk/htdocs
If we end up migratinga the toolkits to git/github (pending Jeff's
comments) we may want to branch the stuff in trunk we want to keep for
archival purposes (htdocs, users_guide) and clean as much stuff out of
trunk as possible to avoid confusion for people browsing the trunk
(and put a README in there explaining what and where stuff is).
I think the plan is to keep trunk/matplotlib as a tracking repo, so
that commits to the git master are pushed to the svn repo, so casual
users who are running from svn HEAD will not be affected by the
migration. Is this your understanding, Andrew?
Does it makes sense to retain the entire history in the new github repo,
or would it be just as well to start from a later point so as to reduce
the size? The entire history could still be available in a separate
read-only repo, or fossilized in svn on sourceforge, or in my hg mirror.
(Andrew's repo, at just under 200MB, is not prohibitively large by any
means, but it is a bit hefty.)
I can see advantages either way, but I'm in favor keeping it. Tons of
MPL is undercommented, and seeing the history is extremely useful when
I am strongly in favor of keeping the entire commit history of
trunk/matplotlib. While the repo is large now, most of the size comes
from data and regression test images, and the early history is largely
code so will not add much incremental size. I suppose one of the
downsides of git is since you have to get the *entire* history on one
checkout, you end up with a bunch of stuff you are unlikely to ever
need, like data that was once in the repo but has now been removed (eg
the stuff we migrated to sampledata). Not sure if there is an easy
On Tue, Mar 2, 2010 at 11:41 PM, Eric Firing <efiring@...229...> wrote: