Using git for opencaching

[OlofL]

I would like to share the "opencaching using git" experience we have gained this year.

When moving opencaching.se from the polish code base to the german code base we branched the german svn. We checked out the branch in git and decided to work in git and then merge our work back into svn when we have finished. This was meant as a pilot for testing out if git was a useful tool and would not have happened unless tosubo had administered it from start.

Our experience of this pilot is very interesting. The tool is less user friendly and much more complex to learn than svn, but it is much more powerful and much more suited for casual and multi-branch development than svn. This however comes at a cost.

git is desribed as a distributed version control system, but you could also describe it as a two stage checkin. The checkin is done in a local "version control server". The changeset can then be moved between other "version control servers", for example one that is public and acts as master.

The extra work involved working with git is that after checkin you need to push your changesets to "the master" and to get access to others work, you need to fetch it from "the master" and merge it into your own local "version control server".

After learning a few basic concepts this actually works very, very good. Sending around changesets and merging them works like magic.

The plan was to terminate the git-pilot and merge our changes into the german master svn, but lately we have started to think of switching to git also for the german source. If that is the descision then we need to create a group and configure a new master for this.

[OlofL]

Here are some examples on how to collaborate using git.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#public-repositories

What we want to accomplish is to get new and to the rest of the team unknown developers possibity to contribute without compromising security of the production code. The pull request model described above is very well suited for this.

[opencaching.su]

Hi all,

Using distributed source control is a right thing. But... project sources are in GitHub (https://github.com/totsubo/se2de-merge/), tracker is in Google Code (http://code.google.com/p/opencaching/), developer forum is at (http://forum.geocaching-network.com)...

Probably it would be better to keep all the parts in the same place?

I am not familiar with Google Code and GitHub, but Source Forge offers all the stuff: source control (either Git or Mercurial or CVS or SVN or Bazaar or ...), tracker (SF's tracker or Mantis), forums (public and closed (for developers only)). It also offers much more — stuff for wiki, blogging, mailing lists...

I am not insist on Source Forge. I am ok with either Google Code *or* GitHub, but not both.

Any thoughts?

[opencaching.su]

http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

[oliver]

Any thoughts?

We might get trouble with the licensing requirements of sourceforge. For hosting at sourceforge, all our codes need to be GPL (or other open source license). We have several different licenses used at the moment (see doc2/license.txt).

[OlofL]

It doesn't matter to me if we use what we have today or something else as long as the tools work. Which also means that if you configure and setup something that works better than we have today I will start using that instead.

[opencaching.su]

We might get trouble with the licensing requirements of sourceforge. For hosting at sourceforge, all our codes need to be GPL (or other open source license). We have several different licenses used at the moment (see doc2/license.txt).

I checked almost all the 3rd party components, updated few links, added some comments and license names. Here is my version of the file:

Code: [Auswählen]



             Opencaching Network Implementation Version 2.0





                                                                  18th July 2007



License Information



Copyright (C) 2006, 2007  opencaching.de



This program is free software; you can redistribute it and/or modify

it under the terms of the GNU General Public License as published by

the Free Software Foundation; either version 2 of the License, or

(at your option) any later version.



This program is distributed in the hope that it will be useful,

but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

GNU General Public License for more details.



You should have received a copy of the GNU General Public License

along with this program; if not, write to the Free Software

Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA





In addition to the GNU GPL:



You have to name and/or link opencaching.de to your customers as

original author of the used parts in your implementation.



This license is only valid for the source code and documents stored in the

public CVS repository. There is a separate license agreement located on

opencaching.de for data transfer from and to opencaching.de.



If you are using this source code to establish a geocache listing service

or some sort of service which can be compared with it, you agree to

populate your geocaching data via XML the same way and under the same

(or less restrictive) conditions as opencaching.de does.





A different license may apply to third party components being used.



List of third party components:



    1.  Smarty: Template Engine

        URI     : http://www.smarty.net/

        License : LGPL 3.0



    2.  Smarty Gettext (modified)

        URI     : http://sourceforge.net/projects/smarty-gettext

        License : LGPL 2.1



    3.  cracklib: Password checking library

        URI     : http://sourceforge.net/projects/cracklib

        License : LGPL 2.1



    4.  b2evo captcha

        URI     : http://sourceforge.net/projects/b2evo-captcha

        License : GPL

        TODO: *** Package contains fonts, font licenses are not checked yet. ***



    5.  OpenGeoDB

        URI     : http://sourceforge.net/projects/opengeodb/

        License : Public domain



    6.  NGA GEOnet Names Server (GNS)

        http://earth-info.nga.mil/gns/html/index.html



    7.  InputFilter (modified)

        URI     : http://freshmeat.net/projects/inputfilter/

        URI     : http://cyberai.users.phpclasses.org/package/2189-PHP-Filter-out-unwanted-PHP-Javascript-HTML-tags-.html

        License : GPL



    8.  RFC(2)822 Email Parser by Cal Henderson

        URI     : http://iamcal.com/publish/articles/php/parsing_email

        License : CC BY-SA 2.5 / GPL 3.0



    9.  ImageCreateFromBMP & ImageBMP

        http://www.jpexs.com/eng/default/php.html   *** DEAD LINK ***



    10. PROJ.4: Cartographic Projections Library

        URI     : http://proj.maptools.org/

        License : MIT



    11. NUTS boundaries from Eurostat

        URI : http://epp.eurostat.ec.europa.eu/portal/page?_pageid=2254,62148876,2254_62153840&_dad=portal&_schema=PORTAL

        (*** DEAD LINK ***)



    12. NuSOAP: SOAP Toolkit for PHP

        URI     : http://sourceforge.net/projects/nusoap/

        License : LGPL 2.1



    13. FamFamFam Flag

        URI     : http://www.famfamfam.com/lab/icons/flags/

        License : Public domain



        “Flags” are 247 icons — in GIF and PNG formats — representing

        most countries in the world as small pixel icons. These flag

        icons are available for free use for any purpose with no

        requirement for attribution.



    14. JavaScript, DHTML Tooltips

        URI     : http://www.walterzorn.de/tooltip/tooltip.htm

        License : LGPL



    15. PHP Class: HTML to Plain Text Conversion

        URI     : http://www.chuggnutt.com/html2text.php

        License : GPL



    16. Garmin Communicator API

        https://my.garmin.com/api/communicator/key-generator.jsp



    17. Prototype JavaScript framework

        URI     : http://www.prototypejs.org/

        License : MIT



    18. In his hands: Font

        URI     : http://www.fontdownloadsfree.com/fonts/1/22/inhishands_inhishan.html

        Licence : *** UNKNOWN ***



    19. EnlargeIt!: A little Javascript enlarging thumbnail images with a mouse click.

        URI     : http://enlargeit.timos-welt.de

        License : GPL 3.0



    20. IE PNG Fix

        URI     : http://www.twinhelix.com/css/iepngfix/

        License : LGPL 2.1



    21. Automatic Image Rotator

        URI     : http://www.automaticlabs.com/ (*** no longer available online ***)

        License : *** ??? ***



    22. MultiFlex-2 CSS Design

        http://www.openwebdesign.org/design/2876/MultiFlex21/



    23. TinyMCE: JavaScript WYSIWYG Editor

        URI     : http://tinymce.moxiecode.com/

        License : LGPL 2.1


I would like to add location of each component within the OC source tree. Will do it later.

How can I commit it back to git repository?

[OlofL]

...
How can I commit it back to git repository?

Great! There are currently two options:
- Create a patch and send it to me by mail (olof_laurin (at) yahoo.com)
- Fork the project at github, push your change to your fork and create a pull request

The third option, to push directly to the master, will be available in the future but currently it unfortunately is not.

[opencaching.su]

...
The third option, to push directly to the master, will be available in the future but currently it unfortunately is not.

Hmm... It is not a good option. I would like somebody to review my changes anyway.

Ok, will try to follow the second one.

[OlofL]

Note on how we have collaborated so far and how we will collaborate in the near future (=going live of oc.se).

From github:

There are two popular models of collaborative development on GitHub:

   1.  The Fork + Pull Model lets anyone fork an existing repository and push changes to their personal fork without requiring access be granted to the source repository. The changes must then be pulled into the source repository by the project maintainer. This model reduces the amount of friction for new contributors and is popular with open source projects because it allows people to work independently without upfront coordination.
   2.  The Shared Repository Model is more prevalent with small teams and organizations collaborating on private projects. Everyone is granted push access to a single shared repository and topic branches are used to isolate changes.

The small team for the oc.se upgrade has been using method no 2. Since the repo admin isn't active at the moment we cannot add any more collaborators than the two who already are. Additional users will need to use method no 1.

[OlofL]

Collaboration on the next step (=going live of the upgrade for oc.de or some other site) I think it is a good idea to have more than 2 people with write access to the main repo, so maybe no 1 for new people joining the project and no 2 open when users have been active and contributed for some time? Let's just not make it too complicated.