wiki:GitMigration

Version 43 (modified by martinl, 6 years ago) ( diff )

two migration scenarious

Table of Contents

  1. Background and aims
  2. Choosing a git platform
    1. Available options
    2. Risk of "vendor lock in"
    3. Requirements and criteria
  3. Steps done
    1. User Survey
    2. git test migration
    3. PSC vote
  4. Implementation of migration from OSGeo SVN and trac to GitHub
    1. Migration plan (draft)
      1. Scenario 1 (source code + issues in one step)
      2. Scenario 2 (two steps)
    2. Transfer to repo to OSGeo organization within GitHub
    3. Needed source code updates
    4. Migration of trac issues
    5. New labels in the GitHub issue tracker
    6. Migration of trac wiki
    7. Setup of Gitlab mirror
  5. Future plans not being part of initial migration
    1. Backporting bot
    2. Zeonodo based DOIs
    3. CI/CD and QA
    4. Next release

Migrating GRASS code repository from SVN to git

Background and aims

SVN has served the GRASS project well as a version control system for numerous years now. The project has established routines and infrastructure (code repository, ticketing system, developer wiki) connected to SVN. However, with an increasing number of Open Source developers using git (and here especially the success of GitHub), interest in moving from SVN to git has been expressed.

Reasons to consider moving from SVN to git are to:

Other OSGeo projects already moved (even if some only partly)

Other relevant projects:

GRASS GIS has already a git-mirror-repository for CI:

In addition GRASS has a (yet unused) team within the OSGeo organisation on github.com:

Possible migration of GRASS GIS source code to git has been discussed at community sprints in 2017 and 2018. At the community Sprint in Bonn 2018 first tools for moving content from trac (SVN) to git were developed (mainly by Martin Landa): ​https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git?order=name

See also: ​https://trac.osgeo.org/grass/ticket/3722

Choosing a git platform

Moving to git involves the question which git platform to move to. So, in addition to technical work, strategical decisions have to be made.

Available options

Most common options / git platforms are:

  • github (still the most popular, yet proprietary, system with online hosting service)
  • gitlab (another platform with online hosting service and increasing popularity esp. after Microsoft acquired github)
  • bitbucket (another popular platform with online hosting service)
  • gitea/gogs ("painlessly selfhosted" platform, hosted by OSGeo SAC)

Yet, there are plenty of other options: ​https://wiki.osgeo.org/wiki/GitHostingSoftware

And there are several comparisons of available git platforms available online:

GitLab compared to other DevOps tools

Risk of "vendor lock in"

See this gitlab-ticket regarding migration from trac to gitlab: ​https://gitlab.com/gitlab-com/support-forum/issues/2765

And see this manual for moving from SVN to gitlab: ​https://docs.gitlab.com/ee/user/project/import/

It seems also possible / relatively straight forward to (e.g. later) move from gitlab.com to a selfhosted gitlab instance: ​https://docs.gitlab.com/ee/user/project/import/gitlab_com.html

Requirements and criteria

Anyway, a first step in order to chose from the available options is to define a list of criteria (here requirements and features) of the git platform to move to. For OSGeo a list of requirements has been compiled: ​https://wiki.osgeo.org/wiki/GitServiceRequirement Yet, that list does not necessarily reflect all or the most important requirements of the GRASS project and the motivation for moving to git...

  • Sign in using OSGeo Userid
  • Autonomously create and manage teams
  • Autonomously create and manage repositories
  • Create private repositories (for software vulnerability testing, etc.)
  • Import tickets from Trac
  • Import tickets from Redmine
  • Comment tickets via email
  • Comment/close tickets via commit log
  • SVN->GIT sync - (Mirroring existing SVN repository) see:/ticket/1654
  • Integration with CI service (hosted eg. Travis-CI, AppVeyor, GitLab CI), self-hosted (e.g. !Buildbot, ?))

Extra link:

Steps done

User Survey

5 Feb 2019:

20 Feb 2019:

git test migration

5 Feb 2019:

  • svn -> git test migration ongoing, see #3722

For the "final" repos, see

PSC vote

Implementation of migration from OSGeo SVN and trac to GitHub

Migration plan (draft)

Two possible scenarios below. Similar procedure will be launched for grass-addons repo.

Scenario 1 (source code + issues in one step)

(whole procedure will take few hours, not more then one working day)

  1. migration of source code and issues will be announced on grass-dev ML few days before day D
  2. svn and trac ticket system (only tickets, wiki will be still editable) will be switched to read-only mode
  3. git grass repo (​https://github.com/grass-svn2git/grass) will be created from scratch and switched to private mode
  4. source code migration will be launched (​https://trac.osgeo.org/grass/browser#grass-addons/tools/svn2git; will take 1-2 hours)
  5. meanwhile migration of trac issue will be launched (target: grass repo; will take few hours)
  6. switch grass repo to public mode
  7. move grass repo under ​Github OSGeo organization

Scenario 2 (two steps)

  1. source code migration
    1. migration of source code will be announced on grass-dev ML few days before day D
    2. svn system will be switched to read-only mode
    3. Git grass repo (​https://github.com/grass-svn2git/grass) will be created from scratch
    4. source code migration will be launched (​https://trac.osgeo.org/grass/browser#grass-addons/tools/svn2git; will take 1-2 hours)
    5. move grass repo under ​Github OSGeo organization
  2. trac ticket migration
    1. migration of issues will be announced on grass-dev ML few days before day D
    2. trac ticket system (only tickets, wiki will be still editable) will be switched to read-only mode
    3. git grass repository under OSGeo organization will be switched to private mode
    4. migration of trac issue will be launched (target: grass repo; will take few hours)
    5. switch grass repo to public mode

Transfer to repo to OSGeo organization within GitHub

One option is to update the existing draft migration (​https://github.com/grass-svn2git/) uner the existing OSGeo organization on GitHub:

Needed source code updates

In various places "svn" is coded and needs to be replaced:

  • configure.in/configure grass.pc Dockerfile
  • include/VERSION g.version/main.c g.version/Makefile g.version/g.version.html
  • INSTALL REQUIREMENTS.html

Migration of trac issues

New labels in the GitHub issue tracker

Migration of trac wiki

Setup of Gitlab mirror

Future plans not being part of initial migration

Backporting bot

Zeonodo based DOIs

  • DOI support through zenodo by connecting repos on GitHub with Zenodo:
    • ​https://guides.github.com/activities/citable-code/
    • According to the Zenodo helpdesk, two options exist to connect the GRASS codebase to the Zenodo archive:
      1. REST-API (of Zenodo) or manual upload into Zenodo
      2. GitHub Integration
      • It is possible to start the process with GitHub Integration and then (for whatever reason) fall back to the REST-API/manual upload.
      • It is NOT possible to start with the REST-API/manual upload and to switch to GitHub Integration later.
      • Zenodo helpdesk on GitHub Integration: If you want to use our GitHub integration, then you must move the source code to GitHub and activate the repository in Zenodo (see the GitHub guide). Afterwards, you make a new release in GitHub for each of your releases (see also the GitHub guide). You have to make the releases in the order you want them to appear in Zenodo. If you have tags push to GitHub, then you can upgrade a tag to a release in the GitHub interface.
      • Zenodo helpdesk on DOI versioning scheme: Zenodo keeps the version number and date in a metadata field that you can change as you see fit even after publishing. By default Zenodo orders the releases in the order we receive them (i.e. by date). This is however only for display purposes, and it is essentially the same way GitHub orders their releases page. In the metadata however, we do not care about ordering (because it's very hard to model the ordering correctly). We simply have a concept DOI that links to all the the specific version DOIs via HasVersion/IsVersionOf relationship.
      • Zenodo helpdesk on mishaps: ...in case you make a mistake, we do have the possibility to reorder the releases manually. Naturally we would like to avoid this, however just rest assured that we can fix it if you make a mistake.

CI/CD and QA

Next release

  • Release of GRASS GIS 8.0.0 (or earlier) from GitHub
Note: See TracWiki for help on using the wiki.