Further Subversion Steps: Get Motoring with TortoiseSVN
- "Who Broke the Build?"
- Build a Repository and Working Copy
- TortoiseSVN: A Windows Shell Extension
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
"Who Broke the Build?"
The question above is heard often in large software development projects. In the old days (2–3 years ago), breaking the build was all too easy because many companies had just a single mainline code branch. In such setups, developers made changes locally, tested, and then checked the new code into the main line. Forgetting to check in one part of a change could break the main line for everyone except the single developer who made the change!
Nowadays, things are a lot more stable, as most organizations embrace more sophisticated repository usage policies; for example, using task branches. This trend is also due in no small part to the adoption of test-driven and test-oriented development. With these practices, software is subjected to fairly rigorous unit testing and integration testing before submission into the repository. Tools such as Subversion help a lot in ensuring that all the required changes are checked in successfully. This, in turn, helps in avoiding the problem of a broken build.
As I’ll discuss shortly, TortoiseSVN provides some useful tools for forensic testing of build breakages. However, it’s important to remember that even with the best will in the world and the most rigorous check-in policies, it’s always possible to break the build. One example is when some changes are not fully checked into the repository—developer X makes five changes and checks in only four changes. Subversion helps to avoid this class of problem in the way the client software manages all changes to the working copy. However, Subversion isn’t foolproof. Suppose I create a new class file and forget to call the command svn add. Subversion won’t know about the new file, even if I instantiate the class elsewhere in my code. In other words, I’ve just broken the build.
The area of Subversion clients is rich in offerings. You can use the basic command line if you’re a text kind of person. Many developers prefer to use a graphical solution; the Eclipse plug-in (called Subclipse) is a good example. Each approach has its merits, but in my opinion TortoiseSVN combines the benefits of both approaches into a single solution. You get the fine-grained control of the command line as well as a more intuitive GUI perspective. However, in computing nothing is free, and you may find that the use of TortoiseSVN adds some overhead to your machine. Loss of performance as a result of using TortoiseSVN is one of the small downsides to this technology.
Aside from the potential for a performance impact, I like the fact that TortoiseSVN works right out of the box. Once you install it, you can start to use it immediately, with no need for any complicated configuration.