It appears the problem is this:

Line 449 SubversionSCM.java
if(svnLocations.length==1) {
Long rev = revisions.get(svnLocations[0].remote);
if(rev!=null) {

svnLocations[0].remote contains http://myserver/svn/repo@HEAD, and revisions[0] key contains http://myserver/svn/repo hence the value of the map "rev" is never found and is always null.

The root of the @HEAD being set in svnLocations[0].remote seems to happen in:

Line 2090 in SubversionScm.java here:

public ModuleLocation(String remote, String local) {
this.remote = Util.removeTrailingSlash(Util.fixNull(remote).trim());

String remote = http://myserver/svn/repo@HEAD, I believe it should search for the last @ char and remove everything after it?

I've made a patch that appears to resolve the issue, I've changed the constructor previously mentioned on line 2090 to this:

@DataBoundConstructor
public ModuleLocation(String remote, String local) {
String tmpRemote = Util.removeTrailingSlash(Util.fixNull(remote).trim());

// Look for an @ char in the case of http://svnserver/repos@HEAD or
// http://svnserver@rev and remove @rev/@HEAD as only the first part of the URL is used in
// the map for pulling out the revisions.
int atPos = tmpRemote.lastIndexOf('@');
if(atPos!=-1)

this.remote = tmpRemote;
this.local = fixEmptyAndTrim(local);
}

Adding a real patch from svn.

After more testing it seems this patch breaks the @REV functionality as the edited URL is the one used to do the checkout (I.e the url http://myserver/svn/repos is always used).

Not sure what the best way to fix this is? Perhaps not using a map for the revisions, or adding a new remotePlain field to the ModuleLocation class?

Updated patch that works in all cases (no revision, revision and keyword such as HEAD).

Attempted to keep code changes down by just calling another function inside map.get(), e.g map.get(getPlainUrl()).