[mapserver-dev] move to github ?

Thu Mar 22 20:32:56 PDT 2012

I'll support the more knowledgeable and active devs on this one and adapt as necessary. I probably didn't want to move away from cvs to svn when that change happened.

That said, seems that a small RFC would be in order here to help formalize the process.

Looking back at the discussion and the 4 options Thomas originally proposed. I'd prefer 3/4- github with *selected* open tickets. If there's a hosted solution that's better than github then cool but I'm thinking it would be nice to be out of as much infrastructure administration as possible.

Steve

________________________________________
From: thomas bonfort [thomas.bonfort at gmail.com]
Sent: Thursday, March 22, 2012 5:43 AM
To: Lime, Steve D (DNR)
Cc: MapServer Dev Mailing List
Subject: Re: [mapserver-dev] move to github ?

On Thu, Mar 22, 2012 at 11:10, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> Here's my workflow from the last couple of days, when using github to
> hack on the mapcache source, hoping the strengths of the solution will
> become clearer.
>
> I started working on adding a tokyocabinet cache backend to mapcache,
> so I create a branch for it:
>
> # git checkout -b tokyocabinet
>
> My source tree is now in this new feature branch, I hack away and add
> the new feature, optionally comitting along the way once I reach local
> milestones. Once the initial implementation is up and running, I
> commit it, and can optionally push it back to the github server for
> others to try it:
>
> # hack, hack, hack
> # git add lib/cache_tokyocabinet.c include/mapcache.h   // add the
> modified files to the list of files that need comitting
> # git commit -m "initial implementation of a tokyo cabinet cache backend"
> # git push origin tokyocabinet  // publish my tokyocabinet branch, it
> is not merged to the trunk yet
>
> I then start working on optimizing the cache code, by adding a
> connection pool. A trac notification comes in signaling a bug in
> mapcache trunk, so I switch to the trunk ("master") branch of mapcache
> and fix the bug.
>

As someone promptly replied to me offlist on this part, I will correct
this: You don't hack directly on the master, you create a branch. svn
reflexes are hard to loose :). To my defense, the fix was a single
character typo change, so I did not branch. Any non trivial bug fixing
would go from

> # git checkout master
> # debug, hack
> # git add -A  //add all changed files to the commit list
> # git commit "fix bug #1234"
> # git push origin master  // publish changes to the github repository

to
# git checkout -b bug1234
# debug, hack
# git add -A  //add all changed files to the commit list
# git commit "fix bug #1234"
# git checkout master
# git merge bug1234
# git push origin master  // publish changes to the github repository

This allows you to cleanly work on any other stuff, should the fixing
of bug 1234 take longer than a few minutes.

>
> # git checkout tokyocabinet  // return to hack on my new feature
>
> I continue hacking on my connection pool, unfortunately the resulting
> code is unstable, tokyocabinet does not like concurrent connections. I
> create a new branch for this code so I can come back later to hack on
> it when I have the time.
>
> # hack hack hack, fail to get something satisfactory
> # git checkout -b tokyocabinet-connectionpool  //create a new branch
> # git add lib/cache_tokyocabinet.c
> # git commit -m "initial implementation of a connection pool for
> tokyocabinet, still not working due to concurrent access issues"
> # git push origin tokyocabinet-connectionpool   //publish the code.
> this is optional, but I want my test code to be backed up somewhere
>
> After testing some more, the initial version of the tokyocabinet code
> is stable enough to be included in the master
>
> # git checkout master  //switch to "trunk"
> # git merge tokyocabinet
> # git push origin master  //publish the changes
>
> I don't need the tokyocabinet branch anymore, so I delete it
>
> # git branch -D tokyocabinet  //delete locally
> # git push origin :tokyocabinet  //also delete the published branch on
> the github server
>
> I am now in a state where I can come back to the
> tokyocabinet-connectionpool branch some day. Note that all the
> commands I used beforehand where instantaneous, except for the "push"
> ones which required a network access to publish my changes. During all
> the hacking phases, I could have merged incoming changes from other
> devs to my branches with:
>
> # git pull origin master   //equivalent to svn up in trunk
> # git merge master  //merge the changes to my hacking branch
>
> --
> thomas
>
> On Tue, Mar 20, 2012 at 18:23, thomas bonfort <thomas.bonfort at gmail.com> wrote:
>> On Tue, Mar 20, 2012 at 17:32, Lime, Steve D (DNR)
>> <Steve.Lime at state.mn.us> wrote:
>>> I'm kind of in the same boat as Frank and am not up on the differences and/or benefits of one versus the other. Seems like that's a worthy discussion...
>>
>> I'll try to give some points which are the most important to me. I'm
>> far from knowing git well enough to list all of them so if others want
>>  to chime in please do.
>>
>> git alone (without github):
>> - you get the whole project history, without needing to go online
>> - offline commits mean you can much more easily create revision points
>> when you're on the road and are working on multiple tasks. I can't
>> count the number of experimental patches I have thrown away because I
>> needed to fall back to a clean trunk when fixing an urgent ticket.
>> - the workflow is somewhat changed: you create a branch (no need to be
>> online) as soon as you start working on a new feature, or on fixing a
>> given ticket. Switching from one branch to another is done instantly,
>> which means you can work on parallel tasks very easily, without
>> risking that your changes interfere with one another. three way merges
>> make merging code from one branch into another much less painfull than
>> with svn+patch
>> - all this means that we also don't have to go through the
>> feature-freeze where all development is halted in trunk while we
>> release. You just merge back the fixes of the release branch back into
>> the trunk (called master by convention).
>>
>> github:
>> - pull requests (along with easy branches) make applying user-supplied
>> fixes much easier.
>> - code commenting (add comments directly aside a specific line in a
>> changeset) makes collaboration much lighter than having to create a
>> full email recapitulating the context.
>> - online code edition, typically for quickly committing a typo fix.
>>
>> Aside from that, all the people I know who have switched from trac+svn
>> to git+github would never move back to the old solution. The git
>> learning curve is quite steep (although using it the same as svn isn't
>> very challenging) but I think very well worth it. Of course, that is
>> provided you hack frequently on the code.
>>
>> --
>> thomas
>>
>>>
>>> Steve
>>> ________________________________________
>>> From: mapserver-dev-bounces at lists.osgeo.org [mapserver-dev-bounces at lists.osgeo.org] on behalf of Frank Warmerdam [warmerdam at pobox.com]
>>> Sent: Monday, March 19, 2012 9:39 PM
>>> To: thomas bonfort
>>> Cc: MapServer Dev Mailing List
>>> Subject: Re: [mapserver-dev] move to github ?
>>>
>>> On Mon, Mar 19, 2012 at 9:52 AM, thomas bonfort
>>> <thomas.bonfort at gmail.com> wrote:
>>>> any other options? what are your thoughts?
>>>
>>> Thomas,
>>>
>>> Since you ask - I'm happy with the way things are!
>>>
>>> Best regards,
>>> --
>>> ---------------------------------------+--------------------------------------
>>> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
>>> light and sound - activate the windows | http://pobox.com/~warmerdam
>>> and watch the world go round - Rush    | Geospatial Software Developer
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev