The AccuRev "populate" command used in the plugin doesn't specify a particular version. It's unclear whether it's atomic - if other promotions occur while the populate is in process, they may or may not be incorporated.

I suggest that the plugin should query for the latest version and then populate using that version, to ensure that the populate is atomic.

The plugin currently retrieves the current AccuRev change history at the end of the populate. If promotes into the stream happened during the populate, they will be in the history, but may or may not be part of what's been populated. The history is inaccurate, I think.

If the plugin did the populate using a specific version, it then could check the change history for the same version.

If plugin stored the version in a known place, such as a file in the root of the Hudson workspace, ant scripts and other processes could use it to perform AccuRev commands, such as snapshotting or promoting. In our usage, this would not be part of the same job that did the populate - there are follow-on regression-testing jobs that use the same workspace. This would provide a workaround for the lack of a snapshot capability (see issue Hudson-5196).

These suggestions may have unintended side-effects, such as poorer "populate" performance... I'm no AccuRev expert.

(I don't seem to have permission to comment on issues... is that intentional?)

Thanks,
-Ed Staub