notes/merge-tracking/summit.html - subversion - Git at Google

 <!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>
	<!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 #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>