| blob | 718e581e8f1d4435a520f16c1d20fdb512e7f66d |
4 <head>
17 </style>
18 </head>
20 <body>
25 questionnaire are given below. The respondents are anonymous,
26 but we indicate what business each is in.</p>
33 tracking features, and did you like them? Why or why not?</p>
36 well at tracking what has been merged between branches. It can merge
37 portions, or entire changelists.</p>
39 <p>P4 branches suck, but the integrate between them works great
40 because P4 remembers the associations between the trunk and the
41 branch, so it knows how to pair up the files for merging.</p></div>
44 (Define "merge tracking" as broadly as you need to answer this --
45 we're more interested in the tasks and how to make them easier than in
46 niceties of categorization.)</p>
49 do: the integrate command keeps the branch up to date w.r.t the
50 trunk. The integrate command is also how we bring stuff *back* to the
51 trunk. Since the branch knows that revs N-M were merged onto the
52 branch, it won't try to reapply them to the trunk. You just get your
53 changes brought to trunk.</p>
55 <p>We also use branches for tracking releases. The integrations bring
56 over all changes from trunk to the release branch. In many cases,
57 we'll cherry pick specific changelists from trunk over to the release
58 branch.</p></div>
61 feel would have been easier with merge tracking functionality? What
62 were you trying to accomplish, and how would you have liked Subversion
63 to behave to help you accomplish it?</p>
66 branch work (and my company doesn't use svn).</p></div>
69 with?</p>
74 Select all that apply:
76 a) Maintenance/releases
77 b) Experimental efforts
78 c) Customized versions for customers
79 d) Other (describe)</p>
82 branches. We don't use them for experimental or for customer-specific
83 code.</p></div>
86 and what is the number of branches in your projects?</p>
91 strategy.</p>
101 tracking features, and did you like them? Why or why not?</p>
104 info recorded in version tree; graphical display of version tree with
105 merge "hyperlinks"; use labels to identify file sets. Dislikes: works
106 only on single files, not on group of files. Impossible to know what
107 changed between two releases (I needed to create my own tool that
110 <p>Perforce: Still learning all the features. I cannot find an easy
111 way to display the branch tree, when a branch was created, when files
112 were merged. So far, I need to look at a lot of (text) history data
113 and create a merge tracking graph by hand. I may need to write my own
114 tool to do this analysis, similar to ClearCase.</p></div>
117 (Define "merge tracking" as broadly as you need to answer this --
118 we're more interested in the tasks and how to make them easier than in
119 niceties of categorization.)</p>
122 features/fixes are left out of a certain version/subtree. Too many
123 times in ClearCase we had a bug fixed on a branch but not in the main
124 trunk because a merge policy was not enforced. After we started to
125 merge all the hanging branches, the stability of the product improved
126 considerably. We also prevented any engineers except the Architects
127 from checking code into the main trunk, and have an e-mail sent if any
128 non-authorized person attempted to check into the main trunk.</p>
130 <p>The same for merges from the main trunk to working branches, so
131 that one can know how different is the branch from the main trunk
132 (i.e. how much work it will be to merge it back).</p></div>
135 feel would have been easier with merge tracking functionality? What
136 were you trying to accomplish, and how would you have liked Subversion
137 to behave to help you accomplish it?</p>
141 command and automerge before a commit to the same branch. We never
142 automatically merged across branches. All cross-merges were done by
145 <p>I didn't like the graphical representation of the history of a
146 file, which was confusing and almost never useful. Subversion does not
147 record info about merges, so each engineer was forced to do double
148 work: fix a bug on the release branch, and at the same time fix the
149 same bug in the next release (development) branch. This was enforced
150 in order to make sure that no bug fix was only done on the branch and
151 never merged back to main. Because of all of this, we tried to keep
152 the number of branches down to a minimum.</p></div>
155 with?</p>
159 <p>SourceSafe : Never used for branching/merging, because it was
160 unreliable and sometimes it corrupted the source repository. After
161 finding the corruption/inconsistent state problems we switched to
162 Subversion.</p>
169 Select all that apply:
171 a) Maintenance/releases
172 b) Experimental efforts
173 c) Customized versions for customers
174 d) Other (describe)</p>
179 and what is the number of branches in your projects?</p>
182 be much bigger if other components are added (tools, tests etc.)</p></div>
185 strategy.</p>
188 development of new code. Personal branches are used to implement new
189 features and are subject to periodical merges from the main
190 trunk. When the new feature is ready, it is merged back to the main
191 trunk or possibly to one active release branch.</p>
193 <p>[Release branches are created when the main trunk is ready for the
194 next release. Release branches receive bug fixes and are these fixes
195 are usually automatically merged to the main trunk.]</p></div>
204 tracking features, and did you like them? Why or why not?</p>
207 like the graph tool, the simple merging, the adding of merge arrows
208 when an actual merge is not needed, the ability to see where items
209 came from or where thy where merged, and the ability to trace who
210 actually made the change.</p>
212 <p>It's dog slow and hard to script nicely in order to get a daily
213 view if everything from one branch has been merged to another. Also it
217 (Define "merge tracking" as broadly as you need to answer this --
218 we're more interested in the tasks and how to make them easier than in
219 niceties of categorization.)</p>
222 trace-ability on a number of aspects, in order to prove that the final
223 product has been made with consideration of prior products and in a
224 good fashion. This is a lot easier with (almost requires) merge
225 tracking, so that we can trace any change anywhere, know who did it,
227 a lot of versions and thus a lot of merging, so having merging being
228 as simple as possible is essential.</p>
231 <ul>
232 <li>Easy merging of development work from a development branch to
233 the main archive</li>
235 <li>Ability to trace a change from any branch to the branch where it
236 was originally done. And as a part of this identify the original
237 changer.</li>
241 <li>Ensuring that all changes made in an older project have been
242 merged to a newer project.</li>
244 <li>Daily merging of changes without repeating old merges or having
245 to specify in detail what exactly to merge.</li>
246 </ul></div>
249 feel would have been easier with merge tracking functionality? What
250 were you trying to accomplish, and how would you have liked Subversion
251 to behave to help you accomplish it?</p>
254 <ol>
255 <li>Basic merging of changes from one project branch to another is
256 rather painful, as one has to remember what changes where merged the
257 last time.</li>
259 <li>When looking at a merged change set to see who made a particular
260 change this is not possible.</li>
262 <li>When trying to identify what branches a change has been merged
263 to this is not possible.</li>
265 <li>When trying to identify where a merged change came from this is
266 not possible.</li>
268 <li>When merging the already poor information on moves/renames are
269 completely lost.</li>
270 </ol></div>
273 with?</p>
278 Select all that apply:
280 a) Maintenance/releases
281 b) Experimental efforts
282 c) Customized versions for customers
283 d) Other (describe)</p>
286 branches used as a part of UCM.</p></div>
289 and what is the number of branches in your projects?</p>
295 strategy.</p>
298 which each main project archive is created. The main archive (MIP) is
299 only used to merge the latest project into when a new project needs to
300 be created. The project archives (MIP ?.?V1) are created when the
301 project starts (one new project every half year) and kept alive for as
303 On each project branch there are MultiSite ClearCase stream, from
304 which each developer has one or more development streams. When a
305 project decides to make release (first one after half a year and then
306 based on customer demands) a release branch is created (MIP ?.?V1L?).
307 New versions of the project archives (MIP ?.?V?) may be created if
308 needed for customer specific bug fixing and isolation. This policy
309 does not scale and is being avoided.</p></div>
318 tracking features, and did you like them? Why or why not?</p>
321 being annoyed by it.</p></div>
324 (Define "merge tracking" as broadly as you need to answer this --
325 we're more interested in the tasks and how to make them easier than in
326 niceties of categorization.)</p>
329 mainline.</p></div>
332 feel would have been easier with merge tracking functionality? What
333 were you trying to accomplish, and how would you have liked Subversion
334 to behave to help you accomplish it?</p>
337 changes from the branch into the mainline- then I want to come back
338 later and pick up more changes. I don't want to have to think about
339 what I've already done. It would be ideal if I saw the history from
340 the branch appear in the history for the mainline, but that's going
341 over the top a bit. I'd be okay if I ended up with an automatically
342 generated log message that tells me that the guy who did the merge
343 isn't the guy who wrote the code and that I can find the real history
344 for the changes on the branch...</p></div>
347 with?</p>
352 Select all that apply:
354 a) Maintenance/releases
355 b) Experimental efforts
356 c) Customized versions for customers
357 d) Other (describe)</p>
362 and what is the number of branches in your projects?</p>
367 strategy.</p>
370 associated overhead. We create branches only when we have a past tag
371 that needs work or if we really need it for parallel development.
372 Branches are a sometimes neccessary evil. People always have a
373 tendency to make a mess with them. If anything, the most important
374 part of merge tracking is to protect people from themselves. Warn
375 them when they're about to double merge or do something eqally
376 inclined to cause pain.</p></div>
384 tracking features, and did you like them? Why or why not?</p>
387 experimented with UCM a bit (didn't like the posted delivery bit)</p>
389 <p>Nearly all merge tracking done through the CC merge manager. Some
390 tracking done by running findmerge commands and logging results.</p>
392 <p>Like the CC merge manager gui and the flexibility of choosing
393 between branch, label or view configuration. Do not like the
394 inability to export data from the merge manager into files (for
395 example to export the list of files merged for a report)</p></div>
398 (Define "merge tracking" as broadly as you need to answer this --
399 we're more interested in the tasks and how to make them easier than in
400 niceties of categorization.)</p>
403 candidates that would merge between branches and then migrate code
404 changes from branch to branch.</p>
409 activities could be better planned.</p>
414 efforts.</p>
417 production changes</p></div>
420 feel would have been easier with merge tracking functionality? What
421 were you trying to accomplish, and how would you have liked Subversion
422 to behave to help you accomplish it?</p>
425 did not find it very easy to figure out how to actually do a merge in
426 Subversion - it seemed very cryptic in terms of trying to decide where
427 the start and end points of a merge were. I would like it to be
428 easier to merge from well defined points on a given branch (e.g. merge
429 from a label) and I would like to have reports of everything that
430 actually merged. I would also like the ability to preview a merge,
431 getting a listing of potential merge candidates without having to
432 actually perform a merge (note: CC does this in part but it requires
433 merging of directory elements - this is acceptable to me as I can
434 simply cancel the checkout of the directory elements once a preview
435 has been generated)</p></div>
438 with?</p>
445 Select all that apply:<!-- the rest of this doesn't get nicely
446 formatted in the browser, but that's
447 probably okay -->
449 a) Maintenance/releases
450 b) Experimental efforts
451 c) Customized versions for customers
452 d) Other (describe)</p>
455 branches for a) but we allow for local experiment branches and we
456 reserve the right to branch for a variety of reasons. We look at
457 branches as ways to isolate changes from one another and there are
458 lots of reasons we might want to do that. Our projects and releases
459 tend to be customer oriented so project requirements can differ
460 significantly from one to another.</p></div>
463 and what is the number of branches in your projects?</p>
466 Vobs, the largest of these is around 15 G. Of these there are several
467 that have multiple branches and are merged with regularity. The
468 largest of these contains approximately 9000 elements and has as many
470 a project branch). Each branch represents a single development effort
471 (release) and the same branch type can exist in multiple Vobs. There
472 can be multiple projects that encompass a development effort.</p></div>
475 strategy.</p>
478 always represent production code and to branch as much as possible
479 from stable baselines off the main branch. We do allow for cascading
480 when the need arises but we prefer to not let branches get more than
481 two levels deep. New development efforts are given a branch when
482 needed. Once a branch goes into production it is merged to main and
483 any other in-progress development efforts are rebased accordingly.
484 The branch that has gone into production then becomes the "emergency
486 necessary.</p></div>
491 </body>
492 </html>