I’m working on a fairly complex Flash ActionScript 2.0 project with several dozen classes, coordinating changes with another programmer. We’ve coordinated our changes pretty well; however, the methodology is an informal “Hey, I’m editing xxx.as, don’t touch it!” style of source management, with periodic archiving to take snapshots of the entire development environment. So while it works, I wanted to try using a “real” Source Code Management (SCM) platform…enter Subversion.

For those of you unfamiliar with source control, it’s a way of allowing multiple programmers access to a set of source files (called a “repository”) simultaneously. Each programmer does a “checkout” from a source control server, which puts a copy of all the files on their computer. Programmer A can make a modification to a file, then do a “commit” to put that changed file back to the server. All the other programmers on the project can retrieve the changed file by doing an “update”, which copies new files to their machine.

So far, that’s not very different from what you already do without source control. The big problem is when two programmers are modifying the same file and are clobbering each other’s copy. Ordinarily, the changes are seamlessly merged into the The source control server will detect this and inform the programmer of the differences. These changes are marked in the source file, and the programmer resolves them before being allowed to do a “commit” back into the repository. That’s pure gold!

Additionally, each commit to the repository increments the version number. If at any point you need to revert to a previous version, you can just do a re-checkout and specify which version you need.

Another good thing is that using svn to get updated files works around the Flash compiler timestamping problem. When a file is copied onto another file, Flash MX 2004 internal makefile doesn’t always notice this, so changes aren’t detected and recompiled. The workaround is to open the new file, make a trivial change, and resave it. To save time, I use a “touch” utility to update the timestamp of all the files. By using svn update, you get all the new files in one fell swoop and they’re automatically timestamped.

That’s the basic idea behind Source Control. I’m pretty new to it myself, so there are a lot of nuances I am still grasping. There’s a free book I’m reading online, Version Control with Subversion, that is surprisingly well written.

So what do you need to get started?

• You need to have a subversion server. The server is something you can download here to install, or you can get subversion hosting online; this tends to include issue tracking and group collaboration tools also.

• You need to create the repository on your server machine, and enable its network connections. You may optionally implement usernames and passwords. This is installation specific, so I won’t go into it. Read the book.

• You need a subversion client, which is what connects to the server to send/retrieve files from the repository. It’s specific for your operating system. I installed TortoiseSVN, which integrates into the Windows Explorer. On the Mac I installed the command line version for Mac OS X, as the GUI versions do not currently support username and password logins for repositories.

• Once you have your client talking to the server, you need source code to check in. Prepare a directory somewhere on your computer for this purpose, separate of your actual development area. Use the “svn import” command to copy everything the repository for the first time.

• After that, do a “svn checkout” from the repository back into where you plan to do development. Preferably an empty folder just for this. You’re now ready to develop! Read the book for more info…there’s a good overview in there that is much more detailed.

<

p>Today will be the first day we really try collaborating using this source control system. We’re continuing to use a CHANGELOG.TXT file, but it’s versioned now in the source tree. Apparently there are ways of integrating subversion with issuetracking (we’re using FogBugz for this project), but haven’t seriously explored this option. Reports as events warrant.

Issues we’ve had so far:

• Telling SVN to ignore SWF files. First, make sure they’re not checked into the repository (an SWF was, which messed up commit operations). You can also tell your SVN client to ignore them.

• Make sure you close all open documents in Flash before you do an svn update/commit cycle. Unlike other IDEs, Flash isn’t aware when you change an ActionScript file out from under it, so there is the possibility of overwriting your update inadvertently and then committing it unchallenged (subversion will think you merely corrected it). We had a couple instances of this before we figured it out.

• With the client I’m using, TortoiseSVN, there are problems with Macintosh-style END-OF-LINE markers. This is an old old problem reaching back into the depths of time: Apple IIs / Macintoshes used CR (Carriage Return, ASCII 13) as the EOL character. PCs used CRLF (Carriage Return + Linefeed, ASCII 13 + 9). Unix uses just LF (linefeed, ASCII 9, also known as your good buddy n). Well, the Flash Mac OS X client converts everything to just CR, and this messes with TortoiseSVN which for some reason doesn’t recognize this by choice. Although every other text utility in the world with multiplatform text support supports this, TortoiseSVN has chosen to take a stand and refuse to support this archaic line ending convention. The end result is that merges and diffs–the comparison between the old file and the new file, with convenient marking of the differing lines of code–are completely hosed.