<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/universitytexas/faq/br04.html#1 $ in the <a href="http://public.perforce.com/public/index.html"> Perforce Public Depot</a></h6> </body> </html>
|#1||684||jim_dowsett||Beginning point for UTA se1 CSE5324 summer 2001 version control/file sharing project.|
Publish "Branching FAQ"
(pull in changes from //guest/laura_wingerd/perforce/faq/... )
|#1||83||laura_wingerd||The Branching Papers.|