Version control for Adobe Flash projects

Question

I'm working with a very complex Flash project which is part of a full range of services that we deploy for the use of our clients. For most of our software sources (Java, PHP, Javascript, HTML and a some supporting scripts in other languages) we use subversion for version control and management, so we do the same for our Flash projects, even though we gain little benefits from version controlling that (except being able revert to previous versions) as FLA files are stored as just binaries which we cannot get meaningful diffs from.

We're putting as much code as we can into AS files which we can properly manage using subversion, but due to the requirements of our architecture and our deployment strategy (both we cannot change because of our clients needs), we still maintain a large collection of FLA files that we need to manage.

I've looked at Adobe Version Cue and while I do not really understand what it does in terms of version control, will moving our Flash projects to hosting on Version Cue will give me better control then I currently get from Subversion?

Also - if people can share their experience and suggestions regarding version control of Flash projects, it will be very helpful.

Answer 1

I've struggled with this myself, and I can't tell you anything other than:

1. No code in FLAs, ever
2. Divide content semantically into separate FLAs where appropriate
3. Make a change document for FLAs, and enter a note for every single change.

The first point is obvious enough. The second is to recognize that there's no getting around the fact that FLAs are binary blobs that hold all your visual assets and don't play well with versioning, but you can recognize the fact that some contents change frequently while others tend to be created once and then left alone. By dividing your assets into different FLAs, you can keep the large majority of changes into a small number of unstable FLAs, and the difference between stable and unstable content will be reflected in your versioned files.

Note that even if you can't load assets at runtime, compile-time sharing still lets you divide assets into an arbitrary number of FLAs. (Compile-time sharing is often overlooked - if you're not familiar with it, open a MovieClip's properties and check out the "Source" section at the bottom.) How to divide things will depend your project. The best I can suggest is to make divisions semantically - perhaps one FLA for each character, or one FLA for each section, or one FLA for each interface element, etc. As with all development the goal is to group related assets and eliminate duplication.

The third point is, since diffs are impossible, there's just no way around keeping a change document. My preferred way is to check the FLAs into versioning and note all changes in the check-in note, but the changes could also be in a separate document. (Note that it's vital that you keep the libraries in each FLA orderly, or someone reading the change description will have trouble finding the change.) However, since this can be a pain for some contents, it's also useful to designate certain FLAs as "unstable", and not bother with a change list. But if such files have a lot of dependencies on other files, you'll regret it later.

Unfortunately this is all I've discovered so far. Adobe has talked about changing to a text-based FLA format in a future version, but until that arrives, there's no easy solution.

Answer 2

Adobe's answer to this is in the new CS5 Flash. Use "save as" and choose .xfl from the types pull down. You can now work on your project and check it in via SVN. I would still break out your code in .as files but this way your library assets are also tracked. It basically keeps everything in xml markup kinda like flex mxml. I think this is your best option.

Answer 3

It sounds like you are stuck with FLA files due to external requirements but, just in case...

If you're building a code-heavy flash project, I would go with a pure actionscript or flex approach, using .fla files only for what they are good for (timeline-based animation)

Flex Builder / Flash Builder is a great environment to build Flash projects where all the code is in source-control friendly file formats.

We're in the process of moving all our FLA based media players over to MXML (where the Flex UI components are useful) and pure ActionScipt projects. Thje source control benefits are huge.

If that is not possible then I'm afraid the only thing you can do is move as much stuff out of FLAs as possible - the binary format is simply not source control friendly.

Forget version cue - Adobe doesn't develop it any more (It's not included in the new CS5 bundles)

Answer 4

From what I understand of Adobe Version Cue, it will not get you anything beyond what svn is giving you. (Granted, I've only heard horror stories of Version Cue and haven't actually used it.)

Having worked on big Flash projects with svn before (big teams and big deployments), the best advice that I can give you is:

• Okay, your client is demanding all these FLAs, but why? You may have done this already, but try pushing back on their technical requirement a bit - what do they think they're gaining from this requirement?

• Designate ONE person to be the release manager for the Flash application. They will be responsible for checking out the proper code from svn, building it, and making sure it gets into the general application deployment. They will also be response for knowing which revision is in which environment (this can be easily automated).

• Put as little code and assets in the FLA as possible. You should be loading images and other assets from external sources and then attaching them to the appropriate MCs and Sprites.

• If at all possible, keep the teams in small discrete chunks. This decreases the chances of conflicting changes in the FLAs and increases the chances of everyone knowing what's going on.

• [More of a bandwidth note, less related to this question] Treat your FLAs like libraries or SDKs if at all possible. If their demand is close to "one sub-FLA per page" with a master FLA, then have additional sub-FLAs that hold the assets/widgets. That way your page FLAs are only holding page specific code, and you aren't reloading widgets each time you "switch pages". (Assumes no browser refreshing between page switches.)

It's probably worth noting that these are largely non-technical solutions. I have yet to find a "one shot kill" for the problem of working with binary files in revision control systems - especially binary files that are really source code. And that's really the clincher: the idea of storing source code in a proprietary binary format, to only be compiled into a different proprietary format, is bad voodoo.