Monthly Archives: June 2006

Subversion Everywhere

Today I went about setting up a subversion repository for my thesis, I had been meaning to do this for sometime but starting the next draft and my experience with the last one finally pushed me over the edge. Anybody who has ever written even a moderately difficult piece of work will understand the number of revisions and changes made while writing can become over whelming. I am for various reasons (that really should be the subject of another blog entry) not a latex man and while Microsoft does provide version control within word I just don’t trust it to work when I really need it. So like many others I have persevered with the ever reliable, if redundant and unorganized, combination of incremental naming conventions and multiple copies.

Today I decided to resolve this once and for all by creating a subversion repository on my work machine and using it to store revisions of all my thesis related work. This blog outlines the steps I used to achieve this both for you reader and (because I never try to remember anything that I can write down) for me also.

Since I have been using subversion for some time for my development work with Chive and other thesis projects I had a lot of the necessary software already installed if you don’t you will need to download and install Subversion, also TortiseSVN is a really good windows client for working with subversion repositories. The default options will probably suffice for most when installing these.

Once everything is downloaded and installed you can start creating your repositories using TortiseSVN. To keep things organized and for backups I created a My Repositories directory in My Documents and then created several repositories in there.

Next check that you can browse to your repositories using the TortiseSVN repo-browser. If you have a local repository the path will probably look something like this: “file:///C:/Documents and Settings/User/My Documents/My Repositories/Work Repository” where Work Repository is the repository you want to browse.

If you’re just interested in accessing the repository from your local machine then you’re done. If however you would like to make the repository you just created accessible remotely then read on.

First thing we need to do is to setup the subversion server to listen for clients, to do this you can either use apache or the lightweight server that comes with the subversion install (listing on 3690). Since you get the subversion server anyway you might as well use that unless you have a good reason to do otherwise (encryption would probably be one).

To start the subversion server run the svnserve.exe app in the Subversion install dir using the following command: “svnserve.exe -d” this launches the subversion server as a demon which will continue to run until you manually kill it. While this solution works it is a little annoying to have to manually run this at startup, a better solution is provided by svnservice which installs the svnserve as a windows service and let windows manage the running of it. Download an install svnservice, then extract the SVNService.exe to the Subversion install dir, then using a command prompt run SVNService.exe -install -d -r C:\$repository_root, where $repository_root is the root where you have defined your repositories (this both increases security and shortens the length of path you have to enter into Tortise later). Once that completes open up the services tab in the management console, locate the SVNService and start it, you will probably also want to set it to start automatically.

That’s it you now have a publicly readable repository, (try accessing it using Tortise locally first using svn://localhost/$repository_root), however since we are talking about using this repository for private work you may need to change the access permissions on the repository, thankfully this is a simple exercise.

Open the conf directory in the repository you want to protect. Edit the svnserve.conf file in the conf of your repository root to set read write privileges. You probably want to set anon-access = none (public can’t read or write), auth-access = write (authorized users can read and write) and password-db = passwd (password file with username password pairs). There is an example passwd file included with the Subversion install so you can modify that.

Once that is done then you can connect to the repository remotely using Tortoise, remember to replace localhost with the hostname or ip of your machine, also you will be prompted for your access credentials when you try and connect. Remember also that this connection is unencrypted so you might want to think twice about committing private information.

Have fun and note if you get lost that the tortise help docs on this are very good.

Eclipse Callisto

Eclipse callisto went RC4a about a week ago, which means that while its not production quality yet its loitering with intent. For those that don’t know (which is probably most) callisto is an attempt by the eclipse foundation to coordinate the release of several popular projects to deliver a more complete and professional software development environment. As such Callisto is not a new piece of software in itself but rather a collection of updates launched from eclipse update. Callisto currently includes projects like the C and C++ dev perspectives, the EMF, the GEF and what I found most interesting the Business Intelligence and reporting Tools project (BRIT) and the Test and Performance Tools Platform Project (TPTP). These latter two projects I think really bring eclipse leaps and bounds towards a professional software development environment.
Eclipse has for some time now being my preferred development environment, first was the SWT, just being able to interact with a java IDE like you were interacting with a real windows app was reason enough to ditch net beans to the curb. Second eclipses refactoring support enabled an iterative development process that when combined with the JUnit plug-in just plain kicks ass. However while eclipse’s support for the individual developing code continued to evolve, its support for integration into a larger development process was always lacking.
The combination of the TPTP and the BRIT projects now attempt to rectify this deficit by providing a framework for performing and reporting on the results of functional and performance tests. The TPTP project doesn’t replace the JUnit plugin but provides a layer over it which can link use cases to specific to JUnit test or manual test cases. The test reports then generated by the TPTP can be converted into HTML, CSV or XML formatted reports by the BRIT. Combine this reporting with subversion and TWiki and you have a really cool, free and extendable development environment.

To those that wish to give it a go I would warn against moving to its as your production dev environment just yet there are still a few bugs to be worked out (especially in the BRIT from what I have seen, note also the callisto bug hunt is still ongoing).

%d bloggers like this: