- <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>
# |
Change |
User |
Description |
Committed |
|
#1
|
83 |
Laura Wingerd |
The Branching Papers. |
26 years ago
|
|