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

Stephen Vance steve at vance.com
Tue Mar 25 18:14:48 PDT 2008

In my opinion, this is an occasion where obliterate is justified. 
Solution (1) doesn't work because you can't have a client spec map a 
revision. The revision is determined by the sync, which leaves you with 
an open opportunity for more errors. Solution (2) could work, but is 
ugly and inadvisable for the reasons you cite.


Roy Smith wrote:
> We've got an ugly problem caused by an accidental submit to a release  
> branch.
> 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  
> include:
> 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  
> forward.
> 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
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user

Stephen Vance

More information about the perforce-user mailing list