On Sep 16, 2011, at 3:04 PM, ext christopher.schm...@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.)
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 <crschm...@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
>> d...@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>
> _______________________________________________
> Dev mailing list
> d...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
