| blob | 703f154709f18f9a3eaa9b23e414eb9d00138189 |
4 <head>
13 </head>
15 <body>
20 summit for some of their Subversion-using customers to solicit use
21 cases and requirements for the enterprise. The results are below; see
25 <p>(Note that this material is still being integrated with the rest of
31 <!-- TODO: Incorporate feedback from rooneg, cmpilato, and djames.
32 Better organize and flesh out content. -->
37 <p>Enterprise users have branches which last longer than a typical
38 open source project (e.g. more than a decade). They tend to do merges
39 more often, involving more files. They may have dedicated staff and
40 tool suites for performing merges and answering inquires about merges.
41 Fundamentally, however, these are differences of scale, not kind.
42 There were no real surprises in terms of functional requirements: it
43 appears that enterprise users' needs are of the same nature as the
44 needs of open source communities, individuals, and small- to
45 medium-sized shops. Enterprise users also have a greater need for
46 auditability/traceability, largely due to compliance requirements
47 (e.g. FDA, Sarbanes Oxley, etc.). Based on the notes below and
49 appear that this would change what meta-data gets recorded, but it
50 does imply more sophisticated data-mining and reporting features than
51 the average user needs.</p>
58 <ul>
60 shops where minimal, inconsistent process prevails. Users are often
61 very average developers/maintenance programmers.</p></li>
64 binaries, tons of merges between them, and subject to duplicate bug
65 reports should be handled.</p></li>
67 <li><p>The ability to manually adjust any merge meta data is crucial.
68 For instance, someone may hand-edit one or more resources to achieve
69 the same result as a merge, or hand-edit the result of a merge in a
70 way which significantly alters the change. Either way, one might
71 still want to represent that the change does still exist in the
72 target line. In general, humans who claim that they know better
73 than the tool should be trusted.</p></li>
77 this exact version of X?") This may imply exposing some sort of
78 unique object identifier, more than we offer so far. This desire
79 was also noted at the
80 <a
88 <li><p>The ability to push a given change out to multiple branches.
89 Selection mechanisms for destinations should be sophisticated. For
90 example, select all branches that have a common ancestor with the
91 source branch of the change, all branches except an exclusion set,
92 all branches matching a regular expression, etc. The medical
93 systems manufacturer does this type of operation daily.</p>
95 <p>The exact same desire was expressed at the
96 <a
102 priority. The current output (which presumably would show the
103 revision in which a merge took place, rather than the original
104 source revision), was deemed generally okay. Possibly, revisions
105 which are marked as merges should be displayed as such, so that the
106 user knows to drill down further.</p></li>
109 automatically provide both who made the original change and who
110 performed the merge.</p></li>
112 <li><p>A portable, human-readable change format for review would be
113 useful. Programmatic parsability was not a high priority,
114 however. An extended patch program was not considered crucial. The
120 useful. Such a tool could graphically show which branch/revision
121 have been merged where, and the ancestry of a branch. <a
123 cited as an excellent example of a tool providing the merge
124 managment portion of this type of UI. The need for GUI interfaces
125 to branch topology was also discussed at the <a
128 "display topology". TODO: Follow-up sessions via WebEx will add
129 more detail here.</p></li>
131 <li><p>The ability to do foreign branch is very good (for similar
132 reasons to those in the open source world -- many commercial
133 organizations are adopting open source-style practices
134 internally).</p></li>
136 <li><p>Partial change merging: The merge meta data itself should be
137 atomic. We record that you either applied a whole change, or
138 not. Of course, hand edits and the log message may tell a more
139 detailed story.</p></li>
141 <li><p>Edited merges should be disentanglable and viewable as separate
142 pieces, i.e. [merge] + [edits]. However, this was a nice-to-have
143 than a must-have.</p></li>
146 all merged regions in a conflicted style, even those which did not
149 <li><p>TortoiseSVN merge is apparently good (it has the Araxis
150 Merge-style "take my version or their version"), but needs a
151 built-in text editor for more involved conflict resolution.</p></li>
155 <li><p>The ability to automate merges (e.g. from a stable branch to a
156 development branch), including interfaces for resolving conflicts
157 and handling other errors, is important. Customers who do
158 multi-thousand file merges stress this.</p></li>
161 'latest' version? Are there changes out there which are applicable
164 <li><p>Any action that can be done to a tag/branch (e.g. merge a
165 change, remove a change, etc.) should be hook-protected. Merging
166 itself should be a first-class hook operation (e.g. commit,
167 revprop-change, etc.)</p></li>
170 have most of the branch follow the original source, while only a few
171 files are selected for branch development (e.g. "unshadowed"). Is
172 this different from systems which allow you to branch individual
173 resources in the first place? Can this be achieved with a
175 shared file storage issue in Subversion's own issue tracker,
178 <a
181 One-File-In-Many-Branches Problem" there, which discusses
182 how p4 and ClearCase do this.</p></li>
184 <li><p>Roll-back should be convenient, and should be recorded as a
185 subtraction event, visible as such in the meta data. Roll-back was
186 common at a few shops, and more rare at others.</p></li>
188 <li><p>Asking change C to where it has been ported was not a strong
189 need (e.g. reporting).</p></li>
193 information company</a>) wanted merge resolution to be distributable
194 across the developer team, rather than limited to one person's
195 working copy. The same group said they do most of their merging in
196 GUIs, and that the merge process saves reports (when they use the
197 commandline tools, they save the logfiles similarly). The longest
198 they've looked back is a few weeks, though.</p></li>
202 information company</a> also stressed the importance of merge
203 previews, dry runs that would allow them to see conflicts and
204 "non-trivial, non-conflicting" (NTNC) changes in advance. These
205 previews should be exportable and parseable, so they can be passed
206 around to others.</p></li>
208 </ul>
215 </body>
216 </html>