Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Section
Column
width70%
Table of Contents
Column

Children:

Children Display

Description

As per our blog post on the topic:

Hi all,
the GeoTools developers have been working, so far, with Subversion as the main version control system. However various core developers have been using Git as a SVN client for quite some time so far, and an [official mirror|https://github.com/geotools/geotools] of Geotools, automatically kept in synch with Subversion, is already available on GitHub.

We are now considering switching permantently from Subversion to Git, meaning the Subversion repository will eventually be abandoned and only the Git official central repo will be kept up to date.
Before making such move we'd like to hear from the users community, please take one minute to share your opinion about the switch to Git:

click here to go to the poll

...

The results of this poll were:

Chart
typeorientationbarhorizontal
QuestionSupport
17 I'd prefer you to keep on using SVN
14It's the same to me
5I'd like Mecurial better
0 I'd like Bazaar better
64Switching to Git is Great

 

...

subTitleGeoTools is considering switching version control from SVN to Git. How you do feel about that?
yLabelOptions
titlePoll Results
xLabelPercentage
legendfalse
typebar
dataDisplayafter
Support 
 I'd prefer you to keep on using SVN

...

17
It's the same to me

...

14
I'd like Mecurial better

...

6
 I'd like Bazaar better

...

0
Switching to Git is Great

...

64

The poll generated 212 votes (this is greater than our number of comitters!)

There are three more hesitations which have now been resolved:

1) The active developers needed to be comfortable with the use of git. This has now taken place.
2) We needed a good story to tell for windows developers. With the release of the [github windows client|http://windows.github.com/] we now have a sensible suggestion.
3) GeoTools 8

...

Description

This is not a suggestion to move to git - it is a proposal to move to github:
* uDig found that using using http://gitorious.org/ worked  worked out well - but still failed due to lack of documentation. Indeed most advice on using git comes from the github docs; stack exchange where github is always used as an example.
* The ease of use of the "fork me" / "pull request" workflow provides the critical glue to allow an open source project to work; as distributed version control no longer provides the motivation for contributors to obtain direct commit access.
* github is simply fashionable. Anecdotal evidence of this is an "if it is not on github must be dead" attitude encountered on IRC

There are three more hesitations which have now been resolved:

1) The active developers needed to be comfortable with the use of git. This has now taken place.
2) We needed a good story to tell for windows developers. With the release of the http://windows.github.com/ we now have a sensible suggestion.
3) GeoTools 8

Additional discussion and support on the email list:

Checklist form justin:

  • a quick primer for people with sample commands for common tasks
  • a list of git does and donts, ie don't rebase on a public branch, etc... 
  • line endings figured out re Bens comment
  • a way to get git revision info from the build... we currently have an svn plugin that does this but no git equivalent, there is a plugin but it turned out to be pretty flaky so we ditched it
  • decide on hosting, are we ok with github?

Status

This proposal is under construction; and won't be submitted until the tasks are sorted out and GeoTools 8 is released.

Voting has not started yet:

...

 

no progress

(tick)

done

(error)

impeded

(warning)

lack mandate/funds/time

(question)

volunteer needed

  1. API changed based on BEFORE / AFTER
  2. Update default implementation
  3. Update wiki (both module matrix and upgrade to to 2.5 pages) |
  4. Remove deprecated code from GeoTools project
  5. Update the user guide
  6. Update or provided sample code in demo
  7. review user documentation

API Changes

Filter

BEFORE:

Code Block
import org.geotools.filter.Filter;
public void exampleMethod( DataStore store, Filter filter){
    FeatureCollection collection = store.getFeatures( filter )
    ...    
}

AFTER:

Code Block
import org.opengis.filter.Filter;
public void exampleMethod( Source source, Filter filter){
    Collection collection = source.content( filter )
    ...    
}

Documentation Changes

list the pages effected by this proposal

...

  1. Update the documentation for checkout and build (can use the uDig docs as a good starting point for this)
    • Try out the docs using the official github fork
  2. Update the developers guide with a note about pull requests; and any other requirements:
    • a quick primer for people with sample commands for common tasks
    • a list of git does and donts, ie don't rebase on a public branch, etc... 
    • line endings figured out re Bens comment
  3. Update the build procedure:
    • Maven: a way to get git revision info from the build...
    • Hudson: update the scripts to pull from git
  4. Transition the repository
    • Contact github about the size of the repository; uDig experience shows this will be fine - but it is good to ask.
    • Can we can start from the official github fork? Or do we need to go back and pull more history?
    • Turn off the old repository; create an Track issue for OSGeo SAC
  5. Transition comitters
    • Grab the commuter list from OSGeo servers; send out an email asking for github IDs
    • Create GeoTools PSC and GeoTools Committers Groups (uDig organisation is an example here)
    • Add github IDs as appropriate
  6. Release form the new repository
    • Update any of justin's automated scripts
    • Update the how to cut a release page in the docs