[mapserver-dev] move to github ?

[thomas bonfort]

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.

# 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

# 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