qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: Branches and Merging
Date Mon, 24 Sep 2007 10:58:34 GMT
If you need some help in figuring out svnmerge:

http://www.orcaware.com/svn/wiki/Svnmerge.py

On 24/09/2007, Rupert Smith <rupertlssmith@googlemail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message