On Tue, Mar 2, 2010 at 11:41 PM, Eric Firing <efir...@hawaii.edu> wrote: > 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 needs consideration. * 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 above. 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 > spelunking. 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 solution here. JDH ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
