If you’re not already using version control, you should start.
The biggest service it provides is keeping track of what you changed, and backing it up somewhere in a repository where all your documents and code can be backed up conveniently.
Once a project is under version control, you can typically right-click on it in the shell and find out everything that’s been done to it over time, even revert the whole project to historic versions, or pick out old versions of things.
In a team environment, it synchronizes work and shows who did what, when and to what files. It allows you to label ‘releases’ and branch off of them for ‘next version’ and ‘bug fixes’, and then allows you to integrate/merge the branches back into the main trunk of development.
I’ve used ClearCase, Perforce, SourceSafe, RCS, CVS and SVN and some various crappy old DOS things I don’t even remember the names of, all the way down to zipping versions, naming them with the date and dumping them into a directory.
Of all of them, SourceSafe is the utter worst. If you don’t mind having your repository damaged and corrupted on a routine basis by minor network errors and crashes, use SourceSafe and don’t complain that you weren’t told that it sucks. It sucks. Microsoft doesn’t use SourceSafe internally (they use one of those crappy old DOS things I mentioned). They maintain SourceSafe in order to sabotage the work of other software developers.
Perforce is ‘free’ for open source work, or for individual work, but you will PAY to use it per seat on a team. I’ve used that for a while on a couple of different projects, and at home. It’s nice, supports branching in a rational manner, and has atomic check-ins and other goodies, like MS Office plug-ins and plug-ins for various IDEs, if you’re into that. Of the commercial products, it’s the biggest bang for the buck.
http://www.perforce.com/
Currently, I use TortoiseSVN. It’s free. I was forced to change over from CVS (which I used on an earlier project) to SVN when SourceForge’s CVS service stopped working for a month. I really never liked WinCVS, but SVN is more or less exactly like it and I do like it. Go figure. For one thing, the ‘TortoiseSVN’ client doesn’t need an external SSL tool installed and configured, like WinCVS did. That’s a big win. For another, it handles binary assets a LOT better. Like CVS, it’s hosted on all manner of sites that will charge a nominal fee to host a commercial project (keeping it up 24/7 and backed up for the whole team), or host open source projects for free. It also has the atomic check-ins and branches a bit like Perforce does. If you’re thinking of using CVS, use SVN instead. CVS is at somewhat of a dead-end, and SVN has a bright future.
http://subversion.tigris.org/
http://svn1clicksetup.tigris.org/ (Windows local Server + TortoieseSVN all in one)
I find that over time, I have tended to use whatever I was last forced to use, and was too lazy to change from.
Flash is sort of hideous in certain ways when it comes to version control. The tendency is to throw all the code into Flash and forget it, letting that ‘undo’ buffer grow forever.
If you use version control, the first thing you’ll need to do is move your major ActionScript code and assets to its own directory structure. To do this…
-
Import/add the project to version control. The details vary, and there are instructions on the web relevant to doing this for all version control systems.
-
After it’s under version control, when you save your FLA file, use ‘Save and Compact’. This will strip the 20 weeks of readily corrupted and anonymous ‘undo’ state out of the file. The version control system will keep the ‘old’ versions for you, so why pile that up? You probably don’t want to do it the very first time you add your FLA file to version control (if you’ve been working on it for a while) because that’s your only project ‘history’ up to that point.
-
If you’re really ambitious, or working with a team or programmers, copy/paste your major ActionScrtipt code snippets to files, and replace that code in Flash with : #include “myfile.as”, where “myfile.as” is a descriptive file name for whatever the particular component of Flash is. It can have a path like #include “lib/myfile.as”. This will allow version control to track and diff the individual code changes AND it will allow you to edit your ActionScript code in a code editor that doesn’t make you want to strangle a kitten.
-
Break the Flash art and assets up into separate Flash files and import the data into the main project, rather than store it there. Once again, you can track changes to separate assets easier than a single ‘all in one file’ project, and collaborate more easily. You don’t need to go overboard with this; just put all the assets relating to one thing in one SWF, and all the assets related to another thing in another SWF, with a ‘main’ SWF to bind it all together.
-
Whenever you ‘finish’ something, or get something working, take a moment to check it into version control. It only takes a moment if you do it routinely. When you check in, PUT A COMMENT IN. Just type up a sentence or two that describes what you just did today. When searching/browsing history, it makes a world of difference.
-
Whenever you make a milestone of progress (milestones like demos, alpha, beta, release), LABEL your work. If you screw up and have to ‘go back’, you will find it again a lot easier. Even minor milestones like, “smooth - Got smooth turning working.” are helpful. If “smooth turning” ever breaks, you can go right back to that label and see how it originally worked before everybody added their ‘little touches’ to it.
-
Keep your design documents and concept art under version control, too. Even contracts. ABOVE ALL contracts and documents relating to them. You don’t want to see a fresh date on the only copy of a design document and then wonder whether there’s a new ‘requirement’ for a milestone payment that’s found its way in, and no way to show that it was added AFTER the deal was signed.
