Jenkins: Source Code Control
Start a Build Whenever a Commit is Made
Jenkins allows you to trigger a new build based on SCM changes. This can be done either as a polling, which requires little configuration and works with almost all SCMs that Jenkins supports, or as a push from a repository, which reduces the latency between the time a commit is made and the time Jenkins notices it.
Hold Off a New Build While Commits are Coming
Developers often make one logical change in a series of commits. And some SCMs just aren’t capable of grouping one commit as one commit. For such situations, Jenkins can hold off a build for a certain period of time, until it makes sure that there is a window of inactivity called a “quiet period.”
In this way, a burst of changes are aggregated into a single build, making it less likely to pick up an inconsistent repository state.
Track Commits in Builds
Jenkins accurately tracks the commits that went into each and every build. This information is valuable when you need to track down regressions–did build #155 contain the change James made last Friday? Ask Jenkins!
Who-made-what-changes-when is all visible from the web UI. If your projects depend on other binary artifacts produced on Jenkins, the web UI will show that as well.
You can come back to Jenkins long after the build has completed and tag the source code that was used for any of the past builds. In this way, you can test the build first and tag it only after you are sure about its quality, not the other way around.
Comprehensive Version Control Support
CVS, Subversion, Git and Mercurial are supported out of the box. ClearCase, Perforce, StarTeam, Visual SourceSafe, Accurev, Team Foundation Server, Bazaar, BitKeeper, CMVC, Dimensions, Harvest, PVCS, Synergy and more are all supported through plugins.