John Hunter wrote: > 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? >
John, Eric, Andrew: I am OK with this. Don't know much about DVCS systems, but I guess this will be my excuse to learn. -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 > -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : jeffrey.s.whita...@noaa.gov 325 Broadway Office : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg ------------------------------------------------------------------------------ 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
