On Wed, Jul 21, 2010 at 6:38 AM, Andrew Straw <straw...@astraw.com> wrote: > On 7/20/10 8:06 PM, Fernando Perez wrote: >> On Tue, Jul 20, 2010 at 7:43 PM, John Hunter<jdh2...@gmail.com> wrote: >> >>> The major issues I am aware of are: >>> >>> * what do to about all the various subdirs of the mpl trunk >>> (trunk/toolkits/basemap, trunk/sample_data, etc..). An svn commit to >>> one tags all with a unique revision number. In git, how do we >>> synchronize between them? Putting them all in the same tree would be >>> monolithic and require huge checkouts. Unlike svn, in git it is >>> difficult/impossible to check out just a subdir (eg trunk/matplotlb) >>> and also commit to it. So we might end up having to informally >>> synchronize parts of the trunk. Eg, basemap rXXX requires mpl rYYY in >>> the CHANGELOG or release notes. >>> >> Probably using a common tag across repos would be the easiest. Any >> time you want a known 'sync point', you tag all the relevant repos >> with the same tag. It then becomes very simple to write a little >> script that will update checkout a bunch of repos sitting in the same >> parent directory (each as its own dir, of course) at a common tag. >> You can make up a convention for these special tags so that they are >> always named with a given pattern (you could even use rNNNN if you >> wanted). >> > We could also make a meta repository that uses git submodules (somewhat > akin to svn externals). Each commit in a repo that links to submodules > specifies a specific revision of the submodule repo, so this meta > repository would be a fairly natural way of linking across several > repositories at specific revisions. That being said, a convention to > simply use the standard git tags would also work fine, and wouldn't > require people to learn git submodules. So, it's really a question of > sticking to a convention (that has a lesser learning curve) or using a > new set of commands that would more or less do exactly what we want, but > would have to be learned. I'm agnostic on the issue.
Is it possible to do both simultaneously for a while, to test whether submodules works for us in practice? I have long been interested in using something along the lines of submodules or nested repositories, and a metarepository would seem to be exactly what we need. But this business about cloning yielding empty submodules until you initialize them, but then they are detached heads, remembering not using trailing slashes when staging changes in a superproject... hopefully these will not be issues, but we might need some time before we decide whether we like submodules enough to embrace it long term. I just finished a long run at work, and should have some time in the next couple weeks during evenings and weekends that I could contribute to the git and python3 transitions. Darren ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
