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

[Robert Cowham]

I agree with Steve that an obliterate is sometimes appropriate, but I would
always test out the speed of obliterates on a copy of your live server
before doing it for real.

For one client with a very large repository an obliterate of a single file
at a single revision is taking many hours - this with a 2006.2 server :( 

Robert

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Stephen Vance
> Sent: 26 March 2008 01:15
> To: Roy Smith
> Cc: perforce-user at perforce.com Com
> Subject: Re: [p4] How to *really* back out a revision
> 
> 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.
> 
> Steve
> 
> 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
> www.vance.com
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>