One of the biggest annoyances when trying to test a Flash application is when you don’t know what version your user is currently looking at, this might be due to caching issues and what not.

The obvious solution is making sure your user can see the version number of your application at run-time and include that with a bug report or similar. I’ll be covering two different techniques to accomplish this.

Using conditional compilation

Our initial and current approach is using svnversion and compiler.define via Ant to include the version number as a constant.

<target name="Build">
	<exec executable="/usr/bin/svnversion" outputproperty="svn.revision">
		<arg value="."/>
	</exec>
 
	<mxmlc file="SomeApp.as" output="bin/MyApp-release.swf" debug="false">
		<source-path path-element="src"/>
 
		<define name="CONFIG::version" value="${svn.version}" />
	</mxmlc>
</target>

This approach works just fine but you’re somewhat tied to using Ant to build you projects.

Embedding your entries file

After using svnversion for a while I thought there has to be a way to embed the version number using any compilation method, which lead me to the [Embed] meta-tag of AS3. This allows you to embed any file when specifying a mimeType of application/octet-stream.

You could for example embed a PSD file and read something from it at run-time.

[Embed(source="SomeFile.psd", mimeType="application/octet-stream")]
var SomeFileByteArray:Class;
var bytes:ByteArray = (new SomeFileByteArray()) as ByteArray;
 
trace(bytes.readUTFBytes(50)); // Read the first 50 bytes

And after tinkering around in the secretive .svn directory I came up with the SVNUtil class.

package {
	import flash.utils.ByteArray;
 
	public class SVNUtil {
		private static const VERSION_PATTERN:RegExp = /dir\xa(\d+)\xa/;
 
		[Embed(source="../.svn/entries", mimeType="application/octet-stream")]
		private static var _entriesByteArray:Class;
 
		public static function get version():String {
			var entries:String = readEntries(20);
			var matches:Array = entries.match(VERSION_PATTERN);
 
			if (matches) {
				return matches[1];
			}
 
			return null;
		}
 
		private static function readEntries(length:uint):String {
			return (new _entriesByteArray() as ByteArray).readUTFBytes(length);
		}
	}
}

To use it, simply refer to it somewhere in your application.

public class MyApplication extends Sprite {
	public static const VERSION:String = SVNUtil.version;
 
	public function MyApplication() {
		trace("Application version:", VERSION);
 
		// Or you can call it directly
		trace("Application version", SVNUtil.version);
	}
}

As a final note this is experimental hacking, but it’s done at compile time so you won’t have to deal with run-time errors, I’m planning on posting up a similar class for Git when time allows.

Subversion isn’t exactly renowned for graceful handling of branches, so naturally merging is a pain in the ass. However after smashing my head in the desk more than a couple of times doing this I thought I’d write a small tutorial on what might seem like voodoo bereft of logic.

Note: I’m using Terminal in OSX throughout the example but it should be perfectly doable in cmd on Windows as well

Requirements

• Subversion command-line utilities (somehow the fancy merge dialogs of Subversive/Subclipse make things even more confusing)
• A subversion repository containing a branch and a trunk

Better safe than sorry

Before we start the actual merging I should mention there are ways to merge two Subversion URLs directly without staging the final commit, I just like to play it safe.

Now fire up Terminal (in Applications/Utilities) and let’s get cooking.

We start by checking out a copy of our trunk (to which our branch changes will be applied) so we have a clean working copy to work with.

$ svn co http://svn.test.com/client.project/flash/trunk staging
$ cd staging

Now we need to figure out the “base” of our branch, this is the revision where we first created our branch.

$ svn log -v --stop-on-copy http://svn.test.com/client.project/flash/branches/cool_feature

The last part of the output will read something like this.

------------------------------------------------------------------------
r155 | simen | 2009-10-12 11:37:52 +0200 (Mon, 12 Oct 2009) | 1 line
Changed paths:
  A /flash/branches/cool_feature (from /flash/trunk:116)

Now we know that the branch was created in revision r155. If your are asking yourself “why doesn’t SVN know this itself” the answer is “because it is really bad at branching and merging”.

Now for the actual merge.

$ svn merge -r 155:HEAD http://svn.test.com/client.project/flash/branches/cool_feature

Again a bunch of text will rush by and probably stop a number of times with the conflict prompt.

Conflict discovered in 'src-external/ui.fla'.
Select: (p) postpone,
        (mf) mine-full, (tf) theirs-full,
        (s) show all options:

For human-readable files like source-code, SVN will attempt to merge the two revisions automatically or you can merge the differences by hand in a normal-text editor.

For binary files you only have two choices, mine-full which tells SVN to use the existing file (the one in trunk), and theirs-full to use the file from the branch we are merging from.

Once the merge is complete we’re back at the command-line, but before committing the changes, let’s make sure everything went as it should.

$ svn diff

After you’ve looked over the changes, it’s time to finalize the merge by committing.

$ svn commit -m "Merged cool_feature branch back into trunk"

You can now update your existing working copy of trunk and see the fruits of your merge.