Projects and Version Control Guidelines
Projects and Version Control Guidelines
Projects in Flash introduce a way for members on a team to work together on a single Flash application or project. A project file remembers each of the files it contains, and lets you incorporate some SourceSafe capabilities into your applications, which helps you keep backups of modified files.
Note: Flash Professional 8 (and earlier) does not support SourceSafe for version control on the Macintosh.
You can group multiple files into a single project file using the Project panel in Flash Professional 8. This helps simplify application building, where managing related files could get complex and confusing. You can define a site for your work, create a Flash Project file (FLP), and then upload everything to the server so that a team can work on the project.
Version control lets you check files in and out of your repository, and check that only one person is working on a file at a certain time. Other benefits include the ability to revert to older versions of the files, so if your FLA file becomes corrupted or spontaneously stops working, you can revert to an older (working) version.
Version control features help you ensure that you use the correct current files when authoring, and that certain files are not overwritten. When multiple authors work on the same project, you can check that only one person has the file checked out and, during that time, another person cannot overwrite the file.
You can typically use your current source control software with Flash, but you might not be able to integrate it with the Project panel. Microsoft Visual SourceSafe is currently supported. Other software programs can manage and control your Flash documents, but you probably cannot integrate them with the Project panel.
There are certain ways that you can organize your project’s workflow. The following sections describe the best practices to follow when working with Flash projects and version control.
Assign an administrator to the project. This individual is responsible for creating and maintaining the project’s structure. For example, documents are split up logically using folders to combine similar files. Typically, several authors work on one Flash project. The administrator confirms changes that are made to the project’s structure, which encourages project stability.
Caution: The administrator is the only person who changes the project file and structure.
The project’s administrator defines the site, and creates the Flash Project (FLP), main FLA document, and any subdirectories for the project’s assets. These directories might include media, images, or classes that dynamically load into the project. The administrator uploads everything to the server. The administrator also creates a clear structure for the project, and communicates how it works and where to add additional assets (such as class and image files) to everyone who is working on the application.
Authors on a Flash project do not change the project root, directory structure of the project, or the site. This includes adding, removing, or changing subdirectory names, or adding additional subdirectories to the project on their local computer. If individual authors change the site or project structure, the local files are out of sync with those on the server. This causes problems in the application, such as class path and missing file errors, and so on. Individual authors can copy assets to the subdirectory files that the project’s administrator creates.
Each author on a Flash project selects File > Open from Site, selects the name of the site, and then selects the project’s FLP file. Then the author updates the project with any missing files. This ensures that the author is working with the latest version of the site. When the author selects Yes, all the project files download to the author’s local computer, so the structure on the local computer matches the structure on the server.
When the project’s structure needs to be changed, authors check in all their files. The project’s administrator checks out all the files to make any necessary changes. After this is done, each person working on the project deletes the root folder of their own local copy of the project. Each individual author should use File > Open from Site to download a new copy of the site. This helps reduce errors when working with the project from accidentally using legacy files, and reduces similar versioning problems.