At the present time, it is useful to think of M2 as a release branch nearing the end of its life cycle. Apply patches to M2.1 to try them out and selectively merge onto M2, once you are happy with them. Of course, as M2 becomes a historical branch, we may apply patches to it that we discover post-M2, that we want to merge back into either trunk or M2.1, so merge tracking has now been turned on in that direction too.
At the moment we have: Dev branches: trunk branches/M2.1 Release branches: branches/M2 Easiest approach, when doing non-trunk work, is to work on M2.1, and merge onto trunk. Selectively merge onto M2, if it is a patch needed for the M2 release. It is extremely helpful when committing a patch, to ensure that an Apache JIRA exists for the patch, and to put the number in the logs. Like this: QPID-123 Fixed the annoying bug... Then merge it accorss with svnmerge, and use the svnmerge-commit-message.txtfile that it generates as the commit log for the merge. This file contains both the logs, and consequently the QPID-XXX numbers, as well as the actual merged revision numbers. Mostly, people have done it liek this, but there are a couple of cases where patches have been applied manually, with no JIRA and under different log messages on different branches. It would also assist matters, if people took note of these things, and did their own merging, immediately upon submitting patches. I do not like back-logs of un-merged patches because it is a real headache to figure out. What happens when we do a release and we are not sure which JIRAs have been fixed in which branch? What happens when you apply a patch to a release branch, which is a valuable code fix, but fail to merge it back into a development branch, so that the bug re-emerges in a future release? Rupert
