Note that there are some explanatory texts on larger screens.

plurals
  1. POCan Subversion properly handle merges in both directions (trunk <-> branch)?
    text
    copied!<p>As far as I understand, the most common (and recommended) way to handle branching &amp; merging in Subversion is:</p> <ul> <li>create branch as a copy of trunk</li> <li>do disruptive development on branch, and regular development on trunk</li> <li>While doing so, regularly merge changes trunk -> branch, to avoid the branch diverging too much. With merge tracking (<code>svn:mergeinfo</code>), I can just run <code>svn merge ^/trunk</code>, and SVN will automatically fetch all unmerged changes from trunk.</li> <li>Once the work on the branch is done, merge everything back (on trunk: <code>svn merge --reintegrate ^/branch/foo</code>), then discard branch.</li> </ul> <p>(described e.g. in the SVN book, chapter <a href="http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html" rel="nofollow">Basic Merging</a>).</p> <p>Now my problem: While this works well for "feature branches", one sometimes also needs "release branches", which represent shipping/about to ship versions.</p> <p>With release branches, in my experience merging has to happen in <em>both</em> directions:</p> <ul> <li>bug fixes from the release branch must be merged into trunk (branch -> trunk)</li> <li>but sometimes a bug fix from trunk (or even a new feature) is deemed critical for a release version (or an update to the release), and must therefore be merged trunk -> branch</li> </ul> <p>I have not found anything firm on how SVN and <code>svn:mergeinfo</code> will handle this. Can I merge in both directions ("bidirectional merge"), and still have svn keep track of merged revisions?</p> <p>Are there any pitfalls? Anything special to pay attention to?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload