Define subversion repository

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

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

If you can not find the subversion menu item, it is most probable that subversion plugin has not been configured at plugin management page.
All text properties of subversion repository can be defined as dynamic string.

Handle https and svn+ssh schema

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

1. login to the build machine as the user which 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 usages, choose "yes"
3. make sure subsequent subversion commands does not prompt for user name and password
4. start QuickBuild process

Checkout from multiple urls

QuickBuild 2.0 removes module definition for subversion repository for the reason of 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 add corresponding checkout steps to checkout them.

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, assume the name is top, the destination path property of this repository is not important as it will not be used for actual checkout
2. For each child repository (the repository responsible for checking out desired url), define the revision to checkout as below:

   ${getConfiguration().getRepository("top").revision}
   

3. Add a take snapshot step to take snapshot of the top repository, and add checkout steps to checkout from each child repository. Arrange them into a sequential step, and make sure the take snapshot steps comes before other checkout steps.

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 as 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 any 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, respectively defined as external1 and external2, the build necessary condition can be defined as:

      getRepository("repository1").isChanged() || getRepository("external1").isChanged() || 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 are changed. Besides this, you also want change set of externals appear in the [build changes] tab together with the main repository
   1. Check the option ignore externals for the main subversion repository. That is, the main subversion repository will no longer 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 with 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, respectively defined as external1 and external2, the build necessary condition can be defined as:

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

Proof build support

For general concept of proof build, refer to [proof build]. Here we explains how to set up subversion repository to support proof build. Here are necessary steps:

1. Connect your user agent to QuickBuild server. Refer to [3. Working with Proof Build] for details
2. Edit the subversion repository, and set the working copies property to contain the subversion working copy directories at your computer. You may specify more than one working copy directories as long as they are not overlapped. The user agent will collect your local change (uncommited change) recursively in these working copy directory and send to QuickBuild server to merge with the content checked out by the subversion repository at the time of running the build.
3. If subversion executable path at your computer is different from the QuickBuild server, you will need to define the subversion executable path as below when configure the subversion plugin:

   ${buildGrid.localNode.getAttribute("svnPath")}
   

   This tells QuickBuild to use value of the attribute "svnPath" at current node as subversion executable path. Now continue to define user attribute "svnPath" for each node in build grid to reflect the actual subversion path. You also need to define this attribute in your user agent like below:
   Unable to render embedded object: File (subversion2.png) not found.

4. If the user name/password to access subversion is different at your computer from the QuickBuild server, you will need to define user name (password is alike) like below for the repository:

   ${buildGrid.localNode.getAttribute("svnUser")}
   

   This tells QuickBuild to use value of attribute "svnUser" at current node as subversion user name. Now continue to define user attribute "svnUser" for each node in build grid to reflect the actual subversion user name. You also need to define this attribute in your user agent.

It is suggested that you update your working copy from subversion server before submitting a proof build, refer to [proof build] for the reason.