Having developers work with the last successful build with SVN

If you work with subversion, how can you organize that de开发者_如何学JAVAvelopers can easily checkout the last working build and work on this one, instead of working on a potentially broken HEAD?

The idea behind the question is as follows. When a lot of developers work simultaneously on a project, it can happen that someone breaks the build or some tests. Continuous integration helps to find these things early, but it does not prevent that the HEAD release is temporarily broken. So I want to give everyone the ability to easily check out and work on the latest revision known to be working, and only update to HEAD when necessary for a commit. Creating a tag with SVN seems not to be the appropriate way to do this, since in SVN a tag is essentialy a new branch and can hardle be moved after each successful build. How would you do this?

If your developers are following a standard practice of 'update to head, run local build/tests, checkin', then the chances of you having a broken server build should be quite slim...

That said, you could get your build to update a public batchfile/script on success, which is used by your developers and does a checkout to a particular revision of the trunk (the revision that your successful build was run against). So on successful build you'd update the checkout command to be something like:

svn co https://<ServerPath>@RevisionNumber

Where RevisionNumber, was either stored when the server checkout was run, or derived by calling svn info and extracting the Revision: value

If your CI server notifies all developers, i.e. not just those who broke the build when a build breaks, your developers can avoid fetching a broken head by watching for a failed build email and holding off until the 'build fixed' email goes out. If a developer crucially needs to update (perhaps after a vacation), they can go back to the last good revision. Most CI software supports this. I know for a fact Jenkins provides a 'last successful build' link. If you wanted a web page to show this, like @forsvarir suggested, you could easily scrape this page.

The problem from a pure technical perspective is that you're trying to orchestrate the behaviour of source control based on the outcome of a build in the continuous integration environment which is a bit back to front. I'm not aware of any way to cause developers to pull from an earlier revision within the same path depending on a CI build outcome.

But really, this is a development practice issue. Developers shouldn't be committing code which "breaks the build" and much has been written on the sort of punishments which should be dished out to those who do :)

But of course a local build can succeed whilst a build from code integrated back into the trunk can fail. This is why products like TeamCity have the concept of a "personal build" whereby work in progress can be built against the trunk and only committed after it builds successfully.

So in short, your problem is known and recognised and a combination of tools and practices exist to address this. But the practices don't include prohibiting pulls of code based on build outcomes.

Even I work with SVN, Since it allows mulitple checkout from many developers, Whoever checks in the file, need to check and compare it properly with the previous versions.

Suppose in the next build if the code breaks, we can easily revert it back..

If this is really an exception it is perhaps easiest to advise the developers where the revision number of the last successful build / deployment is found in the CI server webpages, and suggest to go back to this revision number in case of trouble. Then the problem can be fixed without disturbing the others too much.