Phase.org

OK, this *is* described by CCP on the EVE forum, but it's spread around over several posts and pages and doesn't clarify that some steps may not be required. In any case, it's a bit of a clumsy process. The most critical point is that you may not need to run a patch.

So here's what worked for me:

Notes; TQ refers to Tranquility, the "live" server. SI is Singularity, the primary "test" server.

1. Rename your existingEve Online.app to Eve Online - TQ.app (or similar). (This is to protect it from overzealous patching).
2. Copy that app to Eve Online - SI.app
3. Go into your EVE settings folder:
   /Users/yourMacUser/Library/Preferences/EVE Online Preferences/p_drive/Local Settings/Application Data/CCP/EVE/c_program_files_ccp_eve_tranquility/settings.
4. Copy the prefs.ini file to prefs.ini.TQ
5. Open the original prefs.ini file in a text editor and add the following final line:
   server=87.237.38.50
6. Copy this new prefs.ini file to prefs.ini.SI
7. You can now start the Eve client app. Make sure it's the SI copy.
8. The login area should look something like this: (The important thing's that it says "Server: Test Server (Singularity))."
   
9. Various things can happen at this point:
   • If the display is as shown, you can log straight into the test server. Enjoy.
   • If server status is Offline, Singularity's down (it's a test server after all and downtime varies). See the Eve Servers Status page to confirm.
   • You may get an "Incompatible Protocol Version" message. This means your Singularity copy of EVE needs to be patched. Chances are it'll offer you a patch download automatically. Accept it only if you've got two copies of Eve Online.App as above.
   • You may need to patch manually. If so, visit the Mac Singularity Patch Page and download the patch application. Make sure you run it on the Eve Online - SI.app not the TQ one!
   If you run a patch, either automatically or manually, it will rename your Eve Online - SI.app back to Eve Online.app! This is what we in the software industry technically call DUMB. Make sure you rename it back to Eve Online - SI.app straight away. Otherwise the copies will collide at some point.
   Note that any time you patch your live copy it'll also do this. Make sure you tidy up after it!
10. If you've run the patch and renamed the app, you can now run it and connect to the test server.

IMPORTANT NOTE! You now cannot connect to Tranquility even with your Eve Online - TQ.app copy! To do that, you'll need to copy prefs.ini.TQ back over prefs.ini (or just remove the server line from it, and then run Eve Online - TQ.app
You will need to copy or edit prefs.ini every time you change servers!

Now, in my professional opinion as a software developer and sysadmin, that's a lot of hoops to make your testers jump through. No doubt CCP wonder why they get so few early bug reports from Mac users... I hope they'll make this process simpler soon; if not I may try to provide an automated tool to do the above for you.

A 30 minute podcast doesn't need a 5 minute into track.

A 10 minute cast really doesn't need a 2 minute intro and 2 minute out-tro. Especially when they're the same each week.

Guys, we listen to your podcasts for the content, not for a mix tape. Please keep focussed. 1 minute should be the upper limit for *any* intro or leadout track; 30 seconds is probably plenty.

Back when I was an RAF cadet, we had to study Aircraft Recognition, presumably on the premise that we'd one day have to know which ones to shoot down.

In Eve, it's often vital to recognise ship types and threats instantly from their names, so I'm working on a flashcards app. This can now be found at http://www.phase.org/Eve/showRandomShip/view/flashcard (or jog your memory at http://www.phase.org/Eve/showRandomShip/ first).

So far it's a click-to-view toy with no scoring - that will follow shortly.

Questions - should this include Rookie ships? Polaris? Jovian? There are 124 "special" ships in the DB which I could filter out. (NB: The Orca's already in there, but with the Rorqual's description).

For some time now I've been playing the MMOG "Eve Online"; a game of epic space battles and warring factions in the far future (and so on). Think "Massively Multiplayer Elite with Babylon 5-style graphics".

Eve is famous for various key ways it differs from most other MMOGs:

1) It's unsharded. All players (0.25 million at the last count) play within one server cluster, and any player can (subject to not getting blow up in transit) travel to, and play with or against, any other player.

2) It's extremely free-form. you can choose to mine, build, invent, explore, run missions, fight solo, run megacorps, carry freight - there's a vast in-game economy - and change roles as rapidly as you can train new skills.

3) The learning curve is incredible (although there are no shortage of newbie-safe areas); it can literally take years (of real time, not in-game time) to qualify to fly the largest ships, and months for some of fairly common intermediate ones. The skill tree is colossal.

In other words, it's a highly complex game that occasionally causes you to reach for a spreadsheet (or dedicated app) to work out what to buy, how to equip a ship, or what to study. Fortunately, there are very good tools - and, even better (for my purposes), there's a good supply of data through an API and periodic DB exports.

The DB and API (and a certain degree of transparency in sharing key formulae) allow the use of skill planning apps such as EveMon and ship fitting tools such as the Eve Fitting Tool. They also allow very simple tools as Skill Monitors, and more complex tools that let you search and analyse all your in-game assets.

At the moment, there are some very good tools for Windows, a few less-great ones for the Mac, a decent range on the web, and no iPhone apps. So, I'm looking to fill that gap.

I'm not a Mac coder; I've never written a line of Objective C or cocoa; I'm a PHP developer. But that also means I've a decent object-oriented programmer, and I've got a reasonable C/C++ background. So, I'm initially experimenting with the (XML/REST) API in PHP, while I learn enough about it and Objective C to move to the desktop or the phone.

So far, I've got a crude skills monitor (was there a shortage?), and, more interestingly, a complete asset viewer that also lets you see complete fittings and cargo of all your ships. These tools are currently web-only (hosted at phase.org) and currently open to a very small closed alpha test. However, they will grow, so if you're interested in access or have suggestions, comment here. Priority for alpha/beta access will go to members of my Corporation (Ominous) and Alliance (Ethereal Dawn).

(For what it's worth, the other thing I'm looking to write for the iPhone will be a decent LiveJournal client).

to see if Zend Studio crashes again.

I used to be fairly happy with Zend Studio, but these days it seems to be featuring as one of the banes of my working life. As a developer it should be the program I spend most of my time using (and so needs to Just Work), and indeed on my own system at home (smallish codebase, local files & webserver) it does. Usually.

In the office, however, we have a much bigger codebase, shared mounts for sandboxes (as per the ongoing series on this blog), and an occasionally slow or patchy network. This gives Zend Studio (both 5.5.x and 6.0.x) a myriad of ways and reasons to fall over or just seize up. To be honest, I'm not sure Java's a great language for an app of this complexity, but for whatever reason it will frequently just stop dead, fail to open files, or just ignore all input.

So, to work out how to get around this and actually be able to edit my files (with code completion, debugging, code lookup and all those things which make vim Not An Option), I've been trying to debug my way around the problem.

Firstly, I've been trying to work out if it really is the network that's the issue. So, remove that from the equation: read the files from a samba mount with no network latency; in other words, from a local samba server.

As I've recently received a higher-spec machine at work, with parallels supplied, my first step was to create a small internal ubuntu server with a samba share to see what happened.

What happened was that I discovered that ubutu 8.10 server doesn't run under parallels, although it installs fine.

So, I switched to the Ubuntu JeOS distro instead, which does run. A few apt-get's later and I have a local samba share. I check out our codebase, point a new project at it in Studio 5.5.1, open a file deep in the class tree, and do some other work for a while.

Result: ZDE seizes up and can't do code clickthroughs or open files. Great. So it's not the network. (I'm working on the basis that it's not my new intel 8-core mac, either). Maybe the virtual machine's too slow? Check out to local drive, perform same test, same fail. Ok, so ZDE 5.5 needs to be dragged out into a quiet alley and shot. I've suspected that for a while.

So, chuck out 5.5; try 6.0.1 (which I've tended to avoid as the interface, menu and naming is completely confusing, and it still falls down). And it turns out that I can load, edit and clickthrough a local project if I use a local folder as a project (acheived, uninituitively enough, by starting a new PHP project, and overriding first the file location and then the verification dialogue (and finding that in the manual was fun)).

[As an impromptu aside; ZDE 6 is modal. Very modal. It loves nothing more than to throw up an "information" dialogue that prevents you from editing, saving, or quitting. Except possibly for jumping to the foreground when you're working in another app and it wants attention.]

So, yeah... I can edit locally. Unfortunately, my dev server is my local box (yes, I could set it up that way for myself, but the live server is Linux not OSX, and I'm not configuring local servers for the entire team) and I need to save my files to the dev box. The good news here is that ZDE has a myriad of Remote Systems support; the bad news is that they're utterly baffling. FTP only is easy enough to understand, but then there's 'Linux' (which, last time I looked, was not a network protocol), 'Windows' and Unix (ditto), Local (which didn't sound very remote), SSH only (which turns out to mean SFTP), and Telnet Only (Experimental) which just sounds like bad news.

'Linux', btw, turns out to mean some weird perl/java hybrid server that you have to install on a linux server. Personally, I'd rather steer clear...

Having decided that SFTP looked the best bet, I thought I'd give that a go. Fairly easy (despite the interface's best efforts to confuse matters); set up a server, browse, select a folder and right-click to Create Remote Project. Wait while it refreshes, wait a bit longer while the progress bad gets stuck near the end, and wait while runs out of Java Heap space and crashes with an "Insufficient Memory. This advises you to refer to the "Running Eclipse" section of the readme.txt file; a quick glance in there shows that Zend have removed that section, and indeed most of the rest of the file. Might be nice if they updated their code to reflect this?

A quick google later and I find this page, which tells me to burrow into the depths of ZendStudio.app and edit 'eclipse.ini'.

Of course, that wouldn't do for Zend; they had to rename the file ZendStudio.ini. So, edit that instead.

Setting max memory up from 256M to 1024M crashes ZendStudio at startup. Setting it to 512M or 768M means it gets stuck even longer at the end of the "Create Remote Project" progress bar before crashing.

So, ok, abandon SFTP for now - let's try setting it up as a local PHP project on the Samba share. Set name, set directory, hit "finish", and it hangs - fortunately, only briefly. We can now open and edit files... but as yet, no code clickthroughs; the "processing" bar's spinning at the bottom of Eclipse and it's "building PHP Project" and "building workspace". Experience suggests it may do this forever, so I'm going for a cup of tea.


As suspected, it's got stuck at 4% in the depths of the Zend Framework.


Now what to try?

Erm, force-quit Zend Studio, restart it, and watch it all miraculously work, apparently? Ok, that's a complete anti-climax; maybe the extra memory fixed it. I'll update if it fails again.

In the last installment we set up Trac, and I hinted at a couple of its features. But what should we actually be using it for?

Well, let's take a look inside.

When you first visit Trac, you're presented with a standard intro page that tells you about Trac. It's useful to start, but it's not the key information we're going to want every time we visit the Wiki. As such, I tend to either shift it to another page, or just add new content above it.

This new content should help developers to work with the new systems you've just set up, so useful content to add includes:

• A summary of tools available on the server (with versions)
• How to connect to the dev server via ssh and samba
• Where the central repository is located
• Where each developer's sandbox is located
• How to create and access databases
• Who your local experts are
• Links to library software manuals, the MySQL and PHP manuals etc
• Info such as network setup, mailserver names, all that sort of minutiae

As users may be quite new to these tools, it's usually worth adding a couple of quick reference guides to things like the unix command line or svn commands - either links or you own summaries. Just pasting in the output of svn help is pretty useful.

Beyond this (and while we've not covered these topics yet) it's useful to have notes on:

• Your server's backup schedule and policy
• The coding standards you're applying

OK, so much for the wiki functionality. What else is in here? The nav bar at the top of the page gives us a list of Wiki, Timeline, Roadmap, Browse Source, View Tickets, New Ticket and Search.

Wiki we've seen. Timeline we briefly mentioned last time as a summary of changes made to the code and wiki; it tends to be worth a glance occasionally to sanity check changes and commit frequency and messages. Search is useful too; it lets you hunt for info within all areas of the wiki - and if your documentation is searchable, people use it more and add to it. See below for a way to extend this search and add it to a user's browser for even greater ease of use.

Let's take a look at one more option for now. Browse Source is a link to an SVN repository browser. As is generally the way in Trac, it's fairly lightweight and fairly easy to use. It uses repository connection data that's supplied when you initialise your trac project, and gives you an easy way to browse the repository contents, finding out what's where, who changed it, when, and how. You can do all of this with the SVN command line tools, but it's far easier in here, and a repository browser is invaluable for getting the full historical power of version control.

The browser also has the useful feature that, being part of Trac, it integrates smoothly into the wiki and ticketing systems. By typing r1234 (or any SVN revision number) in a wiki page, you'll get an automatic link to that changeset in the repository browser. You can also link to related files using Trac's source: syntax - check out the TracLinks page in your copy of Trac for more info. Also, any wiki links you add to your subversion commit messages will be linked in the Timeline and Changelogs within Trac.

Next time, we'll take a look at task allocation within a project, with the help of the ticketing system within Trac.

Before we do that though, here's how to add Trac search directly into your Firefox or IE7 browser. It's not the most elegant solution, but it works.

First, we need to create and host an Open Search specification document that can act as a plugin for both Firefox and IE. We'll host this file in the root folder of the webserver which we've set up to host subversion and trac, which in our example is /var/www/html for devbox.example.com

Copy the following into /var/www/html/trac-search.xml:

<?xml version="1.0" encoding="UTF-8"?>
 <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
   <ShortName>Devbox Trac Search</ShortName>
   <Description>Search Devbox Trac</Description>
   <Contact>webmaster@devbox.example.com</Contact>
<Image height="16" width="16" 
type="image/x-icon">http://devbox.example.com/trac/uberproject/chrome/common/trac.ico</Image>
  <Url type="text/html" 
  template=
   "http://devbox.example.com/trac/uberproject/search?q={searchTerms}&amp;noquickjump=1&amp;wiki=on" />
 </OpenSearchDescription>

Obviously, adjust hostnames, paths and descriptions to your own system. Note that the URL constructed here only searches the wiki - I find that's usually what I want to do anyway.

Next, locate the template files for your Trac project. In our example, they'll be at /opt/trac/uberproject/templates. We want to edit the header template site_header.cs. This file starts off pretty empty, and we'll add the link to the search plugin, plus some standard javascript that seems to be required to install a search engine. The resulting file looks like this:

<?cs
####################################################################
# Site header - Contents are automatically inserted above Trac HTML
?>
<link rel="search" type="application/opensearchdescription+xml" 
title="Devbox Trac search" href="/trac-search.xml">
<script type="text/javascript">
/**
 * Install a search engine (opensearch)
 * Returns false in case of success (sic!) because that will keep the file link
 * from being followed.
 */
function addEngine(engineURL) {          
    if (window.external && ("AddSearchProvider" in window.external)) {
        window.external.AddSearchProvider(engineURL);
        return false;
    } else {     
        alert(error_opensearch_unsupported);
        return true;
    }    
} 
</script>
<div style="position: absolute; right: 20px; color: #bbb; cursor: pointer">
<a onclick="addEngine('http://devbox.example.com/trac-search.xml');">Install trac search plugin for IE7 
& Firefox</a>
</div>

And that's it. Each page of your trac project should now contain an install link for the plugin, which will appear in your search box with the trac 'paw' icon.

So, everyone's got their sandboxes and dev servers, and they can all code merrily away and share their code. So far, so good. There are two things we now need: planning and documentation. I'll concentrate on the latter for the moment, by means of a Team Wiki.

There's a lot of odds and ends of documentation that needs to be shared in a dev team; things like Where The Code Lives, How The Servers Work and Those Important Planning Decisions. One way of doing this is just to stick all the docs in a shared drive on the server, but I've never seen that work so well; people can't find the docs they need and don't spot new documents and changes - and equally can't comment on any document or change. This strategy also tends to discourage minor hints and notes which can be invaluable. I find that a wiki works well to solve this problem, and the one I tend to use is Trac.

To be fair, calling Trac a wiki is selling it a bit short; it's also a ticket-tracking system and repository browser, and it ties these elements together well. The Trac site can fill you in on a bit more detail, but for the moment we'll just consider it as as useful location for project documentation.

Installing Trac, thanks to the magic of Ubuntu, is dead simple; just type (as root) aptitude install trac. Ain't Linux great?

Actually, in this case, no. Trac can be awkward to fully set up; the ubuntu and debian packages are (at the time of writing) at least a little broken, and you have to do a bit of magic to finish the setup. Here's the full process that currently works for my Ubuntu servers:

Install Trac, Python and ClearSilver

Most of trac's installation really is achieved with aptitude install trac, but there's still a fair bit of configuration to do.

Possible errors

Skip this block for now and come back to it if the next steps throw errors. You may get lucky and find it's all been fixed.

One common error is that Clearsilver doesn't properly install its python library in the Ubuntu package. The solution (usually in response to an error in neo_cgi.so) is to install the clearsilver library from source and ensure that you add the –with-python=/python/2.5/dir option when you configure it. Full details on that (and other possibe solutions) at https://launchpad.net/ubuntu/+source/clearsilver/+bug/86685

Create your trac project(s)

(you can have multiple projects within one trac install)

This is done with a command-line tool called trac-admin. You need to chose a location for your trac's data files; I tend to go with /opt/trac/whatever.

As trac will be operated via apache, the apache user needs to have full read/write access to all files. So, as root:

root@devbox:/opt/trac# trac-admin uberproject initenv and answer the questions it asks; for more info, trac-admin –help

then

root@devbox:/opt/trac# chown -R www-data:www-data uberproject

Set trac up in apache at a suitable URI

Add the following stanzas to an apache virtual server's config file, eg that for our devbox example:

<Location /trac>
   SetHandler mod_python
   PythonInterpreter main_interpreter
   PythonHandler trac.web.modpython_frontend
   PythonOption TracEnvParentDir /opt/trac/
   PythonOption TracUriRoot /trac
</Location>

Note that there are two ways of specifying the location of the trac files. You can set a path to a single trac as TracEnv /full/path/to/trac (eg TracEnv /opt/trac/uberproject) or have the potential for Trac to automatically find multiple trac sets under one parent directory with the newer TracEnvParentDir, which we use in the above example. Note that getting the wrong directory, or using the wrong directive, will lead to some very confusing errors

Assign user permissions

to allow developers to access the appropriate tools

This is done in a couple of places, and depends on how much public access you want to allow. We'll assume you only want known users to access your system and have no public read access. If you want fully public access, just skip the next steps.

Firstly, you need to create HTTP basic auth protection to your trac URI, as follows:

<LocationMatch "/trac/[^/]+">
  AuthType Basic
  AuthName "Trac"
  AuthUserFile /etc/apache2/trac.htpasswd
  Require valid-user
 </LocationMatch>

You'll also need to set up the htpasswd file as covered previously.

You can then, for each user requiring particular rights, go into trac-admin's interactive mode (root user will allow you to manage the files now owned by the web browser):

root@devbox:/opt/trac# trac-admin uberproject
[...]
Type: '?' or 'help' for help on commands.

Trac [/opt/trac/uberproject]>

Again, I'm not going to duplicate the trac manual here; do as it suggests and type help; look in particular at the 'permission add' command.

Having done all this, you can restart apache and visit your new trac system in a browser.

Once you've got Trac running, all can join in. The features you'll initially find the most useful are the Wiki and the Timeline. I'll introduce the timeline first, because it's simple as well as useful. Simply, it gives you a summary of who changed what and when; it's a combination of subversion's change log and the wiki's revision history, and provides a good way of working out both what you did (or when you did it) and keeping up with other developers' changes. This includes keeping track of who's creating good documentation and change messages, and who isn't.

The wiki is rather more basic than (say) Wikipedia and the syntax is quite old-fashioned (although there's a reasonable internal guide). Page names are generally CamelCase and new pages are created simply by clicking a link to, or visiting the address of, a page that doesn't yet exist. However it's lightweight and fairly easy to use.

In the next installment, I'll go into a little more detail on these, as well as some hints on using the system.

OK, so this site goes 'bang' occasionally. Not ideal for a site that purports to advise on coding and project management techniques, so what's wrong?

Well, part of the issue is that I wouldn't recommend that anyone else code a site in the way that this one's actually being maintained. This code's the nearest I have to a playground, and so sometimes it falls off the swings. A lot of the code's unit tested (and those tests work), but there's still some weird race conditions and sporadic failures.

Why?

Because there are bits of this codebase that date back about 4 years. When I started, PHP4 was young (and I was, well, younger) and I knew nothing of object code, so the first 'PhaseCode' release was purely procedural. No, you can't see that codebase, but if you drop back into the archives you can have a good laugh at my youthful naivety in some of the design notes. These days you can still laugh, but I'm losing that particular excuse.

Then at some point (I can't work it out from the archive offhand) I started wrapping the code up in classes. These classes got slung together in bunches of files that were loosely grouped by "module", and ended up as something of a require() maze.

So, I decided to put away such childish foolishness (I have a feeling this was about the start of last year) and move to a class structure I could __autoload()! Wow!

Except that I did it not in the Zend format of Some/Class/Here.php, but in an older pattern of phasetwo_className_Class.php in a flat structure, which was fairly common around then - I think Smarty still uses it. This was a step forward, but it was a rather different forward from the one I'm now heading in.

Now, I'm using Zend's Some/Class/Here.php (since about this time last year, I think), which is based on a fairly shameful kludge (or, depending on viewpoint, a quick and pragmatic solution to manage a codebase for which no-one else is paying, and of which no-one else has to suffer the pain of maintenance - my pro codebases are stunning ;). That hack is as follows:

• Classes starting with phasetwo_ are autoload()ed from lib/phasetwo_someClass_Name_Class.php
• Classes starting with PhaseTwo_ are autoload()ed from lib/PhaseTwo/SomeClass/Name.php

Yeah, I can hear you wincing from here. Now you know my shame; my autoloader switches by case. The real fun comes as I move files from one location to the other; as I do so I have to change the case of every mention of that class in the rest of the code; sometimes bits escape, but the code works if the correct case was mentioned first, because while my autoloader is case sensitive, PHP's class naming isn't. (Yes, I heard that wince too). This provides no end of fun opportunities for hard-to-find bugs and race conditions, some of which make no sense even after I fix them. Failures inside callbacks (including the ancient template parser I still use) are even harder to find as the PHP interpreter tends to fail without either error or exception.

But hey, it's all fun ;) And now you know why I keep blowing my site up - because I'm not allowed to do it to anyone else's.

(But, seriously folks - don't try this at home ;)

A mere three posts in, and I think there's going to be enough content to keep me going for a while. I'll be revising the content as I go to make it more coherent and readable, and to add newly discovered tricks and ideas as I go. Comments and questions are welcome - I've fixed the comment system, but you can also mail me (richard@phase.org).

To follow (in some order or other)

• Documentation with Trac
• The joy of specs
• Project planning with FogBugz
• Automated testing with PHPUnit
• Release procesures
• Scrum: keeping the team informed
• The value of electric rabbits

Covered so far

• Sandbox servers
• Basic subversion usage

Last time we got as far as checking out the code from a local repository, and I promised we'd take a quick look at some ways of managing the repository as a network server.

There are three benefits to this:

The first that you don't have to make the whole repository writable by (and therefore susceptible to accidental damage by) all of your developers (and conversely you don't have to manage all the user and group privs and file permissions that all of them might use, which ends up locking someone out of part of the repository).

Secondly, you can give access to developers (or reviewers, managers etc) who don't have direct access to the server or need to work remotely. Even if you're using the shared drive strategy previously covered, network access also lets you use desktop SVN clients rather than ssh'ing in to the linux shell to run commands there. (Personally, I generally find the shell friendly and easier to use, but YMMV...)

Thirdly, you have the possibility of more finely-grained and easier to manage access control; you can set up groups to read and right, and even limit access to certain parts of the repository.

There are two server systems you can use: svnserve and apache (http). We'll use apache here as it works well alongside our test webserver, and has fewer problems with firewalls than svnserve.

To use apache as an svn server, you'll need to install its DAV and SVN modules. In ubuntu, this is simple: sudo apt-get install libapache2-svn (I'll assume you're on apache 2; if not, check your calendar).

Ubuntu will then create a file called /etc/apache2/mods-available/dav_svn.conf, which you'll most likely want to completely comment out and replace with a more useful configuration (but do take a read of it).

(As an aside, you may need to execute a2enmod dav_svn; I can't recall if it's enabled on install. In any case, you'll need to restart apache for it to work).

Your config, inside a standard vhosts configuration, will look much like the following:

<VirtualHost *>
    ServerAdmin webmaster@example.com
    DocumentRoot /var/www/html
    ServerName devbox.example.com

   <Location /svn/uberproject >
        DAV svn
        SVNPath /opt/subversion/uberproject/repository
        AuthType Basic
        AuthName "Uberproject Subversion Repository"
         #<LimitExcept GET PROPFIND OPTIONS REPORT>
        Require valid-user
        #</LimitExcept>
        AuthUserFile /etc/apache2/svn.htpasswd
        satisfy all
   </Location>
</VirtualHost

So what's going on in there? Well, we're adding a svn path to a (possibly pre-existing) virtual host - in this case, our devbox.example.com server. We then add a special rule for the URI http://devbox.example.com/svn/uberproject to use the SVN DAV adapter to link to the repository at /opt/subversion/uberproject/repository

The rest of it (from AuthType downwards) sets up access control. Anyone who wants access will have to be listed in the /opt/subversion/uberproject/repository file. If you want public read-only access, remove the # marks to uncomment the LimitExcept lines.

You can create and edit this file with the htpasswd command:

root@devbox:/etc/apache2# htpasswd -c svn.passwd someuser
New password: 
Re-type new password: 
Adding password for user someuser

Note that you only need the -c switch the first time you run the command; once the file exists you can drop it.

Note that for your respository to be usable, the repository files themselves will need to be read-writable by the user than apache runs as. On Ubuntu and Debian, that's user and group www-data. See the last installment for how that worked - if you move all your users to http access, they won't need direct write access.

You can now use the URI http://devbox.example.com/svn/uberproject to refer to your repository where we used the file:// URI before.

I'm not going to cover svnserve access here; take a look at the chapter on "svnserve, a custom server" in the SVN book if you're interested.

In fact the SVN Book (aka the Red Bean book) is an excellent reference resource for SVN, so keep it bookmarked.

I'm not going to go through the full functionality here, as the SVN book will cover it all and even the built in help is very good. To use that, just type svn help at the command line. However, here are the most common commands:

svn checkout URI

Create your sandbox by checking code out from the repository. Don't try and use this in an existing sandbox! Short form: svn co

svn update

Update the current sandbox directory and all subdirectories from the repository. Short form: svn up

svn add FILENAME

Put the specified file (or directory and subdirectories) into version control. Note that this doesn't send the files to the repository; you still need to commit.

svn commit

Send all controlled changes in the current directory and subdirectories to the repository. Add -m 'Commit Message Here' to add a log message; otherwise it'll try to open an editor to take one. Short form (that no-one remembers): svn ci

This is obviously a very short list, and there are many more commands. Use the svn help or red bean for more info; we will probably touch on some (much) later in this series.