Basically I demonstrated for them the improvements (under the hood) that Apple have made in the latest version of OS X (10.6). By my count Snow Leopard contains over 100 significant modifications and improvements, but more than enough people have already covered most of these on other blogs so I’ll not add to the noise on this. If you are interested to find out more then check out Apple’s enhancements and refinements page.

Other then the update to 64 bit in the system and many of the core apps the big ticket item is the upgraded to the services menu. In older versions of OS X the services menu appeared as a menu item in the drop-down menu under the program name in the menu bar. It contained a long list of ever service, functions provided by other applications to the system and other applications on it. Whilst this was a cool way of extending the overall functionality of the system it was not very user friendly as the list contained every service available whether you used them or not and whether they were relevant to what you were doing  at the time. Having a service to rotate an image available when your editing text in a text editor is obviously as useful as proverbs on a Bull.

Well Apple have made some very significant changes. The service menu is now contextually aware so if you are editing text in a text editor you will only see the services that are relevant to the task at hand. Even more handy is the appearance of the services menu in the context menu (control+click / right click) of all applications that support this functionality and in the Action drop-down menu in finder (the button with the cog wheel icon on it). So there are at least three convenient locations you can find the services menu now.

The services menu is also configurable now. To do this all you have to do is click on ‘Service Preferences…’ in the service menu or open the Keyboard Shortcuts tab of the Keybord preferences pane and you can switch the service on and off as you like. You can also change the keyboard shortcuts for each service. The trick is to double click on the existing shortcut (or select a service and hit enter) to make changes.

If you want to take things to the next step and create your own services you can do so with the new service template in Automator. All in all I think what Apple have done with services in Snow Leopard is brilliant and should bring the power of automation to many more Mac users. I suspect this is due in no small part to Sal Soghoian [2] the product manager for automation technologies at apple who introduced me (and about a hundred other transient BFFs) to the new services menu a few months ago.

The Mac OS X Automation web site, which was set up by Sal, is the best place to find out more about services. There are a number of service you can download from the site as well and tutorial on how to roll-your-own as well. There is a good primer article over at MacWorld and a Wikipedia entry about the service menu too.

To some degree I’ve have always tried to live by this creed. It works we’ll for intimate relationships such as the ones many of us have with our computers these days. We all like bright shiny objects and desire is a very strong emotion but we should all stop and think before diving into a new relationship be they Human or Digital and this is especially true of computer operating systems.

History has shown us that shiny new operating systems, like individuals dressed for a night out, are not always what they appear to be. Scrape off the paint and you’ll often find some skeletons in the closet. In the cold hard light of day things often look very different and you can never be sure just what you’ve brought home with you. So it pays to make decisions about a new relationship cautiously rather than basing a long term commitment on a five minute speed date. And, believe it or not, I am still talking about upgrading your operating system.

Single parents beware:

If you have just one computer (or very few) and you rely heavily on it for work / study etc. and everything on it works just fine then don’t be an early adopter. Lets take it as given that new systems are going to have bugs; they may be very few or many, but they will have bugs and if you rely heavily on your relationship being stable you don’t want to dip your toe in the water and loose something important to you.

Yes but there so attractive you just have to have them:

If you don’t want to abstain then you should take precautions. Do your research. Don’t believe what you are being told about the future of your relationship together by the one who want commitment from you. Remember they may be squeezing  your buttocks or they may be checking the size of your wallet. Do some broad research about the OS and the applications you rely on heavily and don’t assume that no news is good news. Snow Leopard was released early and many developers were caught on off guard so some had not finished bug-fixes or product testing. If all else fails shoot an email off to the software developer asking specifically if their software is compatible with the new OS and if you can’t establish a that it is and you really rely on it working then you know what I’m going to say.

I know of one web site that rates ISP by the “my isp sucks” index. Basically they Google “isp name sucks” and see how many hits they get. As of writing “Snow Leopard sucks” produces 67 hits. I’d say that’s pretty low for an OS only release a few weeks ago. If you dig deeper into the sucking camp you’ll often find that the people making these statements made assumptions about the relationship they were going to have without going much past the promises made on a first date. There are many pearls of sage advise on the web about Snow Leopard but you need to be able to read between the lines of those statements made by cast-offs and jilted lovers. So her is just a few words of wisdom from those who believe it is better to work a relationship rather than cast it aside at the first sign of trouble:

Starting point read Apples info about Snow Leopard. No really rrrrread it. http://www.apple.com/au/macosx/

Search the apple support site for “Snow Leopard”. http://support.apple.com

Read the reviews of Snow Leopard: Starting point (bit heavy): http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars Google “Snow Leopard Review”

Check software compatibility: http://support.apple.com/kb/HT3258 http://snowleopard.wikidot.com/

And check with the developer of your favorites.

Remember a lasting relationship is supposed to be built on a sold foundation not a quickie in the kitchen of a share hose in Marble Arch.

Getting revision control software installed and running for a small team can be an onerous task but finding information on how to do it can be more so, so I’ve put together the following end-to-end guide of how we have set up our own revision control server. We chose subversion as our revision control server software as we are a mostly Mac team with a few token WinTel users for system balance. We’re all mad Dreamweaver users (Dreamweaver has subversion client tools in CS4) as does one of our favorite text editors (TextMate) and the box we have to run the system from is an OS X Leopard server. One other reason for choosing subversion is that it came at the right price – free.

So here is the process we went through (minus the back-tracks and stuff-ups) to set-up subversion on OS X Leopard server for revision control of a Website project.

1. Instal subversion

There are a number of methods you can use to install subversion. You can take the geeky route and use MacPorts or Fink but by far the simplest most painless way to do it is to download the binary install from openCollabNet.

Universal Subversion 1.6.2 Binaries for MAC OS X (32 and 64 bit) from openCollabNet  (Universal)

• http://www.open.collab.net/downloads/community/
• http://subversion.tigris.org/getting.html#osx

N.B. Whilst leopard reportedly comes with subversion (Ver 1.4.4 – ?) I think if you are serious about using it you’ll want to get the latest stable release.

2. Test subversion installation

The simple way to test whether or not your install was successful is to open the terminal and type…

$ svn

The response should be…

Type 'svn help' for usage.

3. Create *a* Subversion repository and give the web server user access

The first thing we need to do once we’ve installed subversion is to create a repository where subversion can keep control of your files for us. We’re going to give users access to the repository via a web service so the httpd user, usually www, will need to be able to access the repository.

Create the repository

$ sudo svnadmin create /usr/local/svn_repository

Give the httpd user (www) access / ownership

$ sudo chown -R www /usr/local/svn_repository

Notes

• As in the example above you may need to use superuser i.e. sudo
• Give the repository a meaningful name. Whilst names like ‘repo’ often appear in documents like this ‘svn_repository’ is much more meaningful.

4. Create the basic structure and commit the changes to the repository

Recommended practice prescribes the use of a folder structure that at the minimum, for a single project repository, includes the  folders tags, branches and trunk. This style of repository layout may not be suitable/necessary for all projects but it’s good practice to start this way.

Were going to be creating some folders then committing them to the repository to create its initial structure so its best to cd to temp space to do this.

$ cd /tmp

Checkout the repository: Checking out the repository creates a working copy and forges a link between the working copy and the repository. FYI ‘co’ is short-hand for checkout.

$ svn co file:///usr/local/svn_repository

Checked out revision 0.

cd into the working copy

$ cd svn_repository

Create the basic structure in working copy

$ svn mkdir tags branches trunk

A     tags

A     branches

A     trunk

Commit the content of the working copy to the repository: FYI ci is shorthand for check in.

$ sudo svn ci -m "initial structure"

Password:

Adding    branches

Adding    tags

Adding    trunk

Committed revision 1.

Having created an initial repository we have made it easier to create and test a HTTP connection to the repository.

5. Configure HTTP access via the built-in Apache 2.0 web server

5.1. Activate the required Apache modules

Open server admin and select the web service on the server you want to configure.

Select Settings then Modules and check the box next to the following modules…

• dav_module
• dav_fs_module
• dav_svn_module
• authz_svn_module

Click the save button

5.2. Enable WebDAV on your site*

Switch to Sites and select the site you want to host the service (if you have more than one).

Select Options and check the box next to WebDAV.

Click the save button.

• This may not be necessary?

5.3. Create a Realm

Access to the subversion repository will be controlled by the Apache web service not through subversion itself. This make life a lot simpler and if you have a third party access control mechanism such as an LDAP server it makes it very easy to configure this.

Whilst you are in Sites with the host service selected switch to Realms.

Click the plus button under the Realms list and enter the following into the enter information for the realm dialogue…

• Realm Name: svn_realm
• Authentication: Basic
• (Change the dropdown from Folder to) Location: /svn

Click the OK button.

Click the plus button under the User & Groups list then drag and drop users to the list and modify there permissions accordingly. Most svn users will need ‘Browse and Read/Write WebDAV.’

Click the save button.

5.4. Edit the Apache site config file

Locate the site config file related to the site hosting the svn repository. The usual location is ‘/etc/apache2/sites’ and the file name should start with ’000x’ followed by the site name and then the extension .conf.

Find the section of the config file that begins with the line ‘<Location “/svn”>’ and add the following lines at the end of that section…

 DAV svn

 SVNPath /usr/local/svn_repository

Save and close the config file and then restart the Web server by stopping and starting it again in Server Admin or using apachectl restart in the termainal.

N.B. If you add users to the realm after making these configuration changes the server will rewrite the line ‘DAV svn’ to ‘DAV off’. A fix for this is to put the two lines above in a file called ‘svn.conf’ in the ‘/etc/apache2′ folder and replace them in the site config file with an include statement.

6. Create a working copy on the server and give httpd (www) access to it

We can’t use the repository directly as a web site because it is in reality a database and as a pile of files makes no sense. The solution to this is to have subversion output the files to a directory which the web sever can use a site root. The best way I’ve found so far to do this is to create a working copy of the repository and have subversion update it when content is committed. The fist step in this process is to create a working copy of the repository and then give httpd access to it.

Create a folder for your web site. We’ll use ‘htdocs’ in this example.

In the terminal cd into the htdocs folder…

$ cd /htdocs

Checkout the repository into the htdocs folder…

$ svn co file:///usr/local/svn_repository/trunk .

Checked out revision 0.

Notes

• We checked-out the trunk and not the root of the repository. Trunk usually contains the most up-to-date content of the project.
• The period on the end of the checkout command, for those of you who don’t know, simply means ‘here’ in terms of the servers file path. In this case it means ‘/htdocs’.

cd out of the htdocs folder and change the ownership of the files to give access to the httpd user (www). If you remember earlier we set the server up to give users of subversion access via http so when users interact with service httpd will be doing the work for them.

$ cd /

$ sudo chown -R www /htdocs

Next we need to configure our subversion repository to update the htdocs folder when users commit content to the repository.

7. Edit the post-commit file to update the working copy when users commit content to the store

Locate the ‘post-commit.tmpl’ which usually lives in the ‘hooks’ folder in your repository in this example set-up you will find at ‘/usr/local/svn_repository/hooks/post-commit.tmpl’.  Open it with your favorite text editor (one that can handle editing files as superuser e.g. BBedit or TextMate) and save the file as ‘post-commit’ (no extension) in the same folder. This file is a shell script that subversion will run after content is submitted to the repository.

Add the following lines to the script after the line ‘REV=”$2″‘…

/usr/bin/svn up --non-interactive /htdocs

N.B. The full path to svn may not be necessary but its a good safeguard.

Save the post-commit file and make it excitable.

e.g. from the terminal…

 $ chmod a+x post-commit

Now when ever a user commits a file to the repository the working copy in htdocs will be updated. All that remains to be done now is for the web service to be pointed at this folder as its Web Folder.

References

• http://www.sonzea.com/articles/subversion-trac.html
• http://agileshrugged.com/blog/?p=14
• http://svnbook.red-bean.com/en/1.2/svn.branchmerge.maint.html
• http://svnbook.red-bean.com/en/1.2/svn.reposadmin.projects.html#svn.reposadmin.projects.chooselayout