Overview
Each project on your pulse™ server is used to build a single code line. The project's SCM configuration is used to define the location of the code line in your SCM server. This location is used for monitoring of the SCM for code changes, determining changes between builds, and checking out the project's source code during a build.
Supported SCMs
pulse™ currently supports the following SCMs:
| SCM |
Description |
| CVS |
Concurrent Versions System (CVS) is a popular open source SCM. |
| Git |
git is an open source, distributed SCM originally created by Linus Torvalds to manage the Linux kernel source tree. |
| Perforce |
Perforce is a commercial, multi-platform SCM made by Perforce Software. |
| Subversion |
Subversion is an open source SCM designed as a compelling replacement for CVS. |
Support for more SCM systems will be added in future versions of pulse™, in line with customer demand.
Configuring SCMs
SCM details for a project are initially configured during the add project wizard. This configuration may be changed at a later time at the "configuration" view for the appropriate project. Note that significant changes to the SCM details for a project may disrupt features such as detection of changes. If you do make a major change to the SCM details for a code line (e.g. by switching to a new SCM), it is probably best to configure a new project rather than reuse the same project.
Checkout Schemes
The checkout scheme defines two things:
- Whether a clean working copy is used for each build
- How the project source code is obtained from the SCM.
Details of the available schemes, along with their advantages and disadvantages are described below.
Schemes
The three checkout schemes currently available are:
Clean Checkout
The "Clean Checkout" scheme, will always check out a fresh copy of the source from the SCM and rebuild from scratch. This is the default behaviour, and has the advantage of guaranteeing that the build is executed in a freshly checked out directory. This scheme is recommended for those projects where checking out the full source and rebuilding does not introduce too much of a delay into the build cycle.
Clean Update
The "Clean Update" scheme makes use of a local check out directory to improve the efficiency of updating the source code. When a project is built for the first time, the source files are checked out into a directory on the agent, and copied into the build directory. Each build after that will trigger an update of the source files followed by a copy into a clean build directory. The advantage of this approach is that pulse™ will only retrieve the latest changes from the SCM. This scheme may be used as an optimisation for projects where checking out the source takes a significant amount of time. Clean rebuilds are maintained by copying into a clean build directory every time.
Incremental Update
The "Incremental Update" scheme keeps a working copy of the project source code and reuses it for multiple builds of the same project. When the project is built for the first time, the source files are checked out directly into the build directory. Each build after that the source code will be updated and the build executed in the same directory. The advantage of this approach is that it allows incremental builds. The disadvantage is that builds are not isolated from one another: the artifacts from one build can affect the next. This scheme is recommended for projects that have build cycles too long to allow clean rebuilds.
Forcing Clean Checkouts
When using either the "Clean Update" or "Incremental Update" checkout schemes, it may be necessary at times to force a clean checkout and rebuild. For example, a bug in build dependency management may cause incremental builds to fail. In this case you can force a clean checkout and rebuild by clicking the "mark for clean build" link on the project's "configuration" view. This will ensure that the next build of the project on each agent will begin with a clean checkout.
In some situations, pulse™ itself may force a clean checkout and rebuild. For example, when you edit the SCM details for the project, pulse™ will ensure that the changes take effect by forcing clean rebuilds.
Change Viewers
If you already have a third-party web application for viewing your SCM repository, e.g. Fisheye, you can configure pulse™ to link to the external server using Project Change Viewers.
Filtering SCMs
The SCM Filters allows you to filter out modifications that are used to trigger a build. If for example, you have certain files (such as web pages or document files) under source control that you don't want to have trigger the build, you can use an Scm Filter to ensure that their changes will not trigger a new build. SCM filters can be configured via a projects "configuration" tab.
