[JENKINS-20508] Select a build via SVN revision

[ghost]

Was pretty useful for my project and easy to implement. New feature used in my Jenkins installation for a weeks without issues.

[ghost]

Please ignore commit 6aecc12, this was for internal purpose only.

[cloudbees-pull-request-builder]

plugins » copyartifact-plugin #35 SUCCESS This pull request looks good

[jenkinsadmin]

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

[oleg-nenashev]

I'm afraid that you presume location and structure of SVN data without creating of any dependencies from Subversion Plugin. AFAIK, there's a long refactoring branch with many changes, so it may corrupt your approach after subversion-2.0 release.

The current approach is definitely bad. Maybe it is applicable to implement such extension inside Subversion plugin. @kutzi, what do you think about it?

[kutzi]

So from looking at this very superficially: this PR tries to parse the revision.txt created by the svn-plugin? Yes, that's a no go IMO. So we should either provide an extension point in svn-plugin - though I don't know how it should look like - or create a proper public API in the svn-plugin to access the revisions.

[oleg-nenashev]

I don't think we need a specific extension point in SVN. It seems to be a general case, so it makes sense to move it to Jenkins SCM abstraction or to external SCM_API plugin, which will provide an additional extension points to be extended in SCM plugins.

On the other hand, it may be applicable to add optional dependency to SVN plugin to directly extend Copy Artifact's extension. This plugin is very popular, so why not?

[daniel-beck]

I agree that the best solution (ensuring stability – then the issue of accessing internals wouldn't be that bad either) would be an @Extension(optional = true) and optional dependency to copyartifact in Subversion plugin.