<!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>
<title>CollabNet Merge Tracking Summit</title>
</head>

<body>
<div class="h2">
<h2>CollabNet Merge Tracking Summit</h2>

<p>On Tuesday, January 17th, 2006, CollabNet held a merge tracking
summit for some of their Subversion-using customers to solicit use
cases and requirements for the enterprise.  The results are below; see
also the pre-summit <a href="summit-survey.html">survey questionnaire
and responses</a>.</p>

<p>(Note that this material is still being integrated with the rest of
the stuff in the Subversion <a href="./">merge-tracking area</a>.)</p>

<div class="h3" id="results">
<h3>Summit Results</h3>

<!-- TODO: Incorporate feedback from rooneg, cmpilato, and djames.
Better organize and flesh out content. -->

<div class="h4" id="summary">
<h4>Summary</h4>

<p>Enterprise users have branches which last longer than a typical
open source project (e.g. more than a decade).  They tend to do merges
more often, involving more files.  They may have dedicated staff and
tool suites for performing merges and answering inquires about merges.
Fundamentally, however, these are differences of scale, not kind.
There were no real surprises in terms of functional requirements: it
appears that enterprise users' needs are of the same nature as the
needs of open source communities, individuals, and small- to
medium-sized shops.  Enterprise users also have a greater need for
auditability/traceability, largely due to compliance requirements
(e.g. FDA, Sarbanes Oxley, etc.).  Based on the notes below and
elsewhere in the <a href="./">merge-tracking area</a>, it does not
appear that this would change what meta-data gets recorded, but it
does imply more sophisticated data-mining and reporting features than
the average user needs.</p>

</div>  <!-- summary -->

<div class="h4" id="details">
<h4>Details</h4>

<ul>
  <li><p>Even basic "merge memory" would be incredibly helpful in
  shops where minimal, inconsistent process prevails.  Users are often
  very average developers/maintenance programmers.</p></li>

  <li><p>Very long-lived branches (e.g. 10+ years) containing very large
  binaries, tons of merges between them, and subject to duplicate bug
  reports should be handled.</p></li>

  <li><p>The ability to manually adjust any merge meta data is crucial.
  For instance, someone may hand-edit one or more resources to achieve
  the same result as a merge, or hand-edit the result of a merge in a
  way which significantly alters the change.  Either way, one might
  still want to represent that the change does still exist in the
  target line.  In general, humans who claim that they know better
  than the tool should be trusted.</p></li>

  <li><p>The question "What branches contain this exact version of file
  X?" is important.  (In Subversion, that would be "What paths contain
  this exact version of X?")  This may imply exposing some sort of
  unique object identifier, more than we offer so far.  This desire
  was also noted at the
  <a
  href="http://svn.apache.org/repos/asf/subversion/trunk/notes/EuroOSCON-2005-vc-bof.txt"
  >EuroOSCON 2005 Version Control BOF session</a>, search for
  "What branches/tags is this version of this file present in?".</p></li>

  <li><p>Same as above, but for changes: "What branches include change
  C?"</p></li>

  <li><p>The ability to push a given change out to multiple branches.
  Selection mechanisms for destinations should be sophisticated.  For
  example, select all branches that have a common ancestor with the
  source branch of the change, all branches except an exclusion set,
  all branches matching a regular expression, etc.  The medical
  systems manufacturer does this type of operation daily.</p>

  <p>The exact same desire was expressed at the
  <a
  href="http://svn.apache.org/repos/asf/subversion/trunk/notes/EuroOSCON-2005-vc-bof.txt"
  >EuroOSCON 2005 Version Control BOF session</a>, see the item
  containing the string "find my descendants" in that document.</p></li>

  <li><p>Surprisingly, <code>svn blame</code> improvements were not a high
  priority.  The current output (which presumably would show the
  revision in which a merge took place, rather than the original
  source revision), was deemed generally okay.  Possibly, revisions
  which are marked as merges should be displayed as such, so that the
  user knows to drill down further.</p></li>

  <li><p><code>svn log</code> on a merged revision should be able to
  automatically provide both who made the original change and who
  performed the merge.</p></li>

  <li><p>A portable, human-readable change format for review would be
  useful.  Programmatic parsability was not a high priority,
  however.  An extended patch program was not considered crucial.  The
  desire for a "Smart patch format" was also noted at the <a
  href="http://svn.apache.org/repos/asf/subversion/trunk/notes/EuroOSCON-2005-vc-bof.txt"
  >EuroOSCON 2005 Version Control BOF session</a>.</p></li>

  <li><p>Visual interfaces to branch/merge management are <em>very</em>
  useful.  Such a tool could graphically show which branch/revision
  have been merged where, and the ancestry of a branch.  <a
  href="http://www.araxis.com/merge/index.html">Araxis Merge</a> was
  cited as an excellent example of a tool providing the merge
  managment portion of this type of UI.  The need for GUI interfaces
  to branch topology was also discussed at the <a
  href="http://svn.apache.org/repos/asf/subversion/trunk/notes/EuroOSCON-2005-vc-bof.txt"
  >EuroOSCON 2005 Version Control BOF session</a>, search for
  "display topology".  TODO: Follow-up sessions via WebEx will add
  more detail here.</p></li>

  <li><p>The ability to do foreign branch is very good (for similar
  reasons to those in the open source world -- many commercial
  organizations are adopting open source-style practices
  internally).</p></li>

  <li><p>Partial change merging: The merge meta data itself should be
  atomic.  We record that you either applied a whole change, or
  not.  Of course, hand edits and the log message may tell a more
  detailed story.</p></li>

  <li><p>Edited merges should be disentanglable and viewable as separate
  pieces, i.e. [merge] + [edits].  However, this was a nice-to-have
  than a must-have.</p></li>

  <li><p>An option to merging to say "If anything conflicted, then show
  all merged regions in a conflicted style, even those which did not
  conflict."</p></li>

  <li><p>TortoiseSVN merge is apparently good (it has the Araxis
  Merge-style "take my version or their version"), but needs a
  built-in text editor for more involved conflict resolution.</p></li>

  <li><p>Format-specific merge tools is an important need.</p></li>

  <li><p>The ability to automate merges (e.g. from a stable branch to a
  development branch), including interfaces for resolving conflicts
  and handling other errors, is important.  Customers who do
  multi-thousand file merges stress this.</p></li>

  <li><p>Questions users want to ask: "Is this version of foo.c the
  'latest' version?  Are there changes out there which are applicable
  to foo.c, that have not been applied?  What are they?"</p></li>

  <li><p>Any action that can be done to a tag/branch (e.g. merge a
  change, remove a change, etc.) should be hook-protected.  Merging
  itself should be a first-class hook operation (e.g. commit,
  revprop-change, etc.)</p></li>

  <li><p>The ability to "shadow" versioned resources: Make a branch, but
  have most of the branch follow the original source, while only a few
  files are selected for branch development (e.g. "unshadowed").  Is
  this different from systems which allow you to branch individual
  resources in the first place?  Can this be achieved with a
  finer-grained <code>svn switch</code>?  Note: This is related to the
  shared file storage issue in Subversion's own issue tracker,
  <a href="https://issues.apache.org/jira/browse/SVN-2286"
      >issue&nbsp;#2286</a>.  It was also expressed at the
  <a
  href="http://svn.apache.org/repos/asf/subversion/trunk/notes/EuroOSCON-2005-vc-bof.txt"
  >EuroOSCON 2005 Version Control BOF session</a>, search for "The
  One-File-In-Many-Branches Problem" there, which discusses
  how p4 and ClearCase do this.</p></li>

  <li><p>Roll-back should be convenient, and should be recorded as a
  subtraction event, visible as such in the meta data.  Roll-back was
  common at a few shops, and more rare at others.</p></li>

  <li><p>Asking change C to where it has been ported was not a strong
  need (e.g. reporting).</p></li>

  <li id="distributable-resolution"><p>One group
  (the <a href="summit-survey.html#financial-information" >financial
  information company</a>) wanted merge resolution to be distributable
  across the developer team, rather than limited to one person's
  working copy.  The same group said they do most of their merging in
  GUIs, and that the merge process saves reports (when they use the
  commandline tools, they save the logfiles similarly).  The longest
  they've looked back is a few weeks, though.</p></li>

  <li id="merge-previews"><p>The <a
  href="summit-survey.html#financial-information" >financial
  information company</a> also stressed the importance of merge
  previews, dry runs that would allow them to see conflicts and
  "non-trivial, non-conflicting" (NTNC) changes in advance.  These
  previews should be exportable and parseable, so they can be passed
  around to others.</p></li>

</ul>

</div>  <!-- details -->

</div>  <!-- results -->

</div>  <!-- h2 -->
</body>
</html>