[OpenLayers-Dev] MOTION: move to GitHub

Tim Schaub tschaub at opengeo.org
Sat Sep 17 19:43:27 EDT 2011

For people that had clones of the old repository, you won't be able to
work with these any more.  The new import from svn came with new ids
for all commits, so merges are not possible with clones of the old

If you have a project with the old 2.x git branch of OpenLayers as
submodule, some work needs to be done.

1. rm -rf path/to/submodule/openlayers
2. git submodule update
3. ignore the error from the above
4. git add path/to/submodule/openlayers
5. git commit


On Sat, Sep 17, 2011 at 3:20 PM,  <christopher.schmidt at nokia.com> wrote:
> On Sep 17, 2011, at 12:54 PM, Schmidt Christopher (Nokia-S/Boston) wrote:
>> On Sep 16, 2011, at 3:04 PM, ext christopher.schmidt at nokia.com 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 <crschmidt at crschmidt.net>
>> 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
>>>> Dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev

Tim Schaub
OpenGeo http://opengeo.org/
Expert service straight from the developers.

More information about the Dev mailing list