[p4] Obliterate metrics

[Stanton Stevens]

Perforce obliterate bug reminder: If you obliterate only some revisions
of a file (as you likely will do when obliterating changelists),
integrations that look for one of the obliterated revs as a base will
fail with database errors. If the files were involved in integrations,
it is safest to obliterate all revs of the file. 

Big obliterates:
One optimization that speeds things up a lot is to create a client spec
that can see only the files to be obliterated and then use:
  p4 obliterate -y //my_oblit_spec/...
It makes a lot fewer passes through the database. 

With 8 cpu's I'm surprised that cpu usage is a problem unless you are
running simultaneous obliterates. One obliterate operation should start
a child p4d that uses at most one cpu. 

If you have the luxury of being on Unix (where you can make symbolic
links, here is a way to prevent locking up the database while
obliterating:

1. Make sure that the files to be obliterated and (ideally) files
branched from them are not accessible to anyone  but you via the protect
table. Or do the obliterate when no one is using the main Perforce
instance. 
2. Create a second root folder, restore a checkpoint into it, play back
your current journal file into it to make it as up to date as possible.
Create symbolic links in this folder that point to the depot storage. 
3. Start up this second Perforce instance with a different port number,
and run the obliterate against it.
4. Play the journal file back into the main Perforce instance. 

Stanton 

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Paul Goffin
Sent: Tuesday, April 17, 2007 3:05 AM
To: 'Rick Macdonald'
Cc: perforce-user at perforce.com
Subject: Re: [p4] Obliterate metrics

I was just outlining.

But if you want better optimisation, an even better way is to find the
changelists connected with the path-to-be-removed by "p4 changes
path-to-be-removed" and only attempt to obliterate those changenumbers.

Paul.

-----Original Message-----
From: Rick Macdonald [mailto:rickmacd at shaw.ca]
Sent: 17 April 2007 08:48
To: Paul Goffin
Cc: perforce-user at perforce.com
Subject: Re: [p4] Obliterate metrics


What if your counter is up over a couple hundred thousand?

Wouldn't you just stop at the counter that created "path-to-be-removed"?

Rick

Paul Goffin wrote:
> Obliterate is much faster if you can reduce the workload on the server

> by not making it unwind branches.  In other words, obliterate the 
> destination of a branch or rename location before the source.
>
> Sometimes it's easy to do this manually but a script that applies 
> "obliterate" to the section of the depot you want to remove "change by

> change" and works BACKWARDS in time can do the job with no effort.
>
> i.e. write a script that does the following:
>
> Set counter to highest change number of interest.
> Repeat
>   p4 obliterate //path-to-be-removed/... at counter,counter
>   decrement counter
> Until counter = 0
>
>
>
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of David 
> Ferguson
> Sent: 17 April 2007 07:42
> To: perforce-user at perforce.com
> Subject: [p4] Obliterate metrics
>
>
> Okay, we split our depot into two last summer.  I'm finally getting 
> around to cleaning up all the old cruft that is now obsolete (since it

> was put into the other depot)... Two choices: obliterate checkpoint 
> surgery.
>  
> Surgery works, but support really seems to frown on it.
>  
> obliterate works ...  But wow it's slow.  Anybody got metrics on how 
> slow?
>  
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>   
_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user