Working with Branches adds a new level of complexity concerning code modifications. Code modifications are linked to new features, bug corrections and the potential reports. All these code modification are logically managed by the bug tracking system.

The following explanations are theoretical. Sometimes these rules will be broken.

• An evolution is always developed in trunk. Needs no report on stable branches.
• Where to correct a bug is a more complex question.
  1. If the bug is blocking, it must be corrected on the stable branch and reported on trunk.
  2. Not depending on its severity, if the bug correction requires few code modification, it can be corrected on the stable branch and reported on trunk.
  3. Else, the bug is corrected on trunk, thus it will be corrected on next stable branch.

Correcting the bug on trunk and then reporting the correction on the stable branch will work easily near the fork, in time. But far from the fork day, the correction might need manual modifications. In Pierrick's opinion, correcting on the stable branch and reporting on trunk is a better solution. In Gweltas's opinion, a bug must first be corrected on trunk and then possibly reported on the stable branch, thus avoiding regression. Deciding whether a bug should be corrected on stable branch and trunk or only on trunk is a matter of subjectivity, obviously. Same remark for answering the question ”where must the bug be corrected first?”

In the bug tracker, status ”resolved” means corrected and status ”closed” means reported on trunk.

# report a correction from trunk to 1.5
$ cd 1.5
$ svn merge -c931 http://piwigo.org/trunk
$ svn status # get informations
$ svn diff   # more detailed informations
$ svn commit -m "merge -c931 from trunk to branch 1.5 [...]"

# report a correction from 1.5 to trunk
$ cd trunk
$ svn merge -c946 http://piwigo.org/branches/1.5 .
$ svn status
$ svn diff
$ svn commit -m "merge -c946 from branch 1.5 to trunk [...]"