@Dean Yu here
Using @HEAD achieves the desired result of ensuring a checkout always grabs the latest revision, however the current SVN plugin has one glaring flaw with this - the "HEAD" revision number is not assigned to the Jenkins SVN_REVISION property / environment variable. Consequently you end up in a situation where your checkout is done at a certain revision and that revision is not easily addressable / referenced elsewhere in the project (e.g.: in the build label, for example). Similarly this makes it difficult, if not impossible, to propagate the same revision number to downstream jobs. Sure, you can configure the downstream jobs to use @HEAD as well, but this prevents you from ensuring a set of jobs runs against the same revision number.
Put another way, using this workaround is incompatible with the Parameterized Trigger Plugin because the revision number that gets propagated to downstream jobs is incorrect.
Also, I just exploited another bug with this pattern. Since the SVN plugin triggers from a time stamp, you end up with redundant executions of jobs using this pattern. The use case goes something like this:
- Commit a change to the repo
- Wait until the Jenkins job triggers
- While the job is waiting in queue, commit another change to the same project
- A second instance of the job now enters the queue
- when the first instance of the job begins, it will update to the head revision, grabbing both changes
- when the second instance of the job begins, it looks at the current checkout and sees no changes (because there are none) but the build is still executed
Luckily the revision logs associated with the first execution does appear to show both change sets, so at least that information is consistent.