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). > * organizational stuff: how do we handle the notion of the central > repo? Now that github support "organizations" this should be > relatively easy. Andrew and I registered a matplotlib user acct at > github and created a gmail acct mplgithub as a central administrator > (matplot...@gmail.com was taken, the bastards). Email me offlist if > you are interested in obtaining the passwd for the github or gmail > admin accts -- but you should probably coordinate with Andrew who is > our point person as soon as he re-emerges. No need. Organizations let you designate more than one 'owner', so you can mark more than one person with full admin privileges without having to give out the password around. I recently converted the extra ipython account to an organization, added Brian Granger as a second 'owner', and that's it. You can then make as many teams and repos as you want within an organization. The github org model is fairly simple but very effective (much nicer than how launchpad uses teams). > * porting the buildbot to work w/ github commits > > * related: porting the trunkdocs build to work with github commits > > * how to handle the svn tree at sf -- should it mirror the new github > tree or remain stale or simply removed? I would freeze it during a transition period and later on make a static backup of teh repo dump somewhere for historical purposes (and just in case, disk is cheap). I would then nuke it for simplicity of administration, since on github people can still use svn if they want to track a git repo: http://github.com/blog/626-announcing-svn-support I should note that I have not used this in practice, but a quick and dirty test with the ipython repo seems to work (you just get the master git branch though): amirbar[junk]> svn checkout http://svn.github.com/ipython/ipython.git [...] amirbar[junk]> cd ipython.git/ amirbar[ipython.git]> svn info Path: . URL: http://svn.github.com/ipython/ipython.git Repository Root: http://svn.github.com/ipython/ipython.git Repository UUID: e94b1212-8258-e27c-589c-ce57b7db7bff Revision: 2611 Node Kind: directory Schedule: normal Last Changed Author: fernando.perez Last Changed Rev: 2611 > Please add to the list other issues that need to be handled. > > Of all these, I'm only concerned philosophically with the first. The > others are matters of time and work as people make the transition to > the new server. The first seems like a true potential workflow > impediment for those who run off svn/git HEAD and analogues. Others with more git expertise may suggest a different workflow, but for that the tags approach, along with a couple of simple script helpers to make creation/checkout of these tags a one-line operation, seems like it should do the job. Cheers, f ------------------------------------------------------------------------------ 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
