During the past two weeks I have worked on a new paper outlining the process of installing and configuring a development environment with Apache, Subversion, TortoiseSVN, and Subclipse. Over the next day or two I will be posting the individual parts of the paper as a blog series. For those that prefer to read offline, the entire text (60 pages and 91 screenshots) is available as a PDF download (see below). This blog post kicks off the 5 part series with the Introduction.
Click here to download Configuring a Development Environment with Apache, Subversion, TortoiseSVN, and Subclipse or click the "more" link to begin with the introduction.
Over the past two years I've seen the popularity of Source Control Management (SCM) increase exponentially. I've yet to determine exactly what the catalyst has been but certainly overall awareness regarding the importance of SCM has played a major role. During sessions at various ColdFusion conferences and user group meetings, audiences have been polled regarding their use of source control and over the years more hands are being raised as development teams begin to employ some level of SCM. It's uplifting to see this change and yet there is still room for improvement.
Sprinkled throughout the Internet are several blog postings and articles designed to help developers create and configure a source control environment. Most of these resources are out of date or incomplete when it comes to illustrating an end-to-end solution. That's not to say they aren't helpful but in my own endeavor to set up a new source control environment I've found them somewhat wanting. So, I decided to create a new resource for installing and configuring a source control environment. Throughout the process I've researched tons of different options, documenting what I think works best for my team. Several dozen hours have gone into installing, configuring, re-installing and re-configuring in an effort to get things "just right" and along the way I've documented the entire process. While this was done in forethought of this text it has also been helpful to create a paper trail of what I've done. What follows this introduction are detailed instructions for installing and configuring the same source control environment I've created, complete with dozens of screen shots. Before moving forward I should note this text focuses on both the server and client aspect of source control. Not only will I cover the installation and configuration of Apache and Subversion as server software; I also cover the installation and use of various Subversion client tools like TortoiseSVN and Subclipse. While the information in this text is meant to be consumed as a complete whole you can certainly focus on the portions relevant to you.
For more information about me and my involvement in Web development, visit my bio on Adobe.com.
Why Subversion Over CVS and Microsoft Visual SourceSafe?
First and foremost, yes there are options other than Subversion, CVS (Concurrent Versions System), and Visual SourceSafe (VSS). With the exception of perhaps Perforce I've found these three to be the most popular source control products. I spent the better part of three years using VSS at my first job. Back then, there was no CVS or Subversion and Microsoft was arguably the largest player in SCM. While VSS did help the development team manage code, it did so with an insurmountable laundry list of headaches. The VSS client was not intuitive and required developers to mimic folder structures that were already present on the file system. This "repository view" is something developers should not have to worry about or understand. Managing binary files like images and Flash movies with VSS was horrific to say the least and we gave up after a half dozen failed attempts. The last, and probably largest pitfall of Visual SourceSafe was its inability to allow multiple developers to work on the same code at the same time. The process of changing versioned files included "checking out" the code. Once checked out the code was locked and modifications by other developers were prohibited. If the first developer was working on a version 2 release, bug fixes (by other developers) for version 1 were not allowed.
At another company I had the opportunity to use CVS. When compared with VSS, CVS was a fresh breath of air. It was much easier to use (we used the WinCVS client) than VSS and it handled binary file versioning like a champ. In fact, Flash files (SWF's and FLA's) were what we versioned most. My only real complaint with CVS was its use of a lock-modify-unlock model like VSS. This model requires a user lock a file for modification - locking out other users and changes - and then unlock the file after changes are complete.
Subversion employs a copy-modify-merge model as an alternative to locking. This model allows developers to work on a local copy of files (called working copies) simultaneously and independently. Developers may then commit their work to the versioned repository where Subversion will merge the changes from each developer into a final copy. Other benefits of Subversion include the ability to integrate with the Apache Web server, versioning of directories and directory/file renaming, and cheap branching and tagging operations. Since a full discussion of SCM and SCM policies is outside the scope of this text, I recommend reading Chapter 1. Fundamental Concepts of the Subversion Book.
There are many, many ways SCM can be employed. How you use SCM should be determined by your own needs and the needs of your team. This text describes one such way of utilizing source control and in no way represents an applicable solution for all environments. I encourage you to use my ideas as a guide in discovering what works best for you and your team.
5 related blog entries
- Part 5: Accessing Subversion Repositories With Subclipse (March 15, 2007)
- Part 4: Subversion and Apache - Better Logging and Authenticated Access (March 14, 2007)
- Part 3: Installing TortoiseSVN 1.4.3 and Creating Your First Repository (March 14, 2007)
- Part 2: Installing Subversion 1.4.2 and Integrating Subversion With Apache (March 13, 2007)
- Part 1: Installing and Configuring Apache 2.0.59 (March 12, 2007)