|
|
Home | Docs | Issue Tracker | FAQ | Download |
|
|
| Date: | 2012-03-23 |
|---|---|
| Author: | Thomas Bonfort |
| Contact: | tbonfort at terriscope dot fr |
| Last Edited: | $Date$ |
| Status: | Draft |
| Version: | MapServer 6.2 |
| Id: | $Id$ |
While SVN suits our needs as a collaborative source code versionner, it has shortcomings that make it difficult to work with for developpers working on multiple tasks in parallel. Git’s easy branching makes it possible to set up branches for individual task, isolating code changes from other branches, thus making the switch from one task to another possible without the risk of loosing or erroneously commiting work-in-progress code. Three-way merging of different branches means that merging code from one branch to another becomes a rapid task, by only having to deal with actual conflicts in the code. Offline committing and access to entire history make working offline possible.
There is already somewhat of a consensus that the migration from SVN to git is a good move. Discussion remains as to how this transition should be performed. This RFC outlines the different options available for hosting the official repository, and the different options available for our ticket tracking.
Current investigation has retained two majors options that we could go down with:
This option consists in moving our entire code+ticket infrastructure to github. The current trac instance becomes nearly read-only, new tickets cannot be created on it. Existing tickets are migrated to github with a script taking a trac postgresql dump (once the migration starts, our trac instance becomes read-only).
- No need to worry about hosting infrastructure
- Can be up and running in a short delay
- Support for pull requests, allowing external contributions to be rapidly merged into our repository
- Online code editing for quick fixups
- Github visualization tools, for example to check which branches are likely to contain conflicting code sections
- Code and patch commenting make collaboratively working on a given feature very lightweight, i.e. just at your comment on the code line which seems problematic to you
- Documentation contributions highly simplified for one-shot contributions.
- Integration of ticket state with commit messages (e.g: “fix mem allocation in mapDraw(), closes issue #1234
- Email replies to ticket notifications
- The free-form label tagging of issues might open up some interesting usages
- Versionned text-base attachments (gists), with commenting
- No way to automatically assign a ticket owner given a component
- No support for image attachments, can be referenced by url but must be hosted elsewhere.
- No support for private security tickets
This document outlines a workflow for fixing bugs in our stable branches: http://www.net-snmp.org/wiki/index.php/Git_Workflow I beleive it is a very good match for our stable release management: - pick the oldest branch where the fix should be applied - commit the fix to this oldest branch - merge the old branch down to all the more recent ones, including master
Instead of freezing development during our beta cycle, a new release branch is created once the feature freeze is decided, and our betas, release and subsequent bugfix releases are tagged off of this branch. Bug fixes are committed to this new stable branch, and merged into master. New features can continue to be added to master during all the beta phase. http://nvie.com/posts/a-successful-git-branching-model/ is an interesting read even if it does not fit our stable release branches exactly.
For those users who do not wish to change their workflow and continue with SVN commands. This is not the recommended way to work with git, as local or remote changes might end up in having conflicts to resolve, like with svn.
+1 from ThomasB ,MikeS, UmbertoN, HowardB, SteveW, DanielM, SteveL, TamasS, JeffM, AssefaY, TomK, PerryN
-0 from OlivierC