On Sep 17, 2011, at 12:54 PM, Schmidt Christopher (Nokia-S/Boston) wrote: > > On Sep 16, 2011, at 3:04 PM, ext [email protected] wrote: > >> >> On Sep 16, 2011, at 2:48 PM, ext Tim Schaub wrote: >> >>> I'd like to propose we move the trunk to GitHub. If other agree, we >>> could maintain a read-only svn mirror at the current URL. And, the >>> sandboxes could stay as they are. The only consequence of this move >>> would be that trunk committers use git instead of svn. >>> >>> I'm +1 on this change. >>> >>> Andreas is traveling, but he told me he was +1 on it as well. >> >> I'm +0. Do we have an idea of how we want to make the move? Do you anticipate >> wanting to move tags, branches, etc. over as well? (My understanding when >> I looked was taht this makes things... hard.)
Given the broad support for this from the core developers, and the code sprint this weekend, I have gone ahead and implemented this change while I had the time available. As of now, the correct place to commit to OpenLayers is the OpenLayers github at: https://github.com/openlayers/openlayers All OpenLayers core committers have commit access. Please continue to follow the same general policies -- close messages, trac tickets where appropriate, etc. -- as before, but for source commits, commit to OpenLayers. (If for some reason someone feels strongly about this change and we need to go backwards, we can do so.) -- Chris > Okay, so: > 1. Moving svn to git is hard, but doable; I'm working on that part. > 2. We'll move project/ (website), doc/ and trunk as three seperate > github projects under the OpenLayers organizations. > 3. Sandboxes will continue to live in SVN if people want to use them. > We'll also write up docs as to how to achieve sandbox-like live > deployments using github forks/gh-pages instead, if people would > rather use git. We won't automatically deploy github forks to > dev.openlayers.org like we do sandboxes. > 4. trunk examples are easy. > 5. Releases shouldn't be much different; we'll have to modify our tools > to do things like switching branches/making tags/ etc. in the git > way, but there's nothing super-complex here. > 6. We will maintain pushing all of trunk commits from git to SVN. > 7. We won't push branch or tag commits back to SVN after the switch. > This means that for future releases, if you want to actually check > out the code, you'll need to use git rather than SVN. Given that checking > out from a specific tag is a relatively minor use case, I'm not > concerned we're screwing that many people here. (The actual releases will > obviously continue to be available.) > > Still open questions: > - Github can't do commit emails with diffs. (A diff *link* is included, but no > diff, like: > > Branch: refs/heads/djangozoom > Home: https://github.com/crschmidt/olhttp > > Commit: 2676cc08a8ce5274f272bd81c6d6314efad0a1e9 > > https://github.com/crschmidt/olhttp/commit/2676cc08a8ce5274f272bd81c6d6314efad0a1e9 > Author: Christopher Schmidt <[email protected]> > Date: 2011-09-17 (Sat, 17 Sep 2011) > ) > > If people are dependent on the diffs, we'll have to do something else; > otherwise, > we can just go ahead with making commit posts go to the commits list without > much > further work. > > We'll also need to set up a hook from github to ping OpenLayers when commits > are made so that we can do the mirror step to the OL repo; Eric has been > working > on that, and I think it's just the web/hook side now. > > Overall, I think that all the major pain points are easily resolvable without > major work. I think the release engineering bits are totally doable, and I'm > no longer worried about them. > > -- Chris > >> I don't have any idea how to manage branching for releases and the like >> in github; do others have an idea of how these kinds of things are supposed >> to work? >> >> I'm worried about release engineering approaches; other than that, I have >> no major concerns, and I'm sure that others can help me understand how >> these things are supposed to work and how they will be reflected in the >> SVN repository from the Git repository. >> >>> Tim >>> >>> -- >>> Tim Schaub >>> OpenGeo http://opengeo.org/ >>> Expert service straight from the developers. >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/openlayers-dev > _______________________________________________ Dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/openlayers-dev
