History

In this page I (Tim Sutton) will try to collate reasons why it would be good to move to GIT and leave SVN behind.

A rationale for git

It would be pointless to try to replicate the entire 'git versus svn' debate here - there are many articles on the internet that cover just this topic. Here is one of the nicer ones:

http://whygitisbetterthanx.com/#

If you expand all sections you are presented with a nice overview of the git debate.

Lets rather bring the discussion into the context of QGIS:

  • QGIS development model is to have a few 'annointed' developers who have svn access and everyone else submits patches and hopes one of the annointed will evaluate and submit that patch.
  • Further, we promote the use of branches in svn to do any invasive development work, and then to merge that when it is stabilised.
  • We use trac as a tool to allow us to manage the development process to some extent and to allow interactive browsing of the source code.

Problems with our model start to arise when:

  • Developers who are not SVN committers want to manage their changes under a version control system so as to provide proper historization and code management while they are working. This can be done via git-svn but that git-svn repository is difficult to share and synchronise if it is a team of developers (non QGIS committers) all wanting to work against the same upstream QGIS cloned repository.
  • Patches need to be tested by a wide audience but not neccessarily incorporated into the master repository yet.
  • Branches have existed for a long time - the merge process under svn is cumbersome.
  • Poorly known developers need to be given access to the master repository even though we are 'not sure about them' yet.
  • Issue management needs to be carried out in parallel with issues for other sub projects - trac is inadequate for this.

GIT supports a number of development models. The one I favour is one where:

  • We have a central master repository with only a handful of committers having write access to it.
  • Maintainers of specific areas of the code base e.g. gui, providers, bindings etc. maintain their own forked repositories e.g. on github. They accept changes from other developers either as patches or merging in changes from other remote repositories.
  • Organisations and private individuals maintain their own repositories and allow their collaborators to push to it. If they have something they want to share with the greater project, they obtain push permissions to an upstream repository or submit a patch.
  • The PSC integrate 'best of breed' features from downstream projects into master in the build up to a release.

Why not use GIT svn?

Using_Git already provides a nice solution for using git-svn as a bridge to bring the best of both worlds. Or is it?

There are a number of problems with git-svn:

  • It is difficult to implement a distributed version control model as described above.
  • SVN does not accommodate a good system for crediting downstream developers for their work - commits always come through in the name of the person who actually commits them.
  • The biggest problem for me (TS) is that because of SVN's incremental versioning, there is no unified reference to a revision for any two git-svn clones. That means if for example in my git-svn clone of QGIS I want to track a second remote repository (for example a fork with personal work) its pretty much impossible. Take for example the following scenario:
 * Clone qgis repo using git-svn
 * Add a git remote reference to my github fork of the official qgis git repo
 * Try to fetch or pull that fork:
 * [qgis] git pull qgis-github-timlinux warning: no common commits remote: Counting objects: 91751, done.
 * Basically the biggest benifit of GIT is lost - universal commit id's allowing you to mix and match source from different repos.
  • more reasons to come...