Monthly Archives: April 2008

How to find out what files aren’t added in your Perforce client

How to find out what files aren’t added in your Perforce client(image taken from jparise’s photstream)

I’ve first used Perforce in 2002. At the time we were using another product. Perforce was about 10 times as fast and 10 times less likely to make me want to storm into the comms room, rip the source code server out the rack and drop it off the fire escape into the street. It was also atomic.

A lot has changed in the intervening years. Subversion has come of age, distributed version control has become the next new thing, and I don’t have access to the comms room any more. Oh, and I’m using Perforce again. One thing I miss is Subversion’s ability to tell you the status of all files in the sandbox (which is roughly equivalent to a P4 client), including unversioned ones:

graham-tackleys-mac-mini:~/Documents/workspace/playpen jsimpson$ svn st
? a.html

In this instance, you can tell that ‘a.html’ and ‘’ aren’t versioned in Subversion because they have a status of ‘?’.

What do you do for the Perforce command line client? If you’re a Windows user, you can do this:

dir /s/b/a-d | p4 -x- have > nul: 2>missing.txt

The part to the left of the pipe (the ‘|’ symbol) gives you a list of all the file in your current working directory. The part to the right of the pipe queries perforce to see if the files are in the repository. Any files that are in the repository get binned, whereas any files that aren’t get written to the missing.txt file with the dreaded Perforce error message: file(s) not on client.

Unix users can try this one:

find . -type f | p4 -x- have > /dev/null 2>missing.txt

This valuable snippet comes from Laura Wingerd’s definitive work on Perforce. Is there another Perforce one-liner that you can’t live without? Let us know!


How to get repeat prescriptions from the Build Doctor

How to get repeat prescriptions from the Build Doctor(image taken from Tevor’s Photostream)

Thanks for all your comments so far. It’s nice to know that people are reading and (in just a few cases) correcting me. I do appreciate feedback – of all kinds. Here’s an outline of the ways you could track what’s going on here, and get in touch.

How to keep up to date:
RSS Feed. If you already use RSS feeds, then perhaps the most sensible thing is to subscribe to the feed for the blog. We publish a full feed which gets you ever article published, as well as daily build and deploy links from

Email Subscriptions. Every page on Build Doctor has a link for subscribing by email. I take privacy seriously, and will not disclose your email to anybody. If your internet access is restricted, this could be an option.

Twitter. Twitter is a great way to keep in touch with people, that seems to be quickly gaining traction. I’m going to announce new posts on Twitter.

Talk to the doctor:
You can email the surgery at ‘medic (at) build (dash) doctor (dot) com’

Every Build Doctor blog post has a comment section. I approve comments before they are published, so feel free to drop me a comment. Tell me if you’d like to be emailed back, and I can delete the comment before it gets published.

Twitter is also a good way to get in touch.

Tell your friends:
Every article also has links to social bookmarking sites at the bottom. If yours isn’t there, tell me and I’ll try and squeeze it in.

Thanks to the hipsters at the Disco Blog for the title gag.

Ant Best Practices: Manage Dependencies Using Ant

Ant Best Practices: Manage Dependencies Using Ant

(image taken from cotes’ photostream)

In the last post, we discussed the importance of a clean target. Is it your first time? Have a look at the index page.

Today, I want to talk about managing dependencies with Ant. What does that mean? In this case, it means managing the dependencies on code within your project: dependencies in code, third party libraries, etc. I want to cover dependencies between other projects in another post.

The advice is to start from the very bottom up. You have a bunch of common utility files? Compile them up in one target. And make sure that target outputs one thing and one thing only: a jar file called common.jar. Now, that file isn’t going to be your enterprise application on it’s own, so do the same to the code that references the classes inside common.jar. Make sure that each one of those outputs a single artifact, and that each one of them depends on the target for common.jar. Now, you probably have a web application or two that depends on a jar file of business code, which depends on a bunch of common files that nobody can decide where to put – common.jar.

What if there’s a separate project for the front-end project, vs. the back-end? You still want to package up the code as jar files for consumption by the other project. But for the love of God try to resist doing that. Most projects really only have one product that they make. To split them up into different, smaller projects adds a whole world of complexity.

What we just did was stop anybody from breaking the build by making the back-end code depend on the front-end code. Which is quite easy to do when your IDE allows you to do that in a few keystrokes.

This technique will create some good karma for your project, as long as you follow the sane practice of making every developer run the Ant build before they check in. For me, this is critical. Nice one, Eric.

Tagged ,

Cruise: the newest CI server from ThoughtWorks

ThoughtWorks Studios has announced it’s latest product: a Continuous Integration server called Cruise. It’s derived from the open source project CruiseControl with many new features promised. Jez Humble announced it to the CruiseControl developers on April 15. Presumably this will replace CruiseControl Enterprise, which was announced about a year ago.

Call me shallow, but I do like the name. CruiseControl always gets abbreviated to ‘Cruise’: why not give it the name that sticks?

The list of features looks impressive. I’m particularly interested in having a look at the Build Pipeline support. The idea of the pipeline is nice, but I’m still waiting to see a good implementation; and I’d like to see how it works in practice – I’ve been less than impressed in the past.

The support for Java, .NET and Ruby out of the box is a good thing. The 3 different CruiseControls that we all ended up with each have some great features. With each project being run separately, innovations tend to stick to the CruiseControl fork that they originated in.

You can read up on the rest of the feature list for yourself – click the link at the top of this article.

What will be interesting is how it’s going to fit into the CI marketplace. The first movers in the commercial CI tools space like have been carving out market share. Microsoft offers CI tools. There’s a load more of open source contenders now than there was a couple of years ago. Having said all that, ThoughtWorks are the people who put CI on the map. I think they will generate a lot of interest.

It’s a growing market. Let’s see what happens.


Tagged , ,

How to add Ant and NAnt support to TextMate

How to add Ant and NAnt support to TextMate

The moment my 30 day evaluation of TextMate expired, I ordered a copy. The last time I got so enthused about an application that I stumped up the cash for it was about 3 years ago, with Delicious Library. Today I used it to edit some NAnt files. Here’s how.

My ancient little Mac Mini already had Subversion. I installed Mono so I could get a working copy of NAnt. You’ll need both.

You need to run this in a Terminal window to enable syntax highlighting for both tools:

export LC_CTYPE=en_US.UTF-8
mkdir -p /Library/Application Support/TextMate/Bundles
cd /Library/Application Support/TextMate/Bundles
svn co
svn co
osascript -e ‘tell app “TextMate” to reload bundles’

The TextMate bundles repository has some non-ASCII encodings, so the first line just ensures that you have a UTF-8 encoding selected. The middle 4 lines make a directory, and put the Ant and NAnt bundles in that directory. The last line reloads the bundles for you if TextMate is already running. What a pleasant way to do .NET.

Tagged ,

Ant Best Practices: Provide a clean target

Ant Best Practices

(image taken from Bob Jagendorf’s photostream)

In the last post, we discussed the importance of good help. Today, the best practice we’re going to review (just joined us? have a look here) is provide a clean target. It’s pretty straightforward. As you change code (especially renaming source files), you’ll need to delete old files. You might as well automate the process.

I have seen builds that don’t use a clean target. But then generally these builds are relying on some other process, like nuking the entire checkout and starting again. It’s easier to have a clean target, honest.

You’d think that would be the end of it. Make a target called ‘clean’. Make it clobber some compiled code and generated artifacts. But while you go creating your new target, think about a couple of things:

– How many different files and directories do you need to delete? Ideally, it should be one directory. Life becomes very simple when you have a single tree to clean. Especially as you often end up making the opposite of a clean target to add directories back in.

– Did I say delete? If you have a single directory that the rest of the build depends on, check in into source control. You can often configure your VCS to ignore the contents (like cvsignore or svn:ignore) of the build directory. Then you can guarantee that it’s always there, but not have to worry about the built artifacts showing up when you go to commit.

Here’s one that I prepared earlier:


CITCON Europe 2008, Amsterdam – registration is open

CITCON Europe 2008, Amsterdam – registration is open(Photo taken from Copabella’s photostream)

Citcon is one of my favourite conferences. A free, open space conference about Continuous Integration and Testing. I like it because you get to meet other Build Managers and see where things are headed. Registration opened today. Numbers are limited.

Amsterdam, Holland October 3 and 4. Link

The CruiseControl Best Practices Series

Continuous Integration can be hard. I work with it every day as a Build & Release Manager. In my role I make sure that we are building our software so it can successfully be
deployed to production. In this series of blog posts I hope to
pass on my top ten tips for using CruiseControl
effectively. I’m writing these with the developers or systems
administrators in mind: the people who most often manage
CruiseControl. However, anybody who is interested in
Continuous Integration will get something from these articles.

Part 1: Publish with a publisher [Chinese translation]
Part 2: Keep your dependencies to yourself [Chinese translation]
Part 3:Configuration the CruiseControl way [Chinese translation]
Part 4: Bootstrap with a bootstrapper [Chinese translation] [Config Validator]
Part 5: Refactor your configuration file [Chinese translation]
Part 6: Scaling up [Chinese translation]
Part 7: CruiseControl for non-Java applications

(Image taken from igb’s photostream on Flickr)