[p4] Convert static to automatic labels

Matt Janulewicz matt.janulewicz at lucasfilm.com
Thu Aug 20 10:09:36 PDT 2009

A scenario I've run into when contemplating this kind of project is that 
a lot of the old labels that far pre-date anyone that works here, had no 
limitations in their scope: //depot/..., and I find that a majority, if 
not the entirety, of a depot or two is labeled. So it's impossible to 
find exactly what was intended to be labeled.

Instead of trying to figure out what labels I can change to an automatic 
label, I just found a big chunk of old labels and asked people if they 
knew what they were. Or if they knew they were still used. If nobody 
knew what the label was for, I archived it. (Dump out the labelspec, 
dump out the list of files in the label, check in that pair of files, 
delete label.) It's easy enough to restore a label if you need it later 
and it cut a significant chunk out of our checkpoints.


Jamie.Echlin at barclayscapital.com wrote:
> Hi Guillaume,
> > I'd be interested to know how you intersect those sets.
> I simply subtract the changelist set from the labelled set (using
> Set::Scalar), if the labelled set is then empty I assume it's safe to
> convert. I believe it's an identical to your method below.
> I already restrict the view as much as possible. Where the labelled set
> comes from different parts of the depot, and the label spec has more
> than one line, then I get the deepest path possible. What is difficult
> is getting the optimum view spec (possibly including minus lines), where
> you are trading off lines in the spec for selecting more than you need
> to. (You could off course list every file in the view for the auto
> label, but then you are just swapping db.labels space for db.domain
> space).
> It's a tough problem and I don't think it's one I'm interested in trying
> to solve, unless I knew that getting this table size down (it's about
> 45% of the total db) would have an overall beneficial performance
> effect.
> BTW earlier, I said: "The table consists of 391M records but only 3M
> records were reported." I wrote the mail before I let the script finish,
> and I was only sampling every 100th records, so this is a non-problem.
> jamie
> > -----Original Message-----
> > From: G Barthelemy [mailto:gb.perforce at googlemail.com]
> > Sent: 20 August 2009 15:11
> > To: Echlin, Jamie: IT (LDN)
> > Cc: perforce-user at perforce.com
> > Subject: Re: [p4] Convert static to automatic labels
> >
> > On Thu, Aug 20, 2009 at 11:20 AM,
> > <Jamie.Echlin at barclayscapital.com> wrote:
> >
> > > I'm looking at converting the static to auto labels where possible.
> > >
> > > If s1 is entirely a subset of s2, this can be converted to an
> > > automatic label. s1 and s2 are not always the same - s2 may
> > > incorporate more revisions than s1, the labelled set. That
> > is one of
> > > the drawbacks of this approach. It will often include deleted files
> > > which sometimes seem not to be labelled, and may include
> > other files too.
> >
> > I'd be interested to know how you intersect those sets.
> >
> > When you are in the situation where s2 incorporates more
> > revisions than s1, then it's time to restrict the scope of
> > the View of the automatic label. The major difficulty in this
> > exercise is of course not to just use a huge list of files,
> > or the point of the automatic label gets somewhat lost, but
> > the optimum label view instead, possibly with exclusion rules
> > if adequate.
> >
> > But ignoring this difficulty, a method I use is this:
> >
> > 1- Setup a temporary client
> > p4 client tmprp
> >
> > 2- Populate that client's have table exclusively with files
> > labelled by STATIC
> > p4 sync -k //depot/project/... at STATIC
> >
> > 3- What's the contender changelist for our automatic label?
> > p4 changes -m1 -s submitted //depot/project/... at tmprp Change
> > 123456 on 2009/08/20 by me at client 'Blah'
> >
> > 4- Now what would happen if I sync'ed the client with that change ?
> > p4 sync -nk //depot/project/... at 123456
> > //depot/project/... at 123456 - file(s) up-to-date.
> >
> > That's good. Here STATIC can be replaced by an automatic
> > label with View set to //depot/project/... and Revision set
> > to 123456 (although to be fair, here we are assuming that
> > STATIC doesn't scope out of //depot/project/... and that we
> > could try and determine if a deeper path would do... I assume
> > that those are the cases that your script picks up.
> >
> > Now if you had any files returned by the last sync, there are
> > 2 scenarios:
> >
> > a- the files labelled by STATIC are not contemporaneous. The
> > label shall remain STATIC, that's what they are for.
> > OR
> > b- we are in the case where the set labelled by STATIC is
> > smaller than that of its contemporaneous changelist 123456.
> > That's when we need to restrict the View of the automatic
> > label to exclude (or not include) the files returned by the
> > last sync. For me, that last operation is still a manual
> > process but it could be scripted(*)
> >
> > (*) What would be great would be a Perforce sub-command that,
> > given a list of file revisions would return the optimal pair of (View,
> > Changelist) that would pick up those revisions, with the
> > option of using exclusion rules or not.
> >
> > --
> > Guillaume
> >
> _______________________________________________
> This e-mail may contain information that is confidential, privileged 
> or otherwise protected from disclosure. If you are not an intended 
> recipient of this e-mail, do not duplicate or redistribute it by any 
> means. Please delete it and any attachments and notify the sender that 
> you have received it in error. Unless specifically indicated, this 
> e-mail is not an offer to buy or sell or a solicitation to buy or sell 
> any securities, investment products or other financial product or 
> service, an official confirmation of any transaction, or an official 
> statement of Barclays. Any views or opinions presented are solely 
> those of the author and do not necessarily represent those of 
> Barclays. This e-mail is subject to terms available at the following 
> link: www.barcap.com/emaildisclaimer. By messaging with Barclays you 
> consent to the foregoing.  Barclays Capital is the investment banking 
> division of Barclays Bank PLC, a company registered in England (number 
> 1026167) with its registered offi!
>  ce at 1 Churchill Place, London, E14 5HP.  This email may relate to 
> or be sent from other members of the Barclays Group.
> _______________________________________________
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user

More information about the perforce-user mailing list