PMC proposals/Move apertium to github

Summary

git provides a large number of advantages over subversion, including a very good branching mechanism, offline commit history, a bisection tool for locating broken commits, and excellent merge/rebase capabilities. Making use of a service such as github would also allow for each apertium module to be in a separate repository, with the possibility for creating central repositories (such as incubator) which link to all of the included modules. github also provides an issue tracker and a system for making commits in a personal fork of the upstream repository, then requesting that your changes be pulled into upstream. Note that apertium can retain its current method of allowing people to commit directly, but retain the option of using pull requests for those who don't plan to contribute regularly. Sourceforge could be retained for mailing lists and similar services.

Migration from subversion to git should be relatively simple. Tools exist for creating git repositories from subversion while retaining all commit history. The migration should begin with smaller apertium modules, such as the contents of nursery and incubator. The more central modules, such as lttoolbox and apertium itself, can be moved last. Documentation can be updated, but a simple guide similar to https://wiki.gnome.org/TranslationProject/GitHowTo should be sufficient. Much of the information contained therein is probably not necessary for apertium workflow, making for a simpler, easier-to-write document. For more complex requirements, the existing git documentation is excellent and there are many resources for a variety of git recipes.

Proposed by: User:Leftmostcat

Related reading

• Github Organizations: https://help.github.com/categories/2/articles
• GH Org Teams: https://help.github.com/articles/how-do-i-set-up-a-team
• Example of similar structure: https://github.com/metabrainz

Caveats

• The svn repo contains several larger binaries and their history. The total sum of those would need to be cloned for every person who intends to seriously work with the subproject. A shallow clone (equivalent to svn checkout) can only be used for basic patchwork (cannot clone, fetch, push into, or push from shallow clones). See https://git.wiki.kernel.org/index.php/GitFaq#How_do_I_do_a_quick_clone_without_history_revisions.3F and following point. Tino Didriksen 16:56, 6 September 2013 (UTC)