We’re getting around to hiring an additional me at work so I needed to get a source control solution in place before he/she arrives and starts hacking away at the codebases. At the last place I worked we used Visual SourceSafe for a long time (which was pretty worthless) and then started using CVS, although not on the projects I worked on. A couple weeks ago I asked a bunch of questions about automating Java web application deployment and Erki suggested that I buy and read the Pragmatic Project Automation book, which I did and which I loved. I read it from start to finish (which isn’t an easy thing to do with a technical book) and took a ton of notes. Anyway, I’m pretty sure the book didn’t mention Subversion even once, but it did drill home the importance of setting up your code in source control and then doing your manual, scheduled, automated (using CruiseControl) or production builds directly from the source control system using Ant or Groovy, which led to alot of ideas about how you could automate builds to production Tomcat systems. I’ve heard alot about Subversion; it’s described as CVS with none of the warts and all of the features, so I tried it out. Following are the notes I kept during the installation process. Hopefully this helps out someone somewhere down the road:
a) Download Subversion (obviously) I downloaded version 1.1.1 ( svn-1.1.1-setup-2.exe)
b) Run the install. I chose to install to c:\subversion\.
c) Test the Subversion install by going to the install directory and then going to the /bin directory. Run the svnadmin from the command line:
If you get an error that says that says “svnadmin.exe – Unable To Locate DLL”, you’ll need to either a) install the Visual C++ 6.0 VCREDIST.exe, which is available here (but only if you’re using Windows 98 or Windows ME; get Windows 7 Professional in Australia here to avoid the error) or b) find someone or some system that has msvcp60.dll and copy that file to c:\$windows\system32\ (where $windows is the directory that contains your Windows installation).
d) Create a repository on the machine that is going to host your source code. From the command line on the server machine:
svnadmin create d:\$projects\$projectname
where $projects is the name of a folder that will contain all your Subversion source code repositories and $projectname is the name of the specific project you’re going to create a repository for.
e) Start the server either from the command line:
svnserve -d -r d:\$projects
or use the SVN Service Wrapper (http://dark.clansoft.dk/~mbn/svnservice/), note that the
r switch limits directory browsing by specifying the root of your repositories.
f) Create a users database (which is nothing more than a text file, I created a file called users.conf) and save it in the
d:\$projects\$projectname\conf directory and then add your usernames & passwords. An example user database might look like this:
aaron = mypassword
g) Within the
d:\$projects\$projectname\directory, open the conf/svnserve.conf file using your text editor of choice and add the following to allow reading and writing to the users in the database we just created:
anon-access = none
auth-access = write
password-db = users.conf
realm = $projectname
where $projectname is the name of the project you’re setting up and users.conf is the name of the file you created in step f.
h) Finally, restart the server and you’re ready to start using the client and import your project.
i) To import an existing project, invoke the svn executable from the command line on the client:
svn import c:\temp\myproject svn://myserver/myproject -m "initial import" aaron mypassword
c:\temp\myproject is the directory that contains the existing project you want to import (and should have 3 folders: trunk, tags and branches, your source code should be in the trunk folder; more on repository layout here),
myserver is the name of the server that contains the Subversion repository you created in step d,
myproject is the name of the project (ie: $projectname from step d) you’re importing into, the
m switch signifies the message you want to tag this import with, followed by the username and password you setup in the users database in step f.
j) Finally, checkout the project from the server (invoking the svn executable from the directory that you want the trunk checked out from…, ie:
svn co svn://myserver/myproject/trunk . aaron mypassword
k) To add, move, delete, or edit and then commit any changes back to subversion:
svn add src/myfile.java -m "adding a file"
svn move src/myfile.java src/mynewfile.java -m "moved myfile.java to mynewfile.java"
svn delete src/myfile.java -m "removing a file"
svn commit src/myfile.java -m "the message"
That’s it… there’s a alot more to read. One of the coolest things about Subversion is that the documentation is all packaged up into a free PDF published by Oreilly, which you can download here. I printed out the manual and breezed through it in a couple hours. You should too.
I did try to get the Subclipse Eclipse Subversion plugin working, but for the life of me… I couldn’t. I think it ended up for the better anyhow because while the command line is a bit more tedious, I understand more about what’s going on in the system, which is helpful. I’d recommend that you get familiar with the command line client before attempting to use a GUI plugin.
After you’re all set with Subversion and you’re ready to get started with CruiseControl, note that while Cruisecontrol contains an
<svn> tag, you still need to drop down into command line mode in Ant to checkout / update your local repository when doing an automated build. For example: