Overview
Git, Mercurial and other distributed software configuration management (SCM) solutions enjoyed great success over this past year, but the large majority of developers still use the classic, de facto standard -- Subversion. Now hosted by the Apache Software Foundation, Subversion 1.7 was released last year with significant improvements. Due to its widespread acceptance, we can rely on a large user base for the foreseeable future. As it does for other SCM solutions, Jenkins has a dedicated plugin to support Subversion, one of the most widely used SCMs. It is part of the core release and provided by default with your Jenkins installation files.
Requirements
The Jenkins Subversion plugin uses SvnKit as the subversion client and doesn't require a native client to be available on the host. Setting up a CI server with Jenkins and Subversion is limited to a very minimal installation process: just run the Jenkins WAR and you're done.
How To ...
When configuring a job with Jenkins Subversion plugin, Jenkins will try to validate the repository URL that was entered. As the repository may require authentication, Jenkins will ask you to enter credentials. Those credentials are stored on your first valid authentication, so it won't bother you for them on your next access. To change the credentials used to access a repository, you can navigate to https://JENKINS/scm/SubversionSCM/enterCredential. Please note: in some circumstances, setting authentication may be a more complex process, especially if you use Kerberos or client certificates.
A Jenkins SCM plugin will:
- detect changes in the SCM and trigger a new build if needed
- put the workspace in the desired state for a build to start
The Jenkins Subversion plugin can poll changes from one or multiple repositories, and do some fine filtering for incoming changes. For example, you can select a subset of your repository using include/exclude rules, or filter by user or commit message to ignore some commits if you use automated tools that commit irrelevant changes in the repository.
Multiple repositories, inclusion and exclusion rules can be used to focus on a precise set of changes you want your continuous integration server to monitor. As combinations may be complex, you're encouraged to progressively introduce such rules to exclude irrelevant commits.
When a commit is detected to match all the configured rules, a build is triggered. But this will require your Jenkins server to actively poll Subversion for changes. If you already have read 
The Jenkins Subversion plugin exposes the current state to the build as an environment variable, like $SVN_URL and $SVN_REVISION. You can use them in your build script to improve the metadata of the generated artifact. On a Java project you can, for example, include the Subversion URL and revision in your MANIFEST to easily retrieve the source code for a JAR.
Use on DEV@cloud
The Subversion plugin is, of course, available on CloudBees DEV@cloud and can be configured to access either SVN repositories hosted by CloudBees or your existing repository hosted on SourceForge, Google Code or your own infrastructure as long as it is available on the Internet using http(s).
Relevant Documentation
You can read more about the Subversion plugin on the Jenkins wiki https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin
You can read more about Subversion in general in the SVN e-book available at http://svnbook.red-bean.com/
