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.
I’ve struggled with this myself, and I can’t tell you anything other than:
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.