from an old msg:
<<
I am not on the latest version of the server, I'm using 2002.2, on sun
solaris, but my oblit experience shows that there are some
sensitivities.
first off, if you can do a restore from checkpoint before
obliterating, this will speed things up.
I always create a client that maps in the areas that I want to obliterate
Then I do a "p4 -c client obliterate -y //client/..." and usually, it takes
about an hour, sometimes its not very sensitive to the number of files. I am
always surprised by this, however. Our db size is currently 12 gig.
One thing is that it may do a lot of copying in order to undo the lazy
branching stuff. This can consume more time than the obliterate, so
it might be a good thing to check on. If space is tight, it might
also cause you to run out of space!
Here's an interesting thing. When I did a "p4 -c client obliterate ..."
it took 3 days, instead of a few hours. There shouldn't have
been a difference. None of the oblits since have taken so long when I
use the "p4 -c client obliterate -y //client/..." syntax.
Also, many operations will continue to work ok while the oblit runs.
Our nightly builds, which sync from scratch, continued to run fine
during the 3 day debacle. Luckily, that was over the Christmas
holidays. I generally tell users that things are going to hang
while the oblit runs.
oh yeah, if you use tempobj for some stuff, expect error/warning messages
about missing versions. I seem to remember that happening.
>>
ps. recently, we upgraded, and oblits are running much, much faster. I think
we did one recently that took about 10min!
_______________________________________________
Come to the 2005 Perforce User Conference, April 14 & 15 in Las Vegas.
Learn more: http://www.perforce.com/conf
perforce-user mailing list - perforce-user@xxxxxxxxxxxx
http://maillist.perforce.com/mailman/listinfo/perforce-user
|
