Yeah, that rename was a bad call on my part, but I don't think automatically deleting the contents of the workspace is a good solution. There are many people out there with complex setups, and a change like what is being proposed could seriously break them.

The plugin is compatible with Hudson's "Wipe Out Workspace" function, so that can be used instead of doing it automatically.

I hope you will re-consider. The problem is not limited to our exact scenario. You can readily reproduce this problem by starting a job with one client spec name and then changing your mind and modifying the client spec name in job config. Perforce plugin will happily create the new client spec, overlay it over existing files and lots of fun ensues as the user tries to figure out why Perforce has gone nuts.

Hudson's "Wipe Out Workspace" function is not really a solution for this. In many cases the workspaces are far too large to be blowing them away on every build. Ours are 3GB+. We'd like to be able to tell Hudson to use the nuclear option only when necessary.

I am having a hard time imagining a scenario where the user would configure Perforce plugin to manage the client spec for them and at the same time is doing something funky in the workspace such that letting the plugin blow away their workspace is not a good idea. However, if that is indeed a concern, perhaps an explicit option "let hudson manage my local workspace" could be added.

You'd like to be able to tell hudson to nuke the workpsace only when necessary, but you don't want to use the "Wipe Out Workspace" function? I'm not sure I follow. This is exactly what it does.

I'm not referring to the Perforce Plugin option that wipes out the workspace every time, but the function inside Hudson itself that lets you wipe out the workspace when you need to. On the job page, click the 'Workspace' option on the left, and a "Wipe Out Workspace" option will appear below it. This is what I'm referring to. Is there a reason it won't work in your case?

As an example of a project that will get screwed up in this instance, some people run their jobs in the same workspace root using the same client. A minor mistake in the configuration could result in the workspaces getting wiped for every job.

Another example would be when files not in perforce are also needed in the workpsace root for building, such as code from other SCMs or 'secret' files such as passwords that people don't want to keep in perforce for security reasons.

The one-time wipe function works if you assume that the user realizes that they need to invoke the wipe function. It certainly wasn't obvious to me that Perforce plugin wouldn't handle that. I understand that there are probably some users out there that would need a way to tell Perforce plugin to do less for them, but for majority of users, the setup is simple. The workspace is completely drawn from source control and when they tell Perforce plugin to manage their client spec for them, they assume that it will manage the local workspace as well.

In general, it is not considered a good practice to map Perforce client to a directory that holds other content. Perhaps Perforce plugin should let user define a sub-directory under workspace where Perforce client should map to?

I hope there is a way to make this work better for the majority of users.

I'm just not keen on letting the plugin delete the entire workspace without user intervention. If you think of a better way to handle this without deleting the entire thing without confirmation, then by all means let me know, or better yet supply a patch.

Ideally, the plugin should only delete the files that are being tracked by the old workspace, and leave all other files intact. I think this could be possible by syncing using the old client spec to file revision #0, but I'm not sure. It's probably worth looking into.