Jump to content


Create a label from client spec mapping?

label p4 client p4 label

  • Please log in to reply
6 replies to this topic

#1 mcru

mcru

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 31 May 2017 - 08:37 PM

I was hoping it's possible to create a p4 label from a client spec mapping. For example, something like 'p4 client -o' to output the client spec mapping, and pipe it to 'p4 label my_label -i' to create the label using the mapping from the client spec, but I cannot seem to get this to work.

Any clue if this is possible?

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 947 posts

Posted 31 May 2017 - 08:58 PM

Label and client views are structured differently enough to make this nontrivial -- if you run "p4 client -o" and "p4 label -o" you can see that the views are very different (one has two pieces, the other has one).

Before continuing, are you sure you actually need to copy the view over, rather than leaving the view open and doing "p4 labelsync -l LABEL @CLIENT"?

#3 mcru

mcru

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 31 May 2017 - 09:35 PM

Ah, wow. Didn't realize I could just do "p4 labelsync -l LABEL @CLIENT". Are there any downsides to having a label map include the world like it does by default?

#4 mcru

mcru

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 31 May 2017 - 09:36 PM

I guess if I want, I can create a paired down label or two for each build workspace I have, and use them as templates, then do something like "p4 label -o -t sample newLabel | p4 label -i"

#5 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 947 posts

Posted 01 June 2017 - 01:21 AM

The only reason to pare down the label view is if you want to issue a wide open labelsync command and have it filtered according to a specified view -- for example you craft a complicated view that maps only your built binaries so you can do "labelsync @DATE" to get all the current binaries as of that date.  

If you labelsync @CLIENT the results are already filtered by the client's have list, which is in turn necessarily filtered by the client's view (or at least the view as of the time of the sync), so there's presumably no need to apply any extra filtering.

Also note that anyplace you'd use the label, you can just use @CLIENT directly.  The only point of using the label is if you want to save off a snapshot of that client's contents (synced contents that is, obviously this won't include unsubmitted changes) and refer back to those versions at a future point after the client has been re-synced.  If your idea is to be constantly re-syncing the label to keep it up to date with the client, or if you're just going to use this label once as an intermediate step in some other process, just skip the label.  :)

#6 mcru

mcru

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 01 June 2017 - 10:23 PM

Thanks - I may be able to use virtual labels too I guess. The idea is to tag the contents of what was synced to a client spec and used in a build. Basically, build tagging, so we can at a later point in time sync build client specs back to the exact contents from a previous build.

#7 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 947 posts

Posted 02 June 2017 - 07:22 AM

If possible, the way I always recommend doing this is to do your builds based on a changelist.  E.g.:

p4 changes -m 1 -s submitted  (to get the current highest submitted change)
p4 sync @CHANGE
(do build)
(tag build with CHANGE)

Since a submitted changelist is immutable (more so than a label), you can always reproduce the build by syncing to the same changelist.  Note that when you run "p4 info" or "p4 -V" there's a version string with a big number at the end -- that's a changelist!   (They go with the changelists in the relnotes, so given a version string and a relnote entry you can trivially determine whether your version has that fix).  The other benefit of using changelists instead of labels (aside from built in immutability and fewer moving pieces) is that they perform a lot faster in queries.

The *only* thing that would ever stop you from being able to do this would be if you need to sync different sets of files to arbitrary revisions to do your build, which seems pretty bad (that would be a good case for using a release branch or something to encapsulate what versions have been approved for inclusion in each build).





Also tagged with one or more of these keywords: label, p4 client, p4 label

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users