For each job on Hudson, Hudson allocates a unique "workspace directory." This is the directory where the code is checked out and builds happen. Normally you should let Hudson allocate and clean up workspace directories, but in several situations this is problematic, and in such case, this option lets you specify the workspace location manually.

Once such situation is where paths are hard-coded and the code needs to be built on a specific location. (and you can find one such discussion here.) While there's no doubt that such a build is not ideal, this option allows you to get going in such a situation.

Another situation where this is useful is when you are using the free-style project type not to perform a software build, but execution of a certain batch task, perhaps as a cron replacement. In such case, you can use this option to map the relevant directory as the workspace, so that people can look at files through the Hudson web UI, and you can kick relevant commands more easily.

If you are in a distributed build environment, unless you tie a job to a specific node, Hudson may still move around jobs to different slaves. Sometimes this is desirable, sometimes this is not. Also, you can map multiple projects to have the same workspace, but if you do so, make sure concurrent executions of those jobs won't have nasty interferance with each other.