I would suggest that you raise this as a separate issue, outline the problem you have, and ideally suggest a way of fixing it.
If you can identify a way whereby the plugin can poll to see if there are new changes more efficiently then that news would be welcomed.
Ideally, if you register on GitHub, fork the jenkinsci-accurev plugin code, work on an update, push your changes onto github, and then do a "pull request", you stand a very good chance of having your changes accepted (and even if you don't, you can build your own plugin using Jenkins).

Basically, AccurevSCM.java does nearly everything, and its pollChanges(...) method gets asked if it should do a new build or not.
At present, that code uses the same algorithm that's used to determine what the changes are to determine if there are changes. If you can find a better method, say so (but in a new issue) - all we need to do is answer the question "Given that the last build happened at <datetime>, do we need to do another build now?", but we need to be able to answer that question without a workspace.
If you know of an accurev command (or series of commands) that'll do that (in an efficient manner), please raise an enhancement request saying what it should do instead (however, as far as I am aware, accurev's client API isn't capable of doing this in an efficient or reliable fashion).

I guess you are right, there is no way to do this without a workspace. I think this is an issue to accurev and not to Jenkins, maybe I should talk to them.
Anyway, thanks again for the fix.

One last thought, can the hist command be done without a specific transaction type (i.e. -k) and still inform us if there was a change?

Yes and no.
If you ommit the -k parameter when doing "accurev hist .... -t now.1" then accurev just tells you the last transaction, rather than the last of each type.
This is fine if you want to trigger a build no matter what transaction type happened, but useless if you don't want to trigger a build regardless of transaction type.
(what's really needed is a "-t" option to take a snapshot name as a starting or ending point, or a transaction number, or one of many other options for querying this sort of thing that pretty much all other VCSs have supported since their initial release).

It wouldn't be very difficult to change the plugin behaviour so that this "only react to certain transaction types" behaviour was conditional and could be switched off such that the "-t" parameter wasn't used, but it would have to be configurable behaviour (you would want it switched off, and new users might want it switched off, but existing users should have it unchanged until they configure it otherwise).

I would suggest that, if you're using Jenkins and you've got a large accurev setup and you get actual support from AccuRev Plc (we have "support" as well but, as far as I can see, this is mainly a one-way relationship) then you should strongly consider getting involved with the plugin.
If you're familiar with Java, it'll probably take you about a day or two to build your own custom version of the plugin (both Jenkins and its plugins can all be built using Jenkins...).
You can then make the improvements you want to see happen and share them with your fellow accurev-sufferers

Well, I'm mainly a C guy, so Java is not my strong side.
In addition for the updated plugin besides of the initial customization will have to support future changes to Jenkins, plugin API changes etc. and I can't commit to that. I think I will work with the current configuration.