The version of the tek42 library we use probably doesn't support this at all, but we had branched it ourselves quite a while ago because the maintainer wasn't answering our calls regarding outstanding bugs. It's currently sitting with the rest of our source code, so we can modify it as we please.

I imagine we would need to allow a user to specify a shelved changelist or maybe a list of shelved changelists to pull down, probably through a job parameter. Does that sound like what you had in mind?

Yes, that's pretty much what I had envisioned. I would think min requirement would be to support one shelved changelist in the p4 configuration, and ensure this could be expressed as a token to be resolved from a build job parameter. I hadn't through through the idea of supporting multiple changelists. I suppose that would be possible. My concern would be that one might need to add extra logic to support the edge case that is a conflict in the multiple changelists, as the plugin would have no idea how to resolve it.

The main use case I would be trying to solve is where a developer in their local workspace has one changelist they are ready to check in, but in order to sanity test it, they could shelve that changelist and manually run a hudson build referring to the shelved changelist to verify it works outside of their local environment before committing it.

Quite frankly, I only have very cursory experience with this functionality, but could envision taking advantage of it and integrating it into our reg dev process if could be easily encorporated this plugin and as easy to use as the current plugin functionality (For example, I love how you make specifying workspaces so easy, creating them if they don't exist...)

As I get more experience with this functionality, I will add any additional comments I might have from my learning.

Thanks.

Sounds good. When I can find the time, I'll start looking into adding shelve functionality to the tek42 libraries we're using, then we can go from there.

OK, had a bit more time to work out the use case with some colleagues. What we are looking for is for the perforce-plugin to support the following command line equivalent:

p4 unshelve -s changelist [-f]

Details on the command can be found here: http://www.perforce.com/perforce/doc.current/manuals/cmdref/unshelve.html

The perforce plugin should behave as it always does, specifying a perforce client workspace and ensuring a p4 sync of that workspace prior to executing the build.

The additional work would be to support an additional option to specify a shelved changelist, and if specified, after syncing the workspace, the p4 unshelve -s changelist command would be run to bring down the pending changes and the perform the build. The -f option to that command would force an overwrite of any files with write access – not certain if that also needs to be an option to specify, or if we want to default the behavior.

A couple of additional thoughts on this:

1. the perforce-plugin is responsible for listing the changes since the last build – Might make sense to include in that set of changes in pending shelved changelist, and somehow indicate or highlight the changelist is pending/shelved.

2. upon completion of the build, there will be open files in the active perforce workspace. Need to determine the correct behavior to clean that up. Might make sense at the end of the build to discard those changes, and revert the workspace back prior to picking up the shelved changelist. Optionally, there was a suggestion that a user might want to indicate in the plugin confguration to commit the pending changlist if the build succeeds. That sounds cool but might be an V2 of the implementation as it might require a bit more work.

Regarding vbuzzsaw's comment:
"2. upon completion of the build, there will be open files in the active perforce workspace. Need to determine the correct behavior to clean that up. Might make sense at the end of the build to discard those changes, and revert the workspace back prior to picking up the shelved changelist. Optionally, there was a suggestion that a user might want to indicate in the plugin confguration to commit the pending changlist if the build succeeds."

The main use case we expect this functionality to be used for would be for a user to test their code changes by building and / or testing them on a central build / test engine prior to checking their code in.

If this is so, we'd expect the default behavior is to leave the shelved files checked out so that the user can determine based upon the result of the build/test whether to check them into the codeline or not. Reverting the codeline would not be the thing to do in this case, since the changes would be lost. An option to check-in automatically might be useful.

The user would then need direct access to the build machine, and the perforce user that hudson is running under. Reverting the hudson workspace is necessary so as not to pollute subsequent builds. Any commits (that aren't automatic) should be done by the user in their own workspace.

As I understand it, unshelving a changelist, then reverting the open files does not delete the shelved changelist. It will only return the workspace to the state it was at before the unshelving occurred, which is exactly what we want.

Regarding rpetti's comment - You are correct. Reversion on the build machine is the correct default behavior.

Has anyone looked in to this yet?

Not yet, unfortunately.