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