[p4] What is the best practice for p4 labelling?

[Jeff A. Bowles]

The only good answer is a "depends on what you're doin'"  sort of answer.

Case 1: "use p4-tag to toss things into a label."

        I would recommend this to developers, who are tracking work /
files important to them but that mean little to the entire group.

        For example, a personal-use label that is "the stuff of mine
that last passed my 3-hour regression suite" would be a good example.
70 files, total, but awfully handy.

        A variation: a personal-use label that I can refer to, when I
point someone at my code for a code review or to replicate behavior
for something I'm chasing down.

        Note the main part: that it is easily updated and therefore
easily stepped on. Keep 'em small, use only a few per developer, and
it'll be fast and reliable.

Case 2: "make label, populate a client, then labelsync to the
revision-you-have."

        Quick note: "I always write  'p4 labelsync -l labelname
#have'   or  'p4 labelsync -l labelname    #head' just to keep it
clear what I'm talking about. (Why memorize that specific default,
when it's more reliable for maintenance-folk to specify it every
time?)

        This is one of the two "old ways". (The other was "use
labelsync to construct the label contents, then sync-to-the-label.")

        Writes a database row for each file/rev combination.  For a
small number of labels, or a small number of files, is fine (and very
specific).  Leads to a common error, which is to include a partial
changelist in a label --- and thereby, a partial bug fix or partial
feature. (The upside is that you have a choice; the downside is that
you can choose poorly.)

        Good for release labels that were updated to include
just-one-more-bug, but a good study of the fast-branch docs might lead
you to other choices. (Such as, making a branch and then using case 3
labels for that branch / branch+patch.)

Case 3: "label, but use view/revision fields in label to be very specific."

        For daily builds, overnight builds, etc, is very
space-efficient in the database. (Trades a run-time overhead, but
that's usually a low overhead compared to checkpoint-time increases
for case 2.)

       Forces you into a specific technique if you have to patch a
release-based-on-label and cannot do it cleanly (things checked in
since) -- branch to new tree based on old label, then label the new
branch.  (Perforce branches nicely, so this is really not awful.)

So, for individual developers, "tag". For common / frequent builds,
"case 3 (revision-based labels)". For others, use case 2 "label /
labelsync" or case 3 "revision-based labels" as you want, but don't go
overboard.

(Each of the three has at least one "oh, that's terrific" moment and
one "oh, that's horrible" moment.  Assignment: describe each.)

  -Jeff Bowles

On Jan 22, 2008 1:25 PM, Thierry Lam <Thierry.Lam at autodesk.com> wrote:
> I've looked at 3 ways to do labeling in perforce and I'm wondering, which one is the best way to so that the perforce server is not severely affected in the long term.
>
> 1.
> Use p4 tag
>     p4 tag -l hi-label //depot/Greet/hi/...
>
> 2.
> Use p4 labelsync
>     * Create the label hi-label
>     * Set the label view  to //depot/Greet/hi/...
>     * Create a client(hi-client) to checkout hi module to your workspace
>     * p4 labelsync -l hi-label -c hi-client
>
> 3.
> Use p4 label only
>     p4 label hi-label
>
> Label:    hi-label
> Owner:    admin
> Description:
>      Labeling hi.
> Options:     unlocked
> View:
>      //depot/Greet/hi/...
> Revision:
>      @123456
>
> The main problem is that we have to upgrade our p4 servers to the 2007.3 version from 2005.2 but the labeling is done fairly easily.
>
> Note:
> We have to do around 50 labels and each one of them will have a different changeset number, that's why I'm using solution 3 by specifying a specific changeset.
>
>
> Thierry
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>



-- 
---
Jeff Bowles - jeff.a.bowles at gmail.com