| | 147 | === Branches and backports === |
| | 148 | |
| | 149 | ''This section applies to the core developers with access to the main repository (other contributors can safely ignore it).'' |
| | 150 | |
| | 151 | GRASS GIS Subversion repository has trunk and several branches. All the development should happen in trunk (trunk is a "development branch"). All the other branches are usually associated with releases and should contain stable code which is being prepared towards the given release. |
| | 152 | |
| | 153 | When a bug is fixed the fix should be committed to trunk, tested there, and than backported to the release branch or branches. The testing before backport should include user testing, running automated test (if available), and compilation of the whole source tree (ideally after `make distclean`). Note that thinks like testing should be done also before the original commit to trunk. Also note that not all these steps has to be done manually, you can take an advantage of [https://travis-ci.org/GRASS-GIS/ Travis CI] or [http://fatra.cnr.ncsu.edu/grassgistests/ automated runs of the GRASS GIS testing suite]. |
| | 154 | |
| | 155 | Often there is more than one active stable branch, if you are backporting, make sure you always backport to all the branches between trunk and the furthest branch you are backporting to. For example, let's say we have trunk and branches 7.2 and 7.0, if you backport to 7.0, you have to also backport to 7.2. You can also choose to backport only to the closest branch, in our example 7.2. |
| | 156 | |
| | 157 | Backport only complete fixes. When you are not sure if the fix is complete or if there is an possibility that some details such as wording will change, wait with the backport for a little while and backport all the changes together to reduce number of commits which needs to be reviewed (right now or in the future). You can also backport multiple commits from trunk as one commit if you think it is appropriate. |
| | 158 | |
| | 159 | Include the number of the commit (or commits) you are backporting, into the commit message, for example: `less verbose messages (backport r89436)`. This will help matching the file content in between branches and tracking if the commits were backported. |
| | 160 | |
| | 161 | As a developer you should maintain a list of commits which you plan to backport. One way how to do it is to subscribe to the [https://lists.osgeo.org/listinfo/grass-commit grass-commit mailing list] and filter your commits in your email. |
| | 162 | |
| | 163 | Do not add svn merge property to the commit. Review [source:grass-addons/tools tools directory in Addons repository] for scripts which will help you with backporting. |
