<html>
<head>
<title>The Branching Papers -- Perforce FAQs</title>
<head>
<body bgcolor=#ffffff>
<font size=-2><b><a href="branching.html#br04">[INDEX]</a></b></font>
<p>
<b>
Why is Perforce so brain-dead when it comes to branching renamed files?
</b>
<blockquote>
There are definitely shortcomings in how Perforce handles renames across
branches. First, it's difficult to explain (even though it's not that hard
to understand). Second, there's no automatic way to add a rename line to a
branch spec -- you have to do it by hand, in a separate step from doing
the rename. And finally, branch specs are not versioned. So if someone
comes along and mangles the view in a branch spec, you have to do a
bit of journal-pecking to get the old spec back. (As a hedge, I
recommend storing the "-o" outputs of important specs along with all
other project files.)
<p>
However, despite these shortcomings, our current mechanism does seem to
support some pretty sophisticated SCM. Some very big, very busy shops
tell us they get a lot more mileage out of Perforce branching than they
ever did out of any other system.
<p>
And there's hope -- atomic, persistent file renames, and versioned specs
(client specs, branch specs, etc.), are both on the list of enhancements
we hope to implement someday.
</blockquote>
<p>
<i>(February 1999)</i>
</p>
<font size=-2><b><a href="branching.html#br04">[INDEX]</a></b></font>
<hr>
<h6>This is file $Id: //guest/laura_wingerd/perforce/faq/br04.html#1 $ in the
<a href="http://public.perforce.com/public/index.html">
Perforce Public Depot</a></h6>
</body>
</html>