@tonylampada2
I like your suggestion. However, to help isolate the impact of such configuration options it may be safer to provide them at the job level rather than in the global Jenkins configuration.

Also, I think there could be a 4th option as well: by revision. For example, if someone uses a single repository for all their projects, there is one global revision number shared across all projects and this revision number is guaranteed to be unique. Therefore, building by revision is effectively the same as build by timestamp and yet it avoids the problem of clock skew.

@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.

Amendment
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:

1. Commit a change to the repo
2. Wait until the Jenkins job triggers
3. While the job is waiting in queue, commit another change to the same project
4. A second instance of the job now enters the queue
5. when the first instance of the job begins, it will update to the head revision, grabbing both changes
6. 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.

I just recently exploited yet another SVN revision number bug that is kind of tangientially related to this one.

Correction - I've added a new enhancement request for the SVN plugin that may partially circumvent some of the use cases people are discussing here. See JENKINS-18907 for details.

NOTE
Upon further review, I think the failure condition I was describing in my earlier comment may in fact be indicative of the different SVN revision numbers available in a typical working folder (e.g.: last change revision vs latest revision). As such if the other improvement request I recently created were to be implemented this problem may be avoidable. By leveraging the "latest revision" instead of the "last change revision" the @HEAD "workaround" mentioned here just may work.

If svn:externals are used, the revision checked out will be the Last Changed Rev and not HEAD.