/* A label specification. Labels can be either automatic or static. Automatic labels refer to the revisions provided in the View: and Revision: fields. Static labels refer only to those specific revisions tagged by the label by means of either the p4 labelsync or p4 tag commands. */ function LabelCommand(data) { Object.defineProperties(this, { /* The label name. */ "label": { value: data ? data.label : undefined, enumerable: true, writable: true }, /* The label’s owner. By default, the user who created the label. Only the owner of a label can update which files are tagged with the label. The specified owner does not have to be a Perforce user. You might want to use an arbitrary name if the user does not yet exist, or if you have deleted the user and need a placeholder until you can assign the spec to a new user. */ "owner": { value: data ? data.owner : undefined, enumerable: true, writable: true }, /* The date the label specification was last modified. */ "update": { enumerable: true, get: function() { if (data && data.update) { var strVal = data.update; return Date.parse(strVal); } } }, /* The date and time the label was last accessed, either by running p4 labelsync on the label, or by otherwise referring to a file with the label revision specifier @label. (Note: Reloading a label with p4 reload does not affect the access time.) */ "access": { enumerable: true, get: function() { if (data && data.access) { var strVal = data.access; return Date.parse(strVal); } } }, /* An optional description of the label’s purpose. */ "description": { value: data ? data.description : undefined, enumerable: true, writable: true }, /* Options to control behavior and storage location of labels. - locked or unlocked: If the label is locked, the list of files tagged with the label cannot be changed with p4 labelsync. - autoreload or noautoreload. For static labels, if noautoreload is set, the label is stored in db.label, and if autoreload is set, it is stored in the unload depot. This option is ignored for automatic labels. Storing labels in the unload depot can improve performance on sites that make extremely heavy use of labels. */ "options": { value: data ? data.options : undefined, enumerable: true, writable: true }, /* An optional revision specification for an automatic label. If you use the # character to specify a revision number, you must use quotes around it in order to ensure that the # is parsed as a revision specifier, and not as a comment field in the form. */ "revision": { value: data ? data.revision : undefined, enumerable: true, writable: true }, /* A list of depot files that can be tagged with this label. No files are actually tagged until `p4 labelsync` is invoked. Unlike client views or branch views, which map one set of files to another, label views consist of a simple list of depot files. */ "view": { value: data ? data.view : undefined, enumerable: true, writable: true }, /* If set, restricts usage of the label to the named server. If unset, this label may be used on any server. */ "serverID": { value: data ? data.serverID : undefined, enumerable: true, writable: true } }); } module.exports = LabelCommand;
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#1 | 19553 | swellard | Move and rename clients | ||
//guest/perforce_software/helix-web-services/main/source/clients/2016.1.0/javascript/lib/models/label_command.js | |||||
#2 | 19169 | tjuricek | JavaScript Client SDK jobs CRUD test, with supprt for "additionalProperties" in the swagger definition. | ||
#1 | 19053 | tjuricek |
Rebuild JavaScript Client SDK. The JavaScript client now is a "typed" approach that tends to be similar in approach to the other clients, based on the swagger definition for the platform version. Importantly, client SDK tests are individual scripts (that run under node) that are actually controlled via TestNG. This approach now lets us use a consistent test reporting format so we can at least collect reports from each of the jobs. The documentation is still in progress, that I want to validate as the tests are generated. |