Houston, we have a problem. Revert!

Where would we be without source control?!  I thought about git but I wanted something simple with a proven set of tools so it was back to our old friend Subversion.  I’ve setup Subversion servers from scratch before but I wanted to see if there was anything a bit more user friendly that had a GUI. After some research I settled on VisualSVN.  It literally took me a few minutes to download, configure everything and have a SVN server ready to go.   CollabNet also has a new product called “Subversion Edge” which bundles Subversion and  Apache in an easy to install bundle.  VisualSVN seemed the simpler of the two options so I went with that one and have been happy so far.  It includes a very simple administration interface that allows you to define repositories and permissions, and can integrate with Windows authentication if you need more complexity.

Where is that Post-it with the client’s feedback?

I’ve also grown used to developing with a bug/issue tracker.  I love Jira but needed something free so turned to Redmine.  Redmine is built on Ruby on Rails and again I didn’t want to go through the hassles of setting something up so I turned to BitNami which I have blogged about in the past.  BitNami happens to have a Redmine application stack available. Download. Install. Done!  Out of the box Redmine provides you with issue/bug tracking, file repository, wiki, forums and more.  It also integrates nicely with Subversion.

Hey who deleted the file on the server?

I’ve also grown used to developing locally vs. on a central server.  Locally I’m running my VirtualBox development environment I’ve talked about before.  ColdFusion, MySQL and some other tools all conveniently running in a VM.   I actually set this up at home, then exported it and copied it to my work machine.  A few tweaks and I had our project up and running locally on my workstation.

In only a few hours I setup source control, a bug/issue tracker and a local development environment.   The  “I’m too busy” excuse is easy to fall back on but it really takes very little time to setup a solid development environment that would benefit everyone from a small team of one to large corporate teams.

Next up – mockups, bug logging and more tools!

I was digging through one of the SVN books and came across a bugtraq property. A bit of Googling turned me onto a great tutorial by Mark Phippard (project lead for Subclipse):

Integrating Subversion with your Issue Tracking System

This is one of those simple tweaks that makes your life much easier as a developer.  After adding the properties outlined in Mark’s tutorial:

bugtraq properties

Now in my commit dialog I get a text area to enter my JIRA key:

Subclipse dialog w/JIRA KEY prompt

Since I have Mylyn installed – when I hover over the link in the SVN History view I get two choices:

Open with options

So now I can open the task in Mylyn or if I select the hyperlink option it opens in the Eclipse browser.

Mylyn View

You should be familiar with the “Export” command.  This will make a copy of the files in a new location without all those pesky .svn folders.   If you want to ‘unversion’ something but don’t want a copy – simply do an “export” and when Tortoise asks for the “folder to export to” simply select the same folder your working copy is in! Tortoise will proceed to remove all the .svn folders.

1. One repository per project or…
2. One project per repository

The Subversion book goes into this a bit – and mentions a few pros and cons of each method but I was curious what people were actually doing.

Right now we are ‘One project per repository’.  There were a few reasons for making that decision but now we are re-evaluating and considering moving to a single repository for everything. I’m curious if anyone is currently doing that and having issues?  Anyone have an alternate setup?

Fixing Ignored Files

We’ve all run into this one before – you have a file somone mistakenly commited (.log files in my case).  From the TortoiseSVN help:

If the files are already in the repository, you have to do a little more work.

1. Hold the Shift key to get the extended context menu and use TortoiseSVN > Delete (keep local) to mark the file/folder for deletion from the repository without losing the local copy.
2. TortoiseSVN > Commit the parent folder.
3. Add the file/folder to the ignore list so you don’t get into the same trouble again.

Moving Files within the Repository

I’ve also got some folders scattered around the repository containing documentation. Ideally these should all live under our /doc directory.  But how to move these without loosing their history?  Again – from the TortoiseSVN help:

The easiest way to copy files and folders from within a working copy is to use the right-drag menu. When you right-drag a file or folder from one working copy to another, or even within the same folder, a context menu appears when you release the mouse.

Every time I dig into the TortoiseSVN help I learn something new!

• Merge tracking (foundational)
• Interactive conflict resolution
• Changelist support
• Speed improvements, cancellation response improvements
• More than 150 new bug fixes, enhancements

And a host of other things!  I’m sure Tortoise and the other clients will be updated soon as well.

projectname
/docs
/testing
/build
/priv
/pub

Testing contains our Selenium scripts (and in the future – unit testing scripts). Build contains our Ant scripts.

At the office I’m in charge of setting up new SVN repositories and one of the things I’ve done to speed up setting up new projects is to create a ‘template’ project directory. This contains all the folders listed above along with some default buildfile and testing scripts.

I first created this layout in a new repository. I then added our standard buildfiles and testing suite files. I then created a SVN dumpfile using the svnadmin dump command. You end up with a dumpfile containing the contents of your repository.

Now when I create a new project I simple create the new project’s repository, and then use the svnadmin load command to import my ‘default’ dumpfile contents.

/usr/bin/svnadmin create --fs-type fsfs /var/www/svn/projectname
sudo chown -R apache:apache /var/www/svn/projectname
sudo svnadmin load /var/www/svn/projectname < /var/www/svn/tmp/template.dumpfile --ignore-uuid -q

Now when the first person checks out the project – they already have the required directory structure, buildfiles and testing templates.

This tutorial assumes you have the following installed:

• CFEclipse
• Subclipse plugin
• A remote Subversion repository

First open CFEclipse and open the SVN Repository view.

Window > Show View > SVN Repository

Next click on the Add New Repository button.

Enter the URL of you remote repository and click Finish. I usually enter the root URL so I can access anything within the repository. Your remote repository should now be visible in the SVN Repository view.

If you need to add existing local project files to your repository you can do that at this point by creating a directory within your repository and doing an import:

Now expand the repository and locate the directory you wish to checkout:

:

You should be able to leave the defaults selected and click Finish. We will checkout our project using the New Project Wizard and we will checkout the HEAD revision.

When prompted for a Wizard – select:

CFEclipse > CFML Project

Click next and enter your project name and select your location and click Finish:

Your CFEclipse perspective should open to your new project. You should see the standard SVN icons letting you know these files are under version control:

And you can now manage these files in Subversion via the Team menu:

Sometimes it is useful to construct a working copy that is made out of a number of different checkouts. For example, you may want different subdirectories to come from different locations in a repository, or perhaps from different repositories altogether. You could certainly setup such a scenario by hand—using svn checkout to create the sort of nested working copy structure you are trying to achieve. But if this layout is important for everyone who uses your repository, every other user will need to perform the same checkout operations that you did.

Fortunately, Subversion provides support for externals definitions. An externals definition is a mapping of a local directory to the URL—and possibly a particular revision—of a versioned resource.

At work – I have the following setup in Subversion:

• /trunk
  • /artifacts (my docs)
  • /build (my Ant build files)
  • /coldfusion (my CFM code)
  • /oracle (my ddl scripts, etc)
  • /testing (my selenium scripts)

While I could checkout /trunk and setup my webserver to point to the /coldfusion directory this wouldn’t be exactly the same as my production environment. I need to checkout the /coldfusion directory. This leaves my build, testing and other directories left out. By using svn:externals I can grab those directories as well during checkout.

Note: Be aware there are several issues with svn:externals regarding update/commits of code included in the external directories. Please read the related documents online (and if you have Tortoise SVN installed check out the section related to svn:externals in their excellent HELP section – it is listed under the “How Do I…” section in “Include a common sub-project”).

Now lets see how to setup svn:externals using CFEclipse. First if you haven’t already – we’ll checkout a copy of our project. Here I’m checking out a my /coldfusion subdirectory which contains my project code.

Here is the project in the CFEclipse Navigator view. You can see the path reflected (core/trunk/coldfusion). Now I need to add the other directories (build, testing, etc)

Now we can right click on the top level of our project – select Team > Set Property.

The svn property dialog will appear. For the property name select svn:externals. Make sure “Enter a text property” is selected and enter the following (alter this path to match what you want to include):

oracle https://your.svn.repo.com/svn/telework/core/trunk/oracle

The svn:property consists of two items – one the name – here I’m using ‘oracle’ and the full path to the repo. We can define several of these so we’ll end up with:

oracle https://your.svn.repo.com/svn/telework/core/trunk/oracle
testing https://your.svn.repo.com/svn/telework/core/trunk/testing
build https://your.svn.repo.com/svn/telework/core/trunk/build
artifacts https://your.svn.repo.com/svn/telework/core/trunk/artifacts

Click OK and you will return to the Navigator view and your svn icon will have changed to let you know things are out of sync. Commit then Update your project (Team > Commit / Update) and you should now see your external directories!

Again please note there are some things to be aware of regarding updating and commiting changes in the external directories. From the Tortoise SVN Help:

Each time you update your main working copy, you will also receive the latest version of all external projects.

If the external project is in the same repository, any changes you make there there will be included in the commit list when you commit your main project.

If the external project is in a different repository, any changes you make to the external project will be notified when you commit the main project, but you have to commit those external changes separately.

While in this example I am using CFEclipse and Subclipse you should be able to follow similar steps using any tool that works with Subversion.

One thing I liked is John had tagging built into his Ant scripts. He tags everything when his build file is run. I think I’m going to write up a ‘yes/no’ dialog so I can be prompted and skip it if I don’t want to create a tag. I’m also curious about using something like Cruise Control for continuous integration. I really want to learn more about how people implement that when developing web applications.

I’m also going to start using the SVNAnt task instead of calling exec. The syntax looks MUCH cleaner.

The CFMeetup Link to John’s presentation: http://experts.acrobat.com/p41566907/