<commit_before><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<style type="text/css"> /* <![CDATA[ */
  @import "../branding/css/tigris.css";
  @import "../branding/css/inst.css";
  /* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
  href="../branding/css/print.css"/>
<script type="text/javascript" src="../branding/scripts/tigris.js"></script>
<title>Merge Tracking Functional Specification</title>
</head>

<body>
<div class="h1">
<h1>Merge Tracking Functional Specification</h1>

<p><a href="index.html">Merge tracking</a> functional specification.
Describes Subversion 1.5.0, except where noted as
<i>unimplemented</i>.  This is a living specification, which will
change as features are added or refined.</p>

<div class="h2" id="merge">
<h2>Merge operations</h2>

<p>Merge operations involving a single source URL (e.g. <code>svn
merge -cN URL</code>) allow the revision range and source URL
parameters to be optional.  The revision range defaults to "all
unmerged revisions", while the source URL is inferred using a
combination of merge info and copy history.  When a revision range is
not provided, merge operations are not able to "revert" changes
(e.g. a la <code>svn merge -c -7 URL</code>).</p>

<p>See the <a href="#repeated-merge">repeated merge</a> section below
for discussion of various merge algorithms, and details on the merge
algorithm used.</p>

<p>Merge info is <em>not taken into consideration for three-way
merges</em>, merge operations which do not specify identical "from"
and "to" URLs (e.g. <code>svn merge FROM_URL@REV1 TO_URL@REV2</code>).
In the future, Subversion will likely support this, but currently
lacks sufficient history and merge info between the repository and
client to perform this operation in a reasonable manner.  The primary
use case this will impact is vendor branches.</p>

</div>  <!-- merge -->

<div class="h2" id="diff-status">
<h2>Diff/Status operations</h2>

<p>Output is shown the same as pre-Merge Tracking, except for:</p>

<ul>
  <li>Diffs pretty-print changes to merge info in an easily
    human-readable form.</li>

  <li>Diffs sometimes report spurious property changes from merge info
    (bug?).</li>

  <li>Status represents changes to the merge info for the root of a
    tree as a property change.</li>
</ul>

</div>  <!-- diff-status -->


<div class="h2" id="copy-move">
<h2>Copy/Move operations</h2>

<p>Copy and move operations handle two types of merge info:</p>

<dl>
  <dt>Explicit</dt>
  <dd>The pre-existing value of the <code>svn:mergeinfo</code>
    property on the source path.</dd>

  <dt>Implicit</dt>
  <dd>All revisions represented by the object at the source path (from
    its "appeared in" revision to its current revision).</dd>
</dl>

<div class="h3" id="ra-copy-move">
<h3>Repository Access operation</h3>

<p>Copy/move operations which contact the repository include:</p>

<ul>
  <li>WC to URL</li>
  <li>URL to WC</li>
  <li>URL to URL</li>
</ul>

<p>These operations always propogate both explicit and implicit merge
info.  Other than the inclusion of merge info, operation is
effectively the same as pre-Merge Tracking.</p>

</div>  <!-- ra-copy-move -->

<div class="h3" id="wc-wc-copy-move">
<h3>Working Copy to Working Copy operation</h3>

<p>Pre-Merge Tracking, WC to WC operations occurred offline (e.g. with
no repository access).  This is a typical behavior of refactoring
tools (e.g. IDEs like Eclipse), and is very useful when offline
(e.g. on an airplane or subway, or at a cafe).</p>

<p>However, to propogate merge info during copy/move operations,
access to both a path's comprehensive merge info and its history is
necessary.  To preserve offline operation, the Merge Tracking
implementation supports two modes:</p>

<ul>
  <li>A compatibility mode, which neither contacts the repository, nor
    does any merge info propogation (unless a copy source's merge info
    has been locally modified, in which its value is propogated the as
    any Subversion revision property).</li>

  <li>A mode which requires repository access (e.g. isn't offline),
    but which propogates all merge info from source path to
    destination (<i>unimplemented</i>, start with copy test #31).</li>
</ul>

<p>This behavior is comparable to the difference between <code>svn
status</code> and <code>svn status -u</code>.</p>

<p>While some state indicating delayed merge info retrieval and
handling could instead be stored in WC to preserve offline operation,
there are complications with this when subsequent uncommited revert
operations should change the merge info (we'd have to store negative
merge info in the WC).</p>

</div>  <!-- wc-wc-copy-move -->

</div>  <!-- copy-move -->

<div class="h2" id="switched-paths">
<h2>Switched Paths</h2>

<p>Switched paths are treated as the root of the working copy regarding
merge info inheritance and elision, specifically:</p>

<ul>
 <li>Merge rev N to switched PATH which has no explicit merge info: PATH
   does not inherit merge info from its working copy ancestors.  PATH gets
   merge info for rev N plus any inherited mergeinfo from the repository.</li>

 <li>Merge rev N to PATH with switched CHILD with no explicit merge info:
   CHILD does not inherit merge info from its working copy ancestors.  CHILD
   gets merge info for rev N plus any inherited mergeinfo from the repository.
   </li>

 <li>Elision: Merge info on switched paths never elides.</li>

 <li>Switch PATH which has <em>committed</em> merge info or switch PATH which
   has a CHILD with <em>committed</em> mergeinfo: PATH's / CHILD's mergeinfo
   is <em>replaced</em> by the explicit mergeinfo from the repository.</li>

 <li>Switch PATH which has <em>local</em> merge info or switch PATH which has
   a CHILD with <em>local</em> mergeinfo: PATH's / CHILDS's local mergeinfo<commit_msg>* www/merge-tracking/func-spec.html   (switched-paths): Note that merge to target with switched child is   unimplemented.<commit_after><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<style type="text/css"> /* <![CDATA[ */
  @import "../branding/css/tigris.css";
  @import "../branding/css/inst.css";
  /* ]]> */</style>
<link rel="stylesheet" type="text/css" media="print"
  href="../branding/css/print.css"/>
<script type="text/javascript" src="../branding/scripts/tigris.js"></script>
<title>Merge Tracking Functional Specification</title>
</head>

<body>
<div class="h1">
<h1>Merge Tracking Functional Specification</h1>

<p><a href="index.html">Merge tracking</a> functional specification.
Describes Subversion 1.5.0, except where noted as
<i>unimplemented</i>.  This is a living specification, which will
change as features are added or refined.</p>

<div class="h2" id="merge">
<h2>Merge operations</h2>

<p>Merge operations involving a single source URL (e.g. <code>svn
merge -cN URL</code>) allow the revision range and source URL
parameters to be optional.  The revision range defaults to "all
unmerged revisions", while the source URL is inferred using a
combination of merge info and copy history.  When a revision range is
not provided, merge operations are not able to "revert" changes
(e.g. a la <code>svn merge -c -7 URL</code>).</p>

<p>See the <a href="#repeated-merge">repeated merge</a> section below
for discussion of various merge algorithms, and details on the merge
algorithm used.</p>

<p>Merge info is <em>not taken into consideration for three-way
merges</em>, merge operations which do not specify identical "from"
and "to" URLs (e.g. <code>svn merge FROM_URL@REV1 TO_URL@REV2</code>).
In the future, Subversion will likely support this, but currently
lacks sufficient history and merge info between the repository and
client to perform this operation in a reasonable manner.  The primary
use case this will impact is vendor branches.</p>

</div>  <!-- merge -->

<div class="h2" id="diff-status">
<h2>Diff/Status operations</h2>

<p>Output is shown the same as pre-Merge Tracking, except for:</p>

<ul>
  <li>Diffs pretty-print changes to merge info in an easily
    human-readable form.</li>

  <li>Diffs sometimes report spurious property changes from merge info
    (bug?).</li>

  <li>Status represents changes to the merge info for the root of a
    tree as a property change.</li>
</ul>

</div>  <!-- diff-status -->


<div class="h2" id="copy-move">
<h2>Copy/Move operations</h2>

<p>Copy and move operations handle two types of merge info:</p>

<dl>
  <dt>Explicit</dt>
  <dd>The pre-existing value of the <code>svn:mergeinfo</code>
    property on the source path.</dd>

  <dt>Implicit</dt>
  <dd>All revisions represented by the object at the source path (from
    its "appeared in" revision to its current revision).</dd>
</dl>

<div class="h3" id="ra-copy-move">
<h3>Repository Access operation</h3>

<p>Copy/move operations which contact the repository include:</p>

<ul>
  <li>WC to URL</li>
  <li>URL to WC</li>
  <li>URL to URL</li>
</ul>

<p>These operations always propogate both explicit and implicit merge
info.  Other than the inclusion of merge info, operation is
effectively the same as pre-Merge Tracking.</p>

</div>  <!-- ra-copy-move -->

<div class="h3" id="wc-wc-copy-move">
<h3>Working Copy to Working Copy operation</h3>

<p>Pre-Merge Tracking, WC to WC operations occurred offline (e.g. with
no repository access).  This is a typical behavior of refactoring
tools (e.g. IDEs like Eclipse), and is very useful when offline
(e.g. on an airplane or subway, or at a cafe).</p>

<p>However, to propogate merge info during copy/move operations,
access to both a path's comprehensive merge info and its history is
necessary.  To preserve offline operation, the Merge Tracking
implementation supports two modes:</p>

<ul>
  <li>A compatibility mode, which neither contacts the repository, nor
    does any merge info propogation (unless a copy source's merge info
    has been locally modified, in which its value is propogated the as
    any Subversion revision property).</li>

  <li>A mode which requires repository access (e.g. isn't offline),
    but which propogates all merge info from source path to
    destination (<i>unimplemented</i>, start with copy test #31).</li>
</ul>

<p>This behavior is comparable to the difference between <code>svn
status</code> and <code>svn status -u</code>.</p>

<p>While some state indicating delayed merge info retrieval and
handling could instead be stored in WC to preserve offline operation,
there are complications with this when subsequent uncommited revert
operations should change the merge info (we'd have to store negative
merge info in the WC).</p>

</div>  <!-- wc-wc-copy-move -->

</div>  <!-- copy-move -->

<div class="h2" id="switched-paths">
<h2>Switched Paths</h2>

<p>Switched paths are treated as the root of the working copy regarding
merge info inheritance and elision, specifically:</p>

<ul>
 <li>Merge rev N to switched PATH which has no explicit merge info: PATH
   does not inherit merge info from its working copy ancestors.  PATH gets
   merge info for rev N plus any inherited mergeinfo from the repository.</li>

 <li>Merge rev N to PATH with switched CHILD with no explicit merge info:
   CHILD does not inherit merge info from its working copy ancestors.  CHILD
   gets merge info for rev N plus any inherited mergeinfo from the
   repository (<I>unimplemented</I>).
   </li>

 <li>Elision: Merge info on switched paths never elides.</li>

 <li>Switch PATH which has <em>committed</em> merge info or switch PATH which
   has a CHILD with <em>committed</em> mergeinfo: PATH's / CHILD's mergeinfo
   is <em>replaced</em> by the explicit mergeinfo from the repository.</li>

 <li>Switch PATH which has <em>local</em> merge info or switch PATH which has
   a CHILD with <em>local</em> mergeinfo: PATH's / CHILDS's local mergeinfo
{'fraction_non_alphanumeric': 0.11666666666666667, 'fraction_numerical': 0.006666666666666667, 'mean_word_length': 4.1929900475984425, 'pattern_counts': {'":': 0, '<': 293, '<?xml version=': 0, '>': 293, 'https://': 0, 'lorem ipsum': 0, 'www.': 5, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2471257', 'n_tokens_mistral': 3765, 'n_tokens_neox': 3591, 'n_words': 1514}