On Fri, Nov 09, 2012 at 10:44:57AM +0200, Kiren Pillay wrote:
> "--reintegrate" merge has worked like a charm for us so far, however the
> reason I didn't do a reintegrate merge was that this was our QA branch, so
> if I reintegrated, I would have to delete the QA branch and recreate it,
> since after the merge the QA branch would not allow further commits. (I
> guess this would be safe to do if my merge was done correctly).
This is a slight misconception. You don't *have* to delete a branch
after reintegrating it. The --reintegrate option controls Subversion's
merge behaviour in a way that avoids spurious conflicts due to changes
that were already merged from the reintegrate source (e.g. a branch)
to the reintegrate target (e.g. trunk). Once the reintegrate merge is
done and committed it looks just like any other merge.
> What do you suggest is the best approach for this from your experience?
There is this workaround to avoid deleting the branch, which is documented
in the Subversion book:
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice
I would still recommend using this approach for the time being.
However, in Subversion 1.8, the --reintegrate option is going away so you
will be able to just run 'svn merge' to merge in either direction.
See here for detail:
http://subversion.apache.org/docs/release-notes/1.8.html#auto-mergeo
And here for more (probably too much) detail:
http://wiki.apache.org/subversion/SymmetricMerge
(There is no fixed release date for 1.8 yet, in case you're wondering.
Nobody knows yet, thanks for asking :)
Received on 2012-11-09 13:40:46 CET