Workspace (client): Workspace or Clientspec (oldskewl) of the project. If the workspace specified does not exist, Hudson will create it.

Important Note: Hudson will likely change the root of this workspace to fit Hudson's installation. That means Hudson also automatically creates a workspace for each slave on every project. The hostname of the slave is appended to the end of the given workspace name to ensure that all workspaces are unique and don't collide across machines.

Important Note: If two jobs retrieve the same file into their workspace, these jobs must use a unique Perforce workspace. The reason is otherwise the Perforce server will lose track of the actual contents of the workspaces, leading to inaccurate workspace file versions. For example, if job1 and job2 use the same Perforce workspace, and both include file1, when the file1 is changed, a Perforce 'get latest' will only retrieve file1 into the first job (e.g. job1) that builds, it will not be retrieved into job2 unless you do a 'One Time Force Sync'.

Important Note: When Hudson creates a workspace, the workspace will contain only one view. This view maps the Depot Path to the root of the Hudson job's workspace directory. If Hudson uses an existing workspace that has only one view, it automatically changes the view in a similar way. This behavior can be disabled by the option, "Let Hudson Manage Workspace View. This will allow you to retrieve more than one depot into the workspace of a given job by providing your own list of views.

Let Hudson Manage Workspace View: For most cases, leave this checked. Hudson will update the workspace's view to match the project's settings provided below.

If unchecked, you must manage the workspace's view yourself. This is useful if, for this job, you need to checkout and build multiple projects from Perforce at once. (For those managing the workspace view themselves and looking for a starting point, the typical hudson view is: '//depot/[PROJECTNAME]/... //[WORKSPACENAME]/...' You'll notice this is slightly different from typical workspaces. The [PROJECTNAME] is not normally included.)

Views: This is the depot to client mapping in the same depot-client pair format as a standard Perforce workspace spec, with a couple of handy shortcuts added: the workspace name provided in the second of each pair is not actually used--the actual workspace name is always substituted. And, the second member of any pair may be ommitted which will result in an identity mapping being used.
If "Let Hudson Manage Workspace View" is checked the view entered here will overwrite the view in the existing client.

Typical examples that have the same meaning:
//depot/folder/... //workspace-name/folder/...
//depot/folder/... //anyplaceholder/folder/...
//depot/folder/...

Options: The Perforce client options to use. The default Perforce client values are noallwrite noclobber nocompress unlocked nomodtime normdir, and this plugin's defaults are noallwrite clobber nocompress unlocked nomodtime rmdir. The two differences are that clobber is on to overwrite writable files and rmdir is on to remove empty directories. This is a more useful default for an automated build workspace. See the Perforce p4 guide for more information.

One Time Force Sync: allows you to tell this plugin to do a 'p4 sync -f //...' which will make sure to pull down ALL files to the workspace, regardless if they have been sync'd before. Use this to get around problems where the Perforce workspace has become out of sync with the Perforce server. For most users, you should never need to worry about this.

Note: this is reset after it has been applied once.

First Changelist to Track: allows you to specify the first changelist to start recording build history from. If you are adding an existing project, with lots of history, to Hudson, this will prevent out of memory errors and your first build from having thousands of change records.

Note: this is reset after it has been applied once.