Late Night Cocoa (011) : Source Control, Builds & Unit Tests with Gus Mueller

Gus Mueller talks about automated builds, testing, source control, and other tips



Guest Link
Flying Meat

Automated Build Script
Chris Hanson Xcode Unit Testing Series
Forum for this episode


Another winner

These are getting better and better. Great guests and great interviews of said guests. Looking forward to the next one.

Great podcast

I think it's the best episode to this date. Frankly almost every episode is better then the previous :D

I have a suggestion for a future one:
How to make a shareware = locking an application after a date, genereting code and unlocking application.
So maybe it's even a whole subject: releasing your app for public.

In my humble opinion it's an interesting topic.

Best regards

Two more Subversion resources

From the people who brought us the TextMate book the Pragmatic Programmers have an excellent guide for using Subversion

And if using the command line gets to be too much, there is a GUI for the Mac called SVNX

Version Control Errata

Great interview, I certainly don't want to detract from Gus' worthwhile discussion but there are a couple things that were glossed over really pretty quickly and a little dismissive that I think needs a bit more importance placed on it.

Not quoting exactly, but the idea of 'everytime you make a major change.. check stuff in multiple times a day' likens version control to backups/snapshots.

Also as SOON as you got stubs (say a template), import it... even if you wrote no code. Don't wait till you achieve a skeleton level of your application before you import -- don't depend on backups at all... backups don't have commit logs and I don't know about you but I have no idea what code I write based on calendar date.

It's *very* important -- no it's absolutely necessary that each commit consist of *functionally* atomic changes to code -- I don't liken this to major changes, as one could do more often then not making minor changes, but yet still functionally independent. Make TONS of commits for each functional addition. Do not work breadth-first (multitasking like you do for your end user work can really hurt you code unless you are switching the branch your working copy points at constantly), work on a single problem at a time, when it's solved, commit it. If it's too big for you to tackle in one sitting then you probably need to branch trunk from whatever revision you started this endeavor at. In fact it's probably better to commit too often then too little... Revision numbers just continue to grow, but the goal is to never ever merge a single revision where you are accidently getting baggage that commit was not targeted for. Unwanted baggage is a great way to sneak code in that may break your app directly or even worse introduce a latent bug that may hide for a long time simply due to not being consistent with the commit coverage.

One last point which is more subtle advice based on the interview because I think it was pretty well covered -- but I have one comment -- while subversion and friends make no distinction from branches and tags (after all they are just dirs in your repo with different names), *you* should make a distinction. Tags should be treated as read-only, once you tag a release, it NEVER changes. Branching is cheap after all.

Great Post

Mark, this is a fantastic post , Thanks for your thoughts and comments. We all work in a particualr way and I cant speak for Gus but I know we often casually talk abut complex things and fail to reveal often complex thought processes behind what is described as simple actions. Your comments here just help clarify some of those processes so thanks.

Yes Tags Dont touch , Branches , well thats what there for.

The Goal of this episode more than anything else was to encourage people to use source control, to look at automating tasks and to use unit testing. I know many of our audience will already be doing all three and comments (such as yours) on any of these areas just add value which is great. But we also know that many people don't use SCM , automation or unit tests and if we have encouraged one or two to look into it then I am a happy man.

Please keep constructive comments like this coming.

Late Night Cocoa.

A way to prevent edits on tags dirs.

Have a look at this page:

Under Hook scripts you can find a script called "" this script is configurable to allow/deny add/delete/update on repository paths.

Run with option "-h" to get more details. It involves editing a "svnperms.conf" file. If there is a way to prevent tag updates, this is the only way I know of.

Subversion has such lowsy permission options (only read or write) because of how webdav works. Would have been better to be able to selectivly allow all CRUD operations with a path based system without having to use hookscripting.

(On a usability note of this blog: why does entering a Homepage URL require a full url with a scheme definition. Isn't "http" kind of like a good default?")

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options