[p4] Convert static to automatic labels

Chuck Karish chuck.karish at gmail.com
Sun Aug 23 14:17:51 PDT 2009


On Thu, Aug 20, 2009 at 3:20 AM, <Jamie.Echlin at barclayscapital.com> wrote:
> Our db.labels table is large, varying from 60-70 G, and growing rapidly
> ... we get some back after a rebuild from checkpoint, suggesting
> additions and deletions.
>
> I'm looking at converting the static to auto labels where possible.
>
> Q1. Is this likely to have a positive affect on overall performance,
> other than querying labels etc? I suppose this happens when viewing the
> rev graph for instance.
>
> I know it causes us problems when checkpointing and restoring, but I'm
> interested in if there will be any user-perceived improvement.
>
> The script works by, for each label spec, for each element of the View,
> working out the deepest path in which all labels are under. It puts all
> labelled files in a set (s1).
>
> It then takes the highest change list that comprises all revisions, and
> for all of these deepest paths, adds these elements to a set (s2).
>
> 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.
>
> The table consists of 391M records. In running the script in preview
> mode, it tells me how many total records can be deleted, and how many
> would remain because the labels can't be converted. However, this only
> reports around 3M records total, whereas it should tell me 391M.
>
> Q2. Does anyone know why? Can db.label records get orphaned somehow? For
> example if the label spec is changed to a narrower scope after
> labelsyncing?

I don't think label contents are versioned.   If I'm right db.label has
no need to save records that are not in scope for a current label.

-- 
Chuck Karish   karish at well.com   (415) 317-0182



More information about the perforce-user mailing list