Working with Subversion

Version 22 by Lubos Pochman
on Sep 07, 2008 19:06.

<< Changes from 21 to 22
compared with
Current by Robin Shen
on Sep 29, 2009 13:19.

 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 17 changes. View first change.

 h1. Define subversion repository
 Subversion repository can be defined by choosing the subversion menu item from the repository menu as follows:
 !define-svn-repository.png!
 If you cannot find the Subversion menu item, it probably means that Subversion plugin has been disabled on [plugin management|Plugin Management] page.
  
Subversion repository can be defined by choosing the subversion menu item from the repository menu as below:
  h1. Specify svn command location
 QuickBuild utilizes the svn command to interact with Subversion. If this command is not in system path, you will need to specify location of the command by configuring Subversion plugin as below:
 !configure-svn-plugin.png!
  
!subversion1.png!
  Further more, svn command location can be specified on a per-node basis by following below steps:
 # Open Subversion plugin setting page and define the svn path property as:
 {code}
 ${node.getAttribute("svnPath")}
 {code}
 # For each node that does not have svn command on system path, define the user attribute _svnPath_ to point to the actual svn command location like below:
 !svn-path.png!
 For user agent node, this user attribute can be defined [follow this guide|manage user agent#define user attributes].
  
If you can not find the subversion menu item, it is most probable that subversion plugin has not been configured at [plugin management|Plugin Management] page.
 All text properties of subversion repository can be defined as dynamic string.
  Please note that in above example, the _svnPath_ user attribute is just for demonstration purpose. You can use any other user attribute name.
  
h1. Handle _https_ and _svn+ssh_ schema
  h1. 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:
 # Login to the build machine as the user that will be used to launch QuickBuild process.
 # 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".
 # Make sure that subsequent Subversion command does not prompt for username and password.
 # Start QuickBuild process.
  
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:
 # login to the build machine as the user which will be used to launch QuickBuild process
 # 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"
 # make sure subsequent subversion commands does not prompt for user name and password
 # start QuickBuild process
  
 h1. 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.
  
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:
 # 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
 # For each child repository (the repository responsible for checking out desired url), define the _revision to checkout_ as below:
  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:
 # 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.
 # Define the property _snapshot taking script_ (can be found in advanced settings of a configuration) as below:
 {code}
${getConfiguration().getRepository("top").revision}
  var topRepos = repositories.get("top");
 topRepos.takeSnapshot();
 repositories.get("repository1").setRevision(topRepos.getRevision());
 repositories.get("repository2").setRevision(topRepos.getRevision());
 {code}
# 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.
  Here _repository1_ and _repository2_ represents the repositories responsible for checking out codes.
  
 h1. 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:
 # *If you only want to detect changes from externals, and trigger the build if externals are changed.*
## Keep _ignore externals_ as *unchecked* for the subversion repository
 ## 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.
 ## 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:
  ## Keep _ignore externals_ *unchecked* for the subversion repository.
 ## 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.
 ## 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:
 {code}
getRepository("repository1").isChanged() || getRepository("external1").isChanged() || getRepository("external2").isChanged()
  repositories.get("repository1").isChanged() || repositories.get("external1").isChanged() || repositories.get("external2").isChanged()
 {code}
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|2.3 Build Changes] tab. The next approach addresses this.
 # *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*|2.3 Build Changes]* *tab together with the main repository*
 ## Check the option _ignore externals_ for the main subversion repository. That is, the main subversion repository will no longer responsible for external checkouts
 ## 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.
 ## 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:
  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|Working with Changes] tab. The next approach addresses this.
 # 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|Working with Changes] tab together with the main repository
 ## Check the option _ignore externals_ of the main Subversion repository. That is, the main Subversion repository will no longer be responsible for external checkouts.
 ## 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.
 ## 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:
 {code}
getRepository("repository1").isChanged() || getRepository("external1").isChanged() || getRepository("external2").isChanged()
  repositories.get("repository1").isChanged() || repositories.get("external1").isChanged() || repositories.get("external2").isChanged()
 {code}
  
h1. Proof build support
  h1. {anchor:proof build}Proof build support
  
 For general concept of proof build, refer to [proof build|3. Working with Proof Build]. Here we explains how to set up subversion repository to support proof build. Below are necessary steps:
 # Edit the subversion plugin setting and set the property _subversion executable path_ to a dynamic string like below:
 {code}
 ${node.getAttribute("svnPath")}
 {code}
 This tells QuickBuild to use value of the attribute "svnPath" defined at each grid node (including user agent) as subversion may installed at different location for different node. Developers should define this user attribute at their agent tab to reflect their subversion installation.
 # Edit the subversion repository, and set the _working copies_ property to a dynamic string like below:
 {code}
 ${node.getAttribute("svnWorkingCopies")}
 {code}
 This tells QuickBuild to use value of attribute "svnWorkingCopies" defined at each user agent when collect uncommitted changes as the working copy paths of different user may be different. Developers should define this user attribute at their agent tab according to their development environment. A sample screen to define this attribute is like below:
 !workingcopies.png!
 More than one working copy directories can be specified as value of the attribute as long as they are not overlapped. The user agent will collect user's local change (uncommited change) recursively in the working copy directories and send to QuickBuild server to patch the content checked out by the subversion repository at the time of running the build.
 # If your team use user name/password to access subversion, you will need to define user name of the subversion repository like below for the repository:
 {code}
 ${node.getAttribute("svnUser")}
 {code}
 This tells QuickBuild to use value of attribute "svnUser" defined at each grid node (including user agent) as the account used to access Subversion may be different for different node. Developers should define this attribute at their agent tab according to reflect their subversion accounts.
 In this case the password property should also use dynamic string just like the user property.
  For general concept of proof build, refer to [proof build|Working with Proof Build]. Here we explain how to set up Subversion repository to support proof build.
  
 h3. Test proof build as administrator
 Since proof build set up is a bit tricky, we first set up proof build for the administrator account and make sure it works before we proceed to enable it for all developers. To set up proof build for administrator, please follow below steps:
 # Login as administrator and download user agent by switching to _My_ tab.
 # Install and start user agent on your own desktop. For testing purpose, please start the agent as a foreground process. On windows, this can be done by running _agent.bat_; on Unix platforms, this can be done by running _agent.sh console_
 # Set up a test configuration on QuickBuild server, and define a Subversion repository and enable the proof build option like below:
 !enable-svn-proofbuild.png!
 # Make sure the svn command exist in the system path of both server machine and your desktop. If not, please follow the section _Specify svn command location_ to tell QuickBuild location of svn command.
 # Add a _repository/checkout_ step into step execution graph and have it checkout from the repository defined above.
  
 Now proof build has been enabled for your account, please try to checkout and edit some files in working copies specified above, and then run the test configuration. If set up correctly, your local change will be picked up and reflected in the build result. A local change tab will also appear to display your uncommitted changes after build finishes. Your uncommitted changes will be committed automatically if build is successful.
  
 h3. Enable proof build for all developers
 Now that we have a concept of how proof build works. In order to get proof build works for all developers, we need to parameterize various proof build properties, so that different properties can be used for different developers. To do this, you will need to:
 # Define configuration variables like below:
 !svn-variables.png!
 # Script various properties in proof build section to make use of above variables like below:
 ||Property Name||Property Value||
 |Working Copies|$\{vars.get("workingCopies")\}|
 |User Name|$\{vars.get("userName")\}|
 |Password|$\{vars.get("password")\}|
 |Update Condition|vars.get("update").asBoolean()|
 |Commit Condition|build.successful && vars.get("commit").asBoolean()|
 |Commit Comment|$\{vars.get("comment")\}|
  
 In this way, various proof build properties will be prompted when your developer run the build. Once they've been input by your developer for the first time, the values will be remembered for subsequent triggers for that user.
  
 At last we suggest to change run mode of the proof build configuration so that multiple builds can run concurrently in order to get fast feedback in case multiple developers requesting proof build in the same time. Run mode of the configuration can be changed by editing basic setting of the configuration.