If you need some help in figuring out svnmerge: http://www.orcaware.com/svn/wiki/Svnmerge.py
On 24/09/2007, Rupert Smith <[EMAIL PROTECTED]> wrote: > > 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.txt file 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 >
