Version Control for Flash RIA Projects

This covers how we're using CVS for version control during our Flash RIA development projects and provides a few guidelines for folks who are just getting started with CVS.

Ted at PowerSDK has a great post today about version control systems and CVS in particular. If you are doing any kind of even medium-scale Flash app development, especially with more than one developer or designer on a team, you really need to set up some kind of version control system.

NOT JUST FOR BACKUP

Most people look to version control systems for backup/restore functionality so you don't lose your important source files. This is a big benefit, but some other features are just as valuable:

• Keeping multiple developers and designers in sync and preventing people from inadvertently overwriting other people's work

• Recording a sort of developer's journal of the project in the form of comments that people can add when they check in new versions

• Being able to see exactly what changed in a file since the last time it was checked in. This is one of the best reasons to use external ActionScript files instead of in-frame scripts. Most CVS client software provides some sort of "diff" function which lets you see the incremental changes in files from one version to the next -- but only for text-based files. This functionality won't work if you write your scripts inside of .fla files, but it will with external .as files.
  

The downside is that version control software can be complicated to set up sometimes, and if you use something other than CVS it can get pricey. Plus you need a central server somewhere to host the version control repository, either by setting the server up yourself or signing on with a CVS hosting service like VersionHost.

Luckily the client software for CVS is getting better and better. We use WinCVS, but there's also a product called TurtleCVS for Windows users that makes checking files in and out just as easy as using the Windows Explorer. See Ted's post for a list of links about CVS and where to get all the tools.

WHAT TO SAVE

One of the trickiest things is knowing what to save in your version control repository, and how to organize it. You want to limit it to just the essentials, because each file you manage in CVS requires some overhead. If you work remotely there's upload and download time to consider too. Flash source files can be quite large sometimes, especially if they are graphics- or sound-intensive.

Here in case anyone finds it helpful, here are the types of Flash-related files we currently manage in our CVS repository:

• Flash source files (*.fla). Make sure these are checked in to CVS as Binary files.

• External ActionScript files (*.as). Checked in as Text files. These are text-based files, so storing them as Text will let you do diff's on different file versions, which can be invaluable. Since we are using AS 2.0 exclusively these days, these source files are nicely organized according to the package hierarchy. This hierarchical view works very well in CVS.

• Flash project files (*.flp). We store these for initial convenience. sine these project files provide a great brid's eye view of everything on the Flash side of the app. Because each developers works a little differently over time, though, we have only one person keeping the project files up-to-date. The other developers can choose to update these files from the repository, or they can do their own thing with the project files and never update them.

• External image files, text files, and other assets. We decide about these on a project-by-project basis but almost always we include these in the CVS repository. If all project files are there in one makes it much easier for a new developer to check out the entire project in one fell swoop. One exception is sound files, which can be quite large. CVS doesn't work very well as an MP3 storage solution for any but the smallest sound clips.

• Design documents. On larger projects we'll have a directory containing specification documents, data models, or other diagrams that describe the scope and details of the app to be built. Again the idea is to put everything that the team needs in one place for easy access.

• Documentation files. Usually we're talking documentation for end-users of the software, in whatever form it's developed (HTML, text, Word files, etc. - but generally not .PDFs). Sometimes we also manage developer-targeted documentation here, especially if it covers internally-developed components or utilities that other developers on the team will use.

We generally don't include the Flash runtime files (*.swf) in CVS. The idea is that CVS stores all the things you need to publish the app, but doesn't store the compiled app itself.

One exception to the "no .swf" rule is shared libraries that get delivered as .swf's. Sometimes this can be a good way of distributing shared components or other library items to your other team members without letting them change them or potentially mess them up. If it's a homegrown shared library, you'll probably have another CVS project where the source for the library .swf is kept, but you won't give everyone access to that source.

I won't get into other file types in this post (like HTML files, source code for the server side stuff, etc.). Suffice it to say we usually include all of these things in different directories in the CVS hierarchy under one common Project-level directory.

Anyone else out want to share tips on using CVS or other version control systems when developing Flash RIA's? Send an email or leave a comment!

Comments

[Owen van Dijk]

We do the same, and we also run multiple branches and enable tagging, across versions. Also we run daily builds against the CVS repository using Ant. At last, we do deployment right from CVS. We also run projects from SourceSafe, which has a different implementation of Version Control, namely that only one developer can work on a file, basically having a lock on it.

[Olaf Schmidtmann]

Thanks, very good info. We just started to work this way and came up with the same results. Reading this it quite a relief :-)
I think there is a way to work with locked files in CVS, too, which may be an option in small teams.

[Rob Dixon]

Owen, yes SourceSafe is another option, though we found it is horribly slow when doing check-outs of large files (like FLA's) remotely. That's especially a problem when your team is widely-distributed geographically. SourceSafe works fine over a LAN though.

Olaf, good to hear this matches with your experience so far! We've been able to work with locked files by asking each developer to do a "reserved edit" when checking out. It's not foolproof because a clever developer can always get around the restrictions, but it does provide an indicator when someone else is currently editing a file. That's useful with Flash files, bcause you're not able to "merge" text changes inside of binary files like FLA's.

[Cameron Gull]

I've been using SourceSafe working on a project with 5 different developers and you're right... it's quite slow. The ONLY benefit is that it integrates with Flash MX 2004 Pro. I would much rather use CVS, does anyone know if there's a way to do a check-in/check-out from within Flash as you can with SourceSafe? That would make my team's year! (the funny thing is that we're developing for Micro$haft and I don't know how they'd feel about us using CVS... LOL!)

[jon]

Nice article! We're using svn, and it works fine, except sometimes developers tend to overwrite each others binary files (svn has no locking mechanism).

How are you building the SWFs? Are you using the Flash Ant task, or do you have a manual process?

[eCee]

I see you mention that .as files can be checked into CVS as text files. However, i found that the flash actionscript editor places 3 characters in the beginning of .as files which are not in the ASCII range - they are 0xEF 0xBB and 0xBF. My Wincvs (2.0.2.4) complains about these non-ASCII characters and won't check the .as file in as a text file.

Flash does not seem to mind if the 3 bytes are not there when opening the files. So I can remove these 3 bytes with an text editor before checking the code in. But that is a bit of a pain as the next time i save the file in flash editor it adds them again.

Does anyone know of a solution?
Btw, Flash version is MX2004 professional 7.2

[Rob Dixon]

eCee,

I believe those three bytes are UTF-8 indicators. Flash lets you save your files with UTF-8 Encoding or Default Encoding. In Flash 8 you can change this by going to Edit > Preferences > ActionScript and changing the values for Open/Import and Save/Export to "Default Encoding".

[pennywoo]

We are using CVS but we don't know how to set it up so that the developer has to check in and check out files. Can someone point me in the right direction please? We are hiring new developers and this could be a problem. Thanks in advance.

[Kirtimaan]

My flash files contains AS code in FLA itself (not using the external .as files). Is there any version control system / software which can give me feature of comparing two FLA and listing difference in both ?