/* The client workspace specification and its view. For more information see the [command reference](https://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_client.html). */ function ClientCommand(data) { Object.defineProperties(this, { /* The client workspace name, as specified in the `P4CLIENT` environment variable or its equivalents. */ "client": { value: data ? data.client : undefined, enumerable: true, writable: true }, /* The name of the user who owns the workspace. The default is the user who created the workspace. 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 time the workspace 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 that the workspace was last used in any way. (Note: Reloading a workspace 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); } } }, /* The name of the workstation on which this workspace resides. If included, operations on this client workspace can be run only from this host. If not set, access is allowed from any host. The hostname must be provided exactly as it appears in the output of p4 info when run from that host. This field is meant to prevent accidental misuse of client workspaces on the wrong machine. Providing a host name does not guarantee security, because the actual value of the host name can be overridden with the -H option to any p4 command, or with the P4HOST environment variable. For a similar mechanism that does provide security, use the IP address restriction feature of p4 protect. */ "host": { value: data ? data.host : undefined, enumerable: true, writable: true }, /* A textual description of the workspace. The default text is Created by owner. */ "description": { value: data ? data.description : undefined, enumerable: true, writable: true }, /* The directory (on the local host) relative to which all the files in the `View:` are specified. The default is the current working directory. The path must be specified in local file system syntax. If you change this setting, you must physically relocate any files that currently reside there. On Windows client machines, you can specify the root as null to enable you to map files to multiple drives. */ "root": { value: data ? data.root : undefined, enumerable: true, writable: true }, /* Up to two optional alternate client workspace roots. Perforce applications use the first of the main and alternate roots that match the application’s current working directory. Use the p4 info command to display the root being used. This enables users to use the same Perforce client workspace specification on multiple platforms, even those with different directory naming conventions. If you are using multiple or alternate workspace roots (the AltRoots: field), you can always tell which root is in effect by looking at the Client root: reported by p4 info. If you are using a Windows directory in any of your workspace roots, you must specify the Windows directory as your main workspace root and specify your other workspace roots in the AltRoots: field. */ "altRoots": { value: data ? data.altRoots : undefined, enumerable: true, writable: true }, /* A set of seven switches that control particular workspace options. See [Usage Notes](https://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_client.html#p4_client.usage) for a listing of these options. */ "options": { value: data ? data.options : undefined, enumerable: true, writable: true }, /* Options to govern the default behavior of p4 submit. * submitunchanged + All open files (with or without changes) are submitted to the depot. This is the default behavior of Perforce. * submitunchanged+reopen + All open files (with or without changes) are submitted to the depot, and all files are automatically reopened in the default changelist. * revertunchanged + Only those files with content, type, or resolved changes are submitted to the depot. Unchanged files are reverted. * revertunchanged+reopen + Only those files with content, type, or resolved changes are submitted to the depot and reopened in the default changelist. Unchanged files are reverted and not reopened in the default changelist. * leaveunchanged + Only those files with content, type, or resolved changes are submitted to the depot. Any unchanged files are moved to the default changelist. * leaveunchanged+reopen + Only those files with content, type, or resolved changes are submitted to the depot. Unchanged files are moved to the default changelist, and changed files are reopened in the default changelist. This option is similar to submitunchanged+reopen, except that no unchanged files are submitted to the depot. */ "submitOptions": { value: data ? data.submitOptions : undefined, enumerable: true, writable: true }, /* Configure carriage-return/linefeed (CR/LF) conversion. See [Usage Notes](https://www.perforce.com/perforce/doc.current/manuals/cmdref/p4_client.html#p4_client.usage) for a listing of these options. */ "lineEnd": { value: data ? data.lineEnd : undefined, enumerable: true, writable: true }, /* Associates the workspace with the specified stream. Perforce generates the view for stream-associated workspaces: you cannot modify it manually. */ "stream": { value: data ? data.stream : undefined, enumerable: true, writable: true }, /* A changelist number that sets a back-in-time view of a stream. When StreamAtChange is set, running p4 sync (when called with no arguments) updates the workspace to files at this changelist revision, instead of the head revision. You cannot submit changes (p4 submit returns an error) when StreamAtChange is set, because the workspace view no longer reflects the current stream inheritance. This field is ignored unless the Stream field is also set to a valid stream. */ "streamAtChange": { value: data ? data.streamAtChange : undefined, enumerable: true, writable: true }, /* If set, restricts usage of the workspace to the named server. If unset, use is allowed on master server and on any replicas of the master other than Edge servers. */ "serverID": { value: data ? data.serverID : undefined, enumerable: true, writable: true }, /* Specifies the mappings between files in the depot and files in the workspace. A new view takes effect on the next p4 sync operation. */ "view": { value: data ? data.view : undefined, enumerable: true, writable: true }, /* Restricts access to depot paths to a particular point in time. Files specified for the ChangeView field are read-only: they may be opened but not submitted. For example: `//depot/path/...@1000` Revisions of the files in the specified path will not be visible if they were submitted after the specified changelist number. Files matching a ChangeView path may not be submitted. */ "changeView": { value: data ? data.changeView : undefined, enumerable: true, writable: true }, /* By default clients are writeable. Specify readonly for short lived clients used in build automation scripts. Such clients cannot edit or submit files, but this should not be an issue in build scripts. Using writeable clients in build automation scripts can lead to db.have table fragmentation, which is used to track what files a client has synced. If you are experiencing such issues, use a read-only client instead. A readonly client is assigned its own personal db.have database table. The location of this table must first be specified by an administrator with the client.readonly.dir configurable. */ "type": { value: data ? data.type : undefined, enumerable: true, writable: true } }); } module.exports = ClientCommand;
# | 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/client_command.js | |||||
#3 | 19202 | tjuricek | Revised documentation for the Ruby Client SDK; removed obsolete methods and definitions, and restyled a lot of the tables. | ||
#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. |