Hi Jack,
Nice to see some attention from accurev themselves. Yes, my name's all over many of the recent changes as I did a number of bugfixes/improvements to make it "work for my needs" (and hopefully others' needs too). I spent quite a while with my colleague Martin McAuley and accurev support working out a way of making the build process reliable (answer: avoid doing an accurev login unless logged out) and suitable for use with our internal build labelling/packaging infrastructure, as well as working around a memory leak issue (I'm not sure that one is entirely fixed, but it's no longer causing problems).
When you use the Accurev GUI to show the streams within a depot, unless you've hidden all the snapshots, the GUI takes /ages/ to display anything, and just as long to refresh after you've done anything with it - it makes the GUI fairly unusable as it's doing (and re-parsing) a "show streams" commands each time.
I think that it also impacts on server performance and the time it takes to do various other commands - certainly, we found that general performance improved after I "remove stream"ed about 65000 snapshots in the depot we're working in (accurev's philosophy of "snapshots are lightweight, you can create as many as you like", which is used to negate any "why do I need to create a snapshot to do this" issues, is clearly not entirely true!).
However, this would certainly qualify as low-hanging fruit - I reckon it'd only take an hour or two, once you've got the general modify/build/test cycle sorted out that is (which could take a little longer).
I would also strongly recommend sorting out JENKINS-10937 as well on that basis - it's a definite bug that I introduced due to a lack of testing (I don't use workspaces on my Jenkins setup as I use many slaves, and I've also found that "accurev update" is not 100% reliable, hence I just brute-force a populate instead) and it should be easy to fix.
As for "why are we doing a show streams" command in the first place: It's because of accurev's stream hierarchy/inheritance model - Jenkins needs to know if, were it to populate a new working area, it would get a different set of files to the last time it did so. As a promote to a parent stream can (and often will) affect child streams, Jenkins needs to also check the history of the parent stream. It was the performance problems with running these commands that lead to the "ignore parent changes" option being implemented, as that significantly reduces the amount of work done too.
I guess the short answer to "why" is "because the accurev CLI didn't provide a good way of doing this", and hence we're stuck with it (as not everyone runs the latest version, especially once one has been bitten by major blocking issues on latest versions before).
Looking forward, I'd like to see the plugin moving to the "new" Jenkins VCS-plugin API (it's no longer new, it's just newer than the API we're using), and making more use of accurev transaction numbers (if accurev had always supported a "populate this directory X from that stream Y up to transaction number Z" operation, much of this messing around with snapshots would not have been necessary, but the accurev server side hasn't always supported that and hence the plugin can't use it without introducing compatibility issues) in order to sort out builds missing triggering changes from history reports etc (basing things on time is unreliable and inaccurate, especially on MS Windows where keeping clocks accurate within 5 seconds is a challenge).
Regards,
Peter
Would need to add yet another boolean tick-box option in the configuration to enable/disable this feature. This would only be shown if the snapshot feature was enabled.
If stream removal was enabled, we'd need to do the command immediately after we'd created the snapshot, before we do the populate.