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.

About Me

For more information about me and my involvement in Web development, visit my bio on

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.

Aaron West's Gravatar
About this post:

This entry was posted by Aaron West on March 12, 2007 at 9:53 PM. It was filed in the following categories: ColdFusion, Apache, Subversion, TortoiseSVN, Subclipse. It has been viewed 29285 times and has 7 comments.

5 related blog entries

7 Responses to Configuring a Development Environment with Apache, Subversion, TortoiseSVN, and Subclipse

  1. pan69

    >> My only real complaint with CVS was its use of a lock-modify-unlock
    >> model like VSS.

    This is of course not entirely true. The locking was only supported by CVS as an mechanism (a hack) in the WinCVS client. CVS itself has no concept of what locking is. It's not for nothing that its called a Concurent Versioning System.

    >> Subversion employs a copy-modify-merge model as an alternative to locking.

    It is actually the same model as CVS (concurrent). However, since version 1.3 if I remember correctly, SVN has an actual concept of locking and unlocking since its a bit difficult to merge binary files... :)

  2. Ben

    Dude. Awesome article. I've been wanting to get SVN up and running for a while now but hadn't found anything this detailed before.

    One question: if installing on a local machine, is there any reason I shouldn't use the same directory for my working directory that I imported the files into SVN from?

    Thanks again, this rocks!

  3. Ben, after you've imported your files into a repository the repository does not reference the original import location at all. So, you could certainly use that directory as your working copy. If you do this, I recommend deleting all the files in the directory first and then checking out the latest from the repository. If you don't delete the files, Subversion will overwrite them.

    This type of workflow is probably more indicative of personal development with a local Subversion server than it is a full team environment. In team environments, I've found folks put their code off to the side somewhere, import it into the repo, and then check it out to a personal dev machine. Once that's done, the original import code can be left alone as a backup or deleted.

  4. Hey Aaron,

    Thanks for taking the time and putting this series together! This should prove to be most useful.


  5. Hi,

    Thanks for the article mate. But I have a query.

    We have a team of developers working on various websites and we use eclipse svn to manage the code and its various versions.
    Our App Dev. manager has setup the svn as a distributed system, i.e. every coder has a copy of the whole website on his local pc along with
    Apache and Mysql installed with the database structure for the website (with some dummy data to play with). Hence, when a coder wants to
    edit a page he/she simply works on his/her pc and commits it after successfully testing it on his/her PC.

    Now the problem here i face as an IT Manager is the security of the code. Currently, the source code of all the sites is lying in around 8-10 PCs,
    used by the various coders/designers in the team. I am now worried that how secure it the code. Earlier we had all the code residing in a file server
    where only one person was able to work on a file at a time but though that feature was unavialable we it was safe enough, as we were able to
    set rights for the folder/files on the file server.

    Is there an alternative to this where the coder downloads/stores only that file on his PC which he wants to edit and still continue testing the
    website on his local pc and commit once he is satisfied. Can Apache/Mysql run from a central location where it picks up most of the files from
    the central SVN server and only picks the updated files from the local pc for testing locally.

    Or any other better solution you guys can recommend.

    Thanks and regards


  6. Hitendra, the development environment that you currently have - where the 8-10 developers each have a copy of the codebase - is the standard for programming teams. Your company definitely moved in the right direction switching from a shared server, single-access, dev environment. A lot of companies start out like yours and move in the same direction implementing source control management.

    Of course, from your prospective as an IT Manager, you're concerned with the code being on more than just one machine. If your development environment is behind a firewall, DMZ, or other such security mechanism, you can feel pretty safe about it being protected from folks who shouldn't have any access. You can take things further with your code repositories locking them down to certain groups and users within your organization. This type of granular access is best accomplished with integrating Apache and Subversion together. I describe some of what's possible in Part 4 of this blog series.

    If you ask experienced Subversion admins I think most would discourage finely tuned access permissions in repositories. I would personally discourage this as well. Source control management is designed to keep track of lifecycle changes to documents, code, or whatever. If someone makes a change they shouldn't have, their change can be reversed. My personal take is to manage the social aspect of development teams with policies and procedures instead of software. In the repositories I manage, I do force authentication for all repository actions (read and write) but I've yet to find a situation where giving specific programmers specific rights would help. If a junior developer makes a mistake, we simply roll back their change.

    The scenario you describe in your last paragraph is not really a good one for development teams. Plus, I'm not sure how it would even be technically possible. Rest assured ya'll are on the right path with how you are running things. If you're still uncomfortable with the "openness" of your repositories you can put security measures in place at the Subversion layer.

  7. Thanks for the reply Aaron.

    I got your point and understand that this way development is
    good as we can keep a track of things as they happen.

    The only concern I had is the code distribution. I did read in a
    website we can install the sub-version as a client-server model
    but there were not much details about the same.

    Just want to make sure that possible resources for people to
    steal the code is comparitively less, hence, making it bit more