[p4] How to *really* back out a revision

Roy Smith smith_roy at emc.com
Tue Mar 25 15:37:47 PDT 2008

We've got an ugly problem caused by an accidental submit to a release  

Our patch generation process depends on file timestamps changing.   
Skipping a few details, we build the baseline, then resync to the  
head of the release branch, then rebuild.  Anything that's changed,  
gets put into the patch.

Somebody accidentally submitted a new version of a commonly used  
header file to the release branch.  There's lots to talk about how to  
prevent that from happening again, but that's a different story, and  
what's done is done.  We can resubmit the correct version as the new  
head revision.  That will result in the correct source file  
*contents* being on #head, but as far as make is concerned, when we  
rebuild, the file timestamp will have changed.  That will cause a lot  
of things will get rebuilt which don't need to get rebuilt (resulting  
in a mongo patch, which we're trying to avoid).

One solution is "p4 obsolete file#head".  It would certainly fix the  
problem, but I'm reluctant to use obliterate for all the commonly  
cited reasons why it's not a good idea.  Other ideas we've thought of  

1) Building a complex client spec which specifically maps the  
"correct" revision of the offending file.  This should work, but it  
would be a special case in our patch process, and special cases tend  
not to mix well with reproducible processes.

2) Creating a new branch starting with the correct revisions of  
everything and using that as our new release branch.  Again, I think  
this works, but becomes an exception to the normal process going  

Anybody have any better ideas how to recover?

Roy Smith <smith_roy at emc.com>
Software Guy, EMC Common Management Group
44 South Broadway, 7th floor
White Plains, NY 10601
+1  914  580  3427
AIM: roysmith649

More information about the perforce-user mailing list