Define subversion repository

Subversion repository can be defined by choosing the subversion menu item from the repository menu as follows:

Unable to render embedded object: File (subversion1.png) not found.

If you cannot find the Subversion menu item, it probably means that Subversion plugin has not been configured on plugin management page.
All text properties of Subversion repository can be defined as dynamic string.

Handling https and svn+ssh schema

To connect to Subversion repository with https and svn+ssh schema, you'll need to permanently accept the Subversion server's certificate from the command line before running QuickBuild. The detailed step is:

1. Login to the build machine as the user that will be used to launch QuickBuild process.
2. Connect to your Subversion repository using Subversion command line, and if the server asks for whether or not to save credentials for subsequent usage, choose "yes".
3. Make sure that subsequent Subversion command does not prompt for username and password.
4. Start QuickBuild process.

Checkout from multiple urls

QuickBuild 2.0 removes module definition for Subversion repository to keep simple things simple, complex things possible. In most cases, checking out from a single url is sufficient. However, checking out from multiple urls is still possible, you just need to define multiple Subversion repositories pointing to desired url and to add corresponding checkout steps to check them out.

Things get a bit complex if these urls are pointing to the same Subversion SCM repository, and you want to make sure that these checkouts are performed against the same repository revision. To do this:

1. Define a top level Subversion repository covering all urls you want to checkout. Let's assume the name of repository is top, the destination path property of this repository is not important as it will not be used for actual checkout.
2. Define the property snapshot taking script (can be found in advanced settings of a configuration) as below:

   var topRepos = current.getRepository("top");
   topRepos.takeSnapshot();
   current.getRepository("repository1").setRevision(topRepos.getRevision());
   current.getRepository("repository2").setRevision(topRepos.getRevision());
   

   Here repository1 and repository2 represents the repositories responsible for checking out codes.

External support

If ignore externals option is not checked, QuickBuild will checkout specified url together with any external definitions. However, it does not detect changes for external urls, that is, the isChanged() method for the repository does not return true even if there are new checkins made into the externals. There are two approaches to get around this:

1. If you only want to detect changes from externals, and trigger the build if externals are changed.
   1. Keep ignore externals unchecked for the subversion repository.
   2. For each external url, define a corresponding Subversion repository in QuickBuild, the destination path property is not important as these repositories will only be used for changing detection. No checkout will be done for these repositories.
   3. Modify the build necessary condition to detect changes from these repositories. For example, if the main Subversion repository is defined as repository1, and it has two externals, defined as external1 and external2, the build condition can be defined as:

      current.getRepository("repository1").isChanged() || current.getRepository("external1").isChanged() || current.getRepository("external2").isChanged()
      

      This approach has a limitation: although it can detect changes from externals and trigger the build, the external changeset does not appear in the [build changes] tab. The next approach addresses this.

2. If you want to detect changes from externals, and trigger the build if externals has changed. Besides this, you also want changeset of externals appear in the [*build changes*] tab together with the main repository
   1. Check the option ignore externals of the main Subversion repository. That is, the main Subversion repository will no longer be responsible for external checkouts.
   2. For each external url, define a corresponding Subversion repository, and add steps to checkout these repositories together with the main repository. The destination path property for these external repositories should be well defined, so that the final checkout directory structure looks the same as the directory structure when externals are enabled to checkout.
   3. Modify the build necessary condition to detect changes from these repositories. For example, if the main Subversion repository is defined as repository1, and it has two externals, defined as external1 and external2, the build necessary condition can be defined as:

      current.getRepository("repository1").isChanged() || current.getRepository("external1").isChanged() || current.getRepository("external2").isChanged()
      

Proof build support

For general concept of proof build, refer to proof build. Here we explain how to set up Subversion repository to support proof build. Following are necessary steps:

1. Edit the Subversion plugin setting and set the property subversion executable path to a dynamic string as:

   ${node.getAttribute("svnPath")}
   

   This tells QuickBuild to use value of the attribute "svnPath" defined at each grid node (including user agent) as Subversion may be installed at different locations for different nodes. Developers should define this user attribute at their agent tab to reflect their Subversion installation.

2. Edit the Subversion repository, and set the working copies property to a dynamic string as:

   ${node.getAttribute("svnWorkingCopies")}
   

   This tells QuickBuild to use value of attribute "svnWorkingCopies" defined at each user agent an defining location where to collect uncommitted changes as the work area paths may be different for different users. Developers should define this user attribute at their agent tab based on their development environment. A sample screen to define this attribute is as following:
   Unable to render embedded object: File (workingcopies.png) not found.
   More than one work area directory can be specified as value of the attribute as long as they do not overlap. The user agent will collect user's local changes (uncommitted change) recursively in the work area directory(s) and send them to QuickBuild server to patch the content checked out by the Subversion repository at the time of running the build.

3. If your team uses username/password to access Subversion, you will need to define username of the Subversion repository as following:

   ${node.getAttribute("svnUser")}
   

   This tells QuickBuild to use the value of attribute "svnUser" defined at each grid node (including user agent) as the account used to access Subversion (it may be different for each node). Developers should define this attribute at their agent tab to reflect their actual Subversion accounts.
   In this case the password property should also use dynamic string just like the username property.