svn commit: r1329635 - /subversion/trunk/notes/merge-tracking/func-spec.html

[ju...@apache.org]

Author: julianfoad
Date: Tue Apr 24 10:50:23 2012
New Revision: 1329635

URL: http://svn.apache.org/viewvc?rev=1329635&view=rev
Log:
* notes/merge-tracking/func-spec.html
  (switched-paths): Add subsections on the behaviour of deleting a switched
    subtree, and on the rationale, following the email thread "Symmetric
    Merge -- switched subtrees [was:...]", 2012-04-20,
    <http://svn.haxx.se/dev/archive-2012-04/0399.shtml>.

Modified:
    subversion/trunk/notes/merge-tracking/func-spec.html

Modified: subversion/trunk/notes/merge-tracking/func-spec.html
URL: http://svn.apache.org/viewvc/subversion/trunk/notes/merge-tracking/func-spec.html?rev=1329635&r1=1329634&r2=1329635&view=diff
==============================================================================
--- subversion/trunk/notes/merge-tracking/func-spec.html (original)
+++ subversion/trunk/notes/merge-tracking/func-spec.html Tue Apr 24 10:50:23 2012
@@ -239,6 +239,50 @@ SSRP - Switched subtree's repository par
 
 </ul>
 
+<h3>Delete</h3>
+
+<p><a href="http://subversion.tigris.org/issues/show_bug.cgi?id=4163"
+  >Issue #4163 "merged deletion of switched subtrees records non-inheritable
+  mergeinfo"</a>: If a merge deletes the path SS, the desired behaviour
+  is currently undefined and the actual behaviour is that a commit will
+  delete <strong>both</strong> SS (from SSRP) and SS@BASE (from SSP).</p>
+
+<h3>Rationale</h3>
+
+<p>Why does merging work this way with switched subtrees?</p>
+
+<p>If a subtree (SS) is switched, that means the user has chosen for
+  the time being to work with a substitute for the original subtree
+  (SS@BASE), knowing that any modifications made in SS can be
+  committed only to the repository location of SS and the original
+  subtree SS@BASE remains hidden and unaffected.</p>
+
+<p>The general semantics of a merge is to apply local modifications
+  to the working copy and record the merge as having been applied
+  to the tree that is represented by the working copy.</p>
+
+<p>Merge tracking should ensure that the subtree of the merge that
+  goes into SS is recorded as being applied to SS, while the
+  subtree SS@BASE should be recorded as not having received that
+  merge.</p>
+
+<p>Since the working copy represents parts of two different branches,
+  two parts of the merge are thus applied to the two different
+  branches, and recorded as such when the user commits the result.</p>
+
+<p>If the user is doing a merge that may affect SS, it is reasonable
+  to assume that SS is an alternative variant of SS@BASE rather than
+  some totally unrelated item.  So, in terms of Subversion's loose
+  branching semantics, SS is a 'branch' of SS@BASE.  If the user
+  chooses to merge when the assumption is false and SS doesn't have
+  a sensible branching relationship with SS@BASE, the result will be
+  nonsensical or, in concrete terms, there will be merge conflicts.</p>
+
+<p>Note:  Many typical branching policies would forbid committing to
+  two branches at once, let alone committing merges to two branches
+  at once.  However, the user may have reasons for doing this merge
+  without intending to commit the result as-is.</p>
+
 </div>  <!-- switched-paths -->
 
 <div class="h2" id="prop-change">