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 :)
