<head>
<title>The Branching Papers -- Perforce FAQs</title>
</head>
<body bgcolor=#ffffff>
<a name="top"></a>
<h2>
The Branching Papers
</h2>
<p>
Contributed by Laura Wingerd
<h3>
Frequently (and Infrequently) Asked Questions
about Branching, Integrating, Resolving,
and Sundry
<a href="http://www.perforce.com">Perforce</a>-Related Topics
</h3>
<i>These are excerpted from my own email folder on branching.
Some of these may be slightly out of date; my expertise
has evolved over time, and so has the Perforce product.
But if you're trying to get a better understanding of how
branching works, these notes may help.
</i>
<h3>Branch Views</h3>
<p>
<ul>
<p><li>
<a name="br07"></a>
<a href="br07.html">
Why use branch views?
</a>
<p><li>
<a name="br06"></a>
<a href="br06.html">
Is there a way to see what a branch view looked like in the past?
Can this information be determined from "filelog" output?
</a>
</ul>
<h3>Integrating and Resolving</h3>
<p>
<ul>
<p><li>
<a name="br12"></a>
<a href="br12.html">
Is there a way to
'fake out' Perforce to tell it that a merge has already been done, or that
it doesn't need to be done?
</a>
<p><li>
<a name="br10"></a>
<a href="br10.html">
I backed a change out of one codeline, but I don't want to back it out
of the codeline that's branched from it. Now, every time I integrate
between the two codelines, Perforce wants to integrate the "backing-out"
change. Is there a way to tell it not to?
</a>
<p><li>
<a name="br02"></a>
<a href="br02.html">
We tried to integrate a single change from one branch to
another but in the resolve step we saw hundreds of deltas
that weren't in this change. Why was this?
</a>
</ul>
<h3>Handling Renamed Files</h3>
<p>
<ul>
<p><li>
<a name="br03"></a>
<a href="br03.html">
I have a file I renamed in one branch. When I try to integrate
changes from that branch to another, Perforce insists on renaming
the same file in the target branch. How do I prevent that?
</a>
<p><li>
<a name="br04"></a>
<a href="br04.html">
Why is Perforce so brain-dead when it comes to branching renamed files?
</a>
</ul>
<h3>File Histories</h3>
<p>
<ul>
<p><li>
<a name="br08"></a>
<a href="br08.html">
What is this "filelog" output telling me?
</a>
<p><li>
<a name="br13"></a>
<a href="br13.html">
How do I find out which <i>changelists</i> (not <i>files</i>) need
integrating from one branch to another?
</a>
</ul>
<h3>Branching Strategies</h3>
<ul>
<p><li>
<a name="br11"></a>
<a href="br11.html">
I read through the manual about branching, but I just can't figure out
how to apply it to our daily build procedures here.
Our old SCM system has a completely different branching model.
How do I set up our builds to work with Perforce?
</a>
<p><li>
<a name="br01"></a>
<a href="br01.html">
We have a product that will be
ported and released on HP and on Solaris. Should we branch
//depot/main into
//depot/variant-hp and
//depot/variant-sol?
And then should we branch off of those for each release?
That seems like a lot of branches to maintain.
</a>
<p><li>
<a name="br05"></a>
<a href="br05.html">
Will be we able to integrate bug fixes from our development branch
into the our QA branch without dragging new feature-specific changes
along with them? It there a way to mark the new development changes
so that they won't get integrated into the QA branch?
</a>
<p><li>
<a name="br09"></a>
<a href="br09.html">
We've got three related codelines we'd like to set up in Perforce,
but our current SCM system is so hopeless we don't have any branch
or integration history to convert. How can we make these three
separate directory trees into related Perforce branches?
</a>
</ul>
</a>
<p>
<p>
<small><a href="#top">[TOP]</a></small>
<hr>
<h6>This is file $Id: //guest/laura_wingerd/perforce/faq/branching.html#2 $ in the
<a href="http://public.perforce.com/public/index.html">
Perforce Public Depot</a></h6>
</body>
</html>