<!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 Survey</title>
<style type="text/css">
.question { color: grey; }
.answer   { }
</style>
</head>

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

<p>Responses to CollabNet's pre-<a href="summit.html">summit</a>
questionnaire are given below.  The respondents are anonymous,
but we indicate what business each is in.</p>


<div class="h3" id="web-info-services">
<h3>Responses from a <i>Web Information Services</i> company</h3>

<p class="question">What tools you have used previously had merge
tracking features, and did you like them?  Why or why not?</p>

<div class="answer"><p>Perforce. Its "integration" feature works very
well at tracking what has been merged between branches. It can merge
portions, or entire changelists.</p>

<p>P4 branches suck, but the integrate between them works great
because P4 remembers the associations between the trunk and the
branch, so it knows how to pair up the files for merging.</p></div>

<p class="question">What tasks did you use those features for?
(Define "merge tracking" as broadly as you need to answer this --
we're more interested in the tasks and how to make them easier than in
niceties of categorization.)</p>

<div class="answer"><p>We use few development branches, but when we
do: the integrate command keeps the branch up to date w.r.t the
trunk. The integrate command is also how we bring stuff *back* to the
trunk. Since the branch knows that revs N-M were merged onto the
branch, it won't try to reapply them to the trunk. You just get your
changes brought to trunk.</p>

<p>We also use branches for tracking releases. The integrations bring
over all changes from trunk to the release branch. In many cases,
we'll cherry pick specific changelists from trunk over to the release
branch.</p></div>

<p class="question">If you have used Subversion, what tasks do you
feel would have been easier with merge tracking functionality?  What
were you trying to accomplish, and how would you have liked Subversion
to behave to help you accomplish it?</p>

<div class="answer"><p>My work with Subversion has never involved heavy
branch work (and my company doesn't use svn).</p></div>

<p class="question">What version control tools have you had experience
with?</p>

<div class="answer"><p>CVS, SVN, rcs, Perforce, VSS</p></div>

<p class="question">What does your organization use branches for?
Select all that apply:

   a)  Maintenance/releases
   b)  Experimental efforts
   c)  Customized versions for customers
   d)  Other (describe)</p>

<div class="answer"><p>Maintenance/release, and some long-term dev
branches. We don't use them for experimental or for customer-specific
code.</p></div>

<p class="question">What is the size of your organization's data set
and what is the number of branches in your projects?</p>

<div class="answer"><p>Big :-). I know svn can handle our size tho.</p></div>

<p class="question">Summarize your general branch and development
strategy.</p>

<div class="answer"><p>See above.</p></div>

</div>  <!-- web-info-services -->

<div class="h3" id="desktop-software">
<h3>Responses from a <i>Desktop Software</i> company</h3>

<p class="question">What tools you have used previously had merge
tracking features, and did you like them?  Why or why not?</p>

<div class="answer"><p>ClearCase: Likes: 3-way merge editor; merge
info recorded in version tree; graphical display of version tree with
merge "hyperlinks"; use labels to identify file sets.  Dislikes: works
only on single files, not on group of files. Impossible to know what
changed between two releases (I needed to create my own tool that
analyzed the output of "lsvtree" command).</p>

<p>Perforce: Still learning all the features. I cannot find an easy
way to display the branch tree, when a branch was created, when files
were merged.  So far, I need to look at a lot of (text) history data
and create a merge tracking graph by hand. I may need to write my own
tool to do this analysis, similar to ClearCase.</p></div>

<p class="question">What tasks did you use those features for?
(Define "merge tracking" as broadly as you need to answer this --
we're more interested in the tasks and how to make them easier than in
niceties of categorization.)</p>

<div class="answer"><p>Basically I would like to know at a glace which
features/fixes are left out of a certain version/subtree. Too many
times in ClearCase we had a bug fixed on a branch but not in the main
trunk because a merge policy was not enforced. After we started to
merge all the hanging branches, the stability of the product improved
considerably. We also prevented any engineers except the Architects
from checking code into the main trunk, and have an e-mail sent if any
non-authorized person attempted to check into the main trunk.</p>

<p>The same for merges from the main trunk to working branches, so
that one can know how different is the branch from the main trunk
(i.e. how much work it will be to merge it back).</p></div>

<p class="question">If you have used Subversion, what tasks do you
feel would have been easier with merge tracking functionality?  What
were you trying to accomplish, and how would you have liked Subversion
to behave to help you accomplish it?</p>

<div class="answer"><p>We used Subversion for a large C++ project with
3 branches alive at any given time. We mostly used the "update"
command and automerge before a commit to the same branch. We never
automatically merged across branches. All cross-merges were done by
hand using a 3rd party tool (Araxis Merge).</p>

<p>I didn't like the graphical representation of the history of a
file, which was confusing and almost never useful. Subversion does not
record info about merges, so each engineer was forced to do double
work: fix a bug on the release branch, and at the same time fix the
same bug in the next release (development) branch. This was enforced
in order to make sure that no bug fix was only done on the branch and
never merged back to main.  Because of all of this, we tried to keep
the number of branches down to a minimum.</p></div>

<p class="question">What version control tools have you had experience
with?</p>

<div class="answer"><p>ClearCase: see above</p>

<p>SourceSafe : Never used for branching/merging, because it was
unreliable and sometimes it corrupted the source repository. After
finding the corruption/inconsistent state problems we switched to
Subversion.</p>

<p>Subversion: see above</p>

<p>CVS</p></div>

<p class="question">What does your organization use branches for?
Select all that apply:

   a)  Maintenance/releases
   b)  Experimental efforts
   c)  Customized versions for customers
   d)  Other (describe)</p>

<div class="answer"><p>A,b,c</p></div>

<p class="question">What is the size of your organization's data set
and what is the number of branches in your projects?</p>

<div class="answer"><p>Minimal data set is approx. 600Mb (core), but could
be much bigger if other components are added (tools, tests etc.)</p></div>

<p class="question">Summarize your general branch and development
strategy.</p>

<div class="answer"><p>One main branch tracks the official (public)
development of new code. Personal branches are used to implement new
features and are subject to periodical merges from the main
trunk. When the new feature is ready, it is merged back to the main
trunk or possibly to one active release branch.</p>

<p>[Release branches are created when the main trunk is ready for the
next release. Release branches receive bug fixes and are these fixes
are usually automatically merged to the main trunk.]</p></div>

</div>  <!-- desktop-software -->


<div class="h3" id="medical-systems">
<h3>Responses from a <i>Medical Systems</i> company</h3>

<p class="question">What tools you have used previously had merge
tracking features, and did you like them?  Why or why not?</p>

<div class="answer"><p>We currently use ClearCase with UCM. Developers
like the graph tool, the simple merging, the adding of merge arrows
when an actual merge is not needed, the ability to see where items
came from or where thy where merged, and the ability to trace who
actually made the change.</p>

<p>It's dog slow and hard to script nicely in order to get a daily
view if everything from one branch has been merged to another. Also it
is not 100% reliable and has its share of problems.</p></div>

<p class="question">What tasks did you use those features for?
(Define "merge tracking" as broadly as you need to answer this --
we're more interested in the tasks and how to make them easier than in
niceties of categorization.)</p>

<div class="answer"><p>As a medical device company we have to provide
trace-ability on a number of aspects, in order to prove that the final
product has been made with consideration of prior products and in a
good fashion. This is a lot easier with (almost requires) merge
tracking, so that we can trace any change anywhere, know who did it,
and when. We also have to maintain code for 10-12 years, which implies
a lot of versions and thus a lot of merging, so having merging being
as simple as possible is essential.</p>

<p>Merge tracking tasks are:</p>
<ul>
  <li>Easy merging of development work from a development branch to
  the main archive</li>

  <li>Ability to trace a change from any branch to the branch where it
  was originally done. And as a part of this identify the original
  changer.</li>

  <li>Ability to see what branches a change has been merged to.</li>

  <li>Ensuring that all changes made in an older project have been
  merged to a newer project.</li>

  <li>Daily merging of changes without repeating old merges or having
  to specify in detail what exactly to merge.</li>
</ul></div>

<p class="question">If you have used Subversion, what tasks do you
feel would have been easier with merge tracking functionality?  What
were you trying to accomplish, and how would you have liked Subversion
to behave to help you accomplish it?</p>

<div class="answer">
<ol>
  <li>Basic merging of changes from one project branch to another is
  rather painful, as one has to remember what changes where merged the
  last time.</li>

  <li>When looking at a merged change set to see who made a particular
  change this is not possible.</li>

  <li>When trying to identify what branches a change has been merged
  to this is not possible.</li>

  <li>When trying to identify where a merged change came from this is
  not possible.</li>

  <li>When merging the already poor information on moves/renames are
  completely lost.</li>
</ol></div>

<p class="question">What version control tools have you had experience
with?</p>

<div class="answer"><p>Mainly UCM and base ClearCase.</p></div>

<p class="question">What does your organization use branches for?
Select all that apply:

   a)  Maintenance/releases
   b)  Experimental efforts
   c)  Customized versions for customers
   d)  Other (describe)</p>

<div class="answer"><p>A, B, C, and D. For D the main usage is developer
branches used as a part of UCM.</p></div>

<p class="question">What is the size of your organization's data set
and what is the number of branches in your projects?</p>

<div class="answer"><p>The current data set is about 800-1000 MB and we
have about 12 project branches and about 100 developer branches.</p></div>

<p class="question">Summarize your general branch and development
strategy.</p>

<div class="answer"><p>The current setup starts with a main archive from
which each main project archive is created. The main archive (MIP) is
only used to merge the latest project into when a new project needs to
be created.  The project archives (MIP ?.?V1) are created when the
project starts (one new project every half year) and kept alive for as
long as 10-12 years depending on customers usage and FDA regulations.
On each project branch there are MultiSite ClearCase stream, from
which each developer has one or more development streams.  When a
project decides to make release (first one after half a year and then
based on customer demands) a release branch is created (MIP ?.?V1L?).
New versions of the project archives (MIP ?.?V?) may be created if
needed for customer specific bug fixing and isolation. This policy
does not scale and is being avoided.</p></div>

</div>  <!-- medical-systems -->


<div class="h3" id="investment-banking">
<h3>Responses from an <i>Investment Banking</i> company</h3>

<p class="question">What tools you have used previously had merge
tracking features, and did you like them?  Why or why not?</p>

<div class="answer"><p>Perforce.  My memory is fuzzy, but I remember not
being annoyed by it.</p></div>

<p class="question">What tasks did you use those features for?
(Define "merge tracking" as broadly as you need to answer this --
we're more interested in the tasks and how to make them easier than in
niceties of categorization.)</p>

<div class="answer"><p>Rolling changes from a branch into the
mainline.</p></div>

<p class="question">If you have used Subversion, what tasks do you
feel would have been easier with merge tracking functionality?  What
were you trying to accomplish, and how would you have liked Subversion
to behave to help you accomplish it?</p>

<div class="answer"><p>I have a branch and a mainline.  I want to roll all
changes from the branch into the mainline- then I want to come back
later and pick up more changes.  I don't want to have to think about
what I've already done.  It would be ideal if I saw the history from
the branch appear in the history for the mainline, but that's going
over the top a bit.  I'd be okay if I ended up with an automatically
generated log message that tells me that the guy who did the merge
isn't the guy who wrote the code and that I can find the real history
for the changes on the branch...</p></div>

<p class="question">What version control tools have you had experience
with?</p>

<div class="answer"><p>p4, cvs, vss (*sigh*)</p></div>

<p class="question">What does your organization use branches for?
Select all that apply:

   a)  Maintenance/releases
   b)  Experimental efforts
   c)  Customized versions for customers
   d)  Other (describe)</p>

<div class="answer"><p>mostly a, occasionally b</p></div>

<p class="question">What is the size of your organization's data set
and what is the number of branches in your projects?</p>

<div class="answer"><p>too many to count.</p></div>

<p class="question">Summarize your general branch and development
strategy.</p>

<div class="answer"><p>Our branch strategy is minimize branches and their
associated overhead.  We create branches only when we have a past tag
that needs work or if we really need it for parallel development.
Branches are a sometimes necessary evil.  People always have a
tendency to make a mess with them.  If anything, the most important
part of merge tracking is to protect people from themselves.  Warn
them when they're about to double merge or do something eqally
inclined to cause pain.</p></div>

</div>  <!-- investment-banking -->

<div class="h3" id="financial-information">
<h3>Responses from a <i>Financial Information</i> company</h3>

<p class="question">What tools you have used previously had merge
tracking features, and did you like them?  Why or why not?</p>

<div class="answer"><p>Pretty much just base Rational ClearCase -
experimented with UCM a bit (didn't like the posted delivery bit)</p>

<p>Nearly all merge tracking done through the CC merge manager.  Some
tracking done by running findmerge commands and logging results.</p>

<p>Like the CC merge manager gui and the flexibility of choosing
between branch, label or view configuration.  Do not like the
inability to export data from the merge manager into files (for
example to export the list of files merged for a report)</p></div>

<p class="question">What tasks did you use those features for?
(Define "merge tracking" as broadly as you need to answer this --
we're more interested in the tasks and how to make them easier than in
niceties of categorization.)</p>

<div class="answer"><p>Used the features to first preview potential
candidates that would merge between branches and then migrate code
changes from branch to branch.</p>

<p>Previews used to:</p>

<p>1) Provide evidence of needed merges so that merge
activities could be better planned.</p>

<p>Code migrations used to:</p>

<p>1) provide baselines for new development
efforts.</p>

<p>2) Rebase existing development efforts with
production changes</p></div>

<p class="question">If you have used Subversion, what tasks do you
feel would have been easier with merge tracking functionality?  What
were you trying to accomplish, and how would you have liked Subversion
to behave to help you accomplish it?</p>

<div class="answer"><p>I have not really used Subversion much at all.  I
did not find it very easy to figure out how to actually do a merge in
Subversion - it seemed very cryptic in terms of trying to decide where
the start and end points of a merge were.  I would like it to be
easier to merge from well defined points on a given branch (e.g. merge
from a label) and I would like to have reports of everything that
actually merged.  I would also like the ability to preview a merge,
getting a listing of potential merge candidates without having to
actually perform a merge (note: CC does this in part but it requires
merging of directory elements - this is acceptable to me as I can
simply cancel the checkout of the directory elements once a preview
has been generated)</p></div>

<p class="question">What version control tools have you had experience
with?</p>

<div class="answer"><p>RCS</p>

<p>Rational ClearCase</p></div>

<p class="question">What does your organization use branches for?
Select all that apply:<!-- the rest of this doesn't get nicely
                           formatted in the browser, but that's
                           probably okay -->

   a)      Maintenance/releases
   b)      Experimental efforts
   c)      Customized versions for customers
   d)      Other (describe)</p>

<div class="answer"><p>How about e) all of the above?  We primarily uses
branches for a) but we allow for local experiment branches and we
reserve the right to branch for a variety of reasons.  We look at
branches as ways to isolate changes from one another and there are
lots of reasons we might want to do that.  Our projects and releases
tend to be customer oriented so project requirements can differ
significantly from one to another.</p></div>

<p class="question"> What is the size of your organization's data set
and what is the number of branches in your projects?</p>

<div class="answer"><p>Our data set currently consists of 23 ClearCase
Vobs, the largest of these is around 15 G.  Of these there are several
that have multiple branches and are merged with regularity.  The
largest of these contains approximately 9000 elements and has as many
as 4-5 project branches active at any one time (main is not considered
a project branch).  Each branch represents a single development effort
(release) and the same branch type can exist in multiple Vobs.  There
can be multiple projects that encompass a development effort.</p></div>

<p class="question">Summarize your general branch and development
strategy.</p>

<div class="answer"><p>Our general strategy is to have the main branch
always represent production code and to branch as much as possible
from stable baselines off the main branch.  We do allow for cascading
when the need arises but we prefer to not let branches get more than
two levels deep.  New development efforts are given a branch when
needed.  Once a branch goes into production it is merged to main and
any other in-progress development efforts are rebased accordingly.
The branch that has gone into production then becomes the "emergency
fix" or "patch branch" so that emergency fixes can be made if
necessary.</p></div>

</div>  <!-- financial-information -->

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