[p4] Obliterate metrics

[Dave Lewis]

For my part, we never oblit specific revisions. An oblit is 99% of the
time to remove files submitted in error, like the first revision went
into the depot in the wrong place. After that, things just become part
of the history.

Dave



On 4/17/07, David Ferguson <daf at vmware.com> wrote:
> Do people think the changelist is better than the specific file version?
>
> Ie ... obliterating
> foo at 3000,3000
> foo at 2590,2590
> foo at 2000,2000
>
> Is faster/slower than
> foo#3
> foo#2
> foo#1
>
> -daf
>
>
> > -----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 1: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
> >
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>