Using Subversion with Dreamweaver CS5 – Part 1: Introducing Subversion

In 2008, with the release of Dreamweaver CS4, Adobe introduced support for the Subversion version control system (VCS). With the release of Dreamweaver CS5, the company continues to provide web designers and developers all of the benefits afforded by a VCS that have long been recognized and enjoyed by more traditional code developers but with updated support of the Subversion 1.6.6 client libraries and the addition of several new features, including easier ways to commit and revert files in the VCS repository.

The goal of Adobe in supporting this feature is to improve the workday of Dreamweaver users. No longer do designers/developers have to use one graphical user interface (GUI) for web development and another separate GUI to manage their VCSs. This integration greatly improves the designer/developer workflow.

Note: The Dreamweaver CS5 integration with Subversion is not intended as a full-featured Subversion client. Although Dreamweaver CS5 does not offer all of the advanced features that are available in other Subversion clients, it does give Dreamweaver users the ability to integrate Subversion into their daily workflows.

This is Part 1 of a three-part article series in which I will explain why designers/developers will find Subversion useful and how they might integrate VCS use into their current workflows. To get you started, I will focus on some basic VCS concepts as well as the reasons for using such a tool. Later I will cover how to integrate Subversion into your workflow. In Part 2, I show you how to configure Dreamweaver CS5 to use a Subversion repository, and in Part 3, I explain how to create your own repository.

If you are already familiar with VCS concepts, you may want to proceed to Part 2: Configuring Dreamweaver CS5 to use Subversion.

Subversion (SVN) is one of several commercial and open source version control systems (VCSs) currently available. It has seen significant adoption since its initial release and provides many features that are considered essential to a good VCS. Subversion software runs on a server that provides a repository where a developer can store critical data such as source code and configuration files. Unlike a standard file system, the VCS keeps track of changes made to each file, enabling users to track changes and return to previous versions of any file. It also allows multiple developers to interact in a more complex development process by using branching, merging, and tagging.

Subversion was initiated by the CollabNet development team, who continue to support it together with the open source community. It has been released to the general public for use under the Apache License. The software and its source are freely available at the Subversion website for download and installation. It also comes pre-installed on many platforms including Mac OS X 10.6 and a number of Linux variants. As a Dreamweaver CS5 user you do not need to download or install the Subversion client itself, because Dreamweaver CS5 acts as a client to a Subversion repository.

Subversion is not the only VCS available in the public domain. Other classic open source systems include Revision Control System (RCS) and Concurrent Versions System (CVS). Those interested in commercial applications can review products such as Perforce and Microsoft Visual SourceSafe. At the time of writing, Subversion is the only VCS supported by Dreamweaver CS5.

Whether you work as a member of a web design/development team or as an individual web designer/developer, you may want to consider a VCS for several reasons. I have experience using VCS in both types of environments and I have found the benefits far outweigh the additional effort required to integrate Subversion into your workflow.

Note: Dreamweaver CS5 and Subversion use different terminology for VCS concepts. For the remainder of this article I will use the terminology used by Adobe in Dreamweaver CS5 followed by the corresponding Subversion term in parentheses.

As a team-based designer/developer, your organization may require you to check out (checkout) and check in (commit) your code (such as HTML, CSS, JavaScript) from and to an existing Subversion repository. This allows the entire development group to work on a single project and code base. With Subversion there are methods for dealing with conflicts and accidental changes. You can also create a standardized release process using snapshots (tags) of a collection of different files at a given point in time.

As an individual designer/developer you can use your own Subversion repository to keep track of changes to your code so that when you want to return to a previous version, the system will allow you to undo (revert) your changes. I use Subversion extensively in this fashion when developing HTML for websites as well as scripts and other code. I can't even begin to count the number of times I have wanted to see a particular revision of my code. In each case, Subversion allowed me to get to it quickly and identify the differences between that earlier version and the current version.

The repository

The repository is the central store of data where all of the files that are managed under version control are kept. A repository is typically kept on a central server but can also be created on a local system. To a Subversion client (including Dreamweaver CS5) the repository resembles a standard directory structure much like the local files system on your machine. Although the client sees the repository as a directory structure, to the server the repository is a sophisticated system for keeping track of files and changes to those files. Multiple users can access the repository at the same time, making Subversion ideal for team-based development.

Dreamweaver CS5 users access the repository using a repository path and connection method typically provided by their repository administrator.

Check out (checkout) and check in (commit)

When using Subversion (or any VCS) there are three basic development activities: check out one or more files, make changes to any of the files, and then check the files back into the repository. The goal of the system is to keep track of each change made to the file and watch for conflicts between developers. If at any point in time your local copy of the repository and the remote version get out of sync, the repository directory structure can be re-synchronized by performing an update.

If two different designers/developers make changes to the same file, the submitter will be alerted to the conflicts and he or she can then contact the other party to resolve the conflicts and determine whose changes will take precedence.

Compare (diff) and undo (revert)

Using Subversion to manage development projects has many benefits, but two advantages stand out. The first is the ability to compare current files to past files to see what the differences are and identify the changes that have been made. This process, sometimes called diffing the files, allows you to see what changes occurred between two different submissions of a file to the Subversion repository.

The second major advantage to using Subversion is the ability to revert to a previous version of a given file. Consider a situation in which someone made changes to a web page or CSS file that have rendered the website unusable. Without a VCS the developer would either have to rely on reproducing the old file by hand or look for a backup. With Subversion you can easily revert to a previous version of the changed file. The ability to go back to a snapshot of a previous point in time is much like the new Time Machine feature in Mac OS X 10.6.x.

Trunks, branches, and tags

If you are working as part of a larger development team, there will likely be a Subversion administrator managing the directory structure within the repository. This directory structure varies depending on how each individual firm approaches development workflow. Understanding trunks, branches, and tags will help you communicate effectively with your teammates when discussing Subversion.

• Trunks: The main part of a project in a repository is called the trunk. This is where the bulk of the code is managed and where the mainline development of the site is kept. If the repository has multiple websites under management each one may have its own trunk.
• Branches: A branch is commonly created when a developer or small team wants to work on their own version-controlled "copy" of the mainline trunk. Typically work is done in the branch for a limited period of time and then merged back into the main trunk when the derivative project is complete. Some branches may not be merged back into the main trunk if that project is to remain a derivative.
• Tags: You are likely familiar with the different version numbering systems of commercial and open source software. Apple uses the xx.x.x format to number their releases (for example, 10.6.3). Microsoft uses a different approach with a main product name followed by build numbers (for example, Windows XP, Version 5.1 Build 2600.xpsp.080413-2111). Both of these numbering systems are related to tags in a VCS. A tag is a snapshot in time of one or more files in the VCS repository. Think of it as making a full copy of a web content folder and then labeling it with a version number (for example, WebSite_1.0). Most organizations have a build system that tags a collection of files for a release to either staging (beta) or production (final release). At one firm where I worked I was responsible for developing custom push scripts that tagged the web content in the repository and then synchronized all of the tagged code from the build server to all of the different web servers behind our load balancing system.

Individual developers may never need to create a branch outside of a single main trunk, but some do use tags. If you are planning to use tags, see the Where to go from here section at the end of this article for additional Subversion resources.

Web design and development workflow varies quite a bit from organization to organization. This variation makes it hard to define a single standard for using a VCS in your workflow. I have worked for several companies that did both web development and more traditional software development, and each had their own method for integrating a VCS into their workflow. There were, however, some similarities that can be used to guide a move from a non–VCS-based workflow to one which uses Subversion. The method outlined here is by no means the sole best practice or the only option, but I think it is a good starting point.

Most Dreamweaver users are set up with a local copy of their websites and a remote server used for hosting the content developed by the design team. The remote server may be either a staging or development system or it could be the actual production server in the case of smaller teams. Larger firms tend to use a development server for testing and doing trials of code and content. They will typically have one individual responsible for pushing code to the production website.

A typical workflow of an individual developer or one working in a small team is to make edits to the local copy of their sites and then push those edits at various times, either at the end of a task or at the end of the day. The developer may periodically download the whole site to make sure he/she has the same content as the rest of the team, but this happens relatively infrequently as changes rarely overlap. This approach can be prone to problems if there are differences between local content and remote content or if different developers make changes to the same file.

In larger teams the workflow tends to be slightly different, because there is a bigger chance that changes made by different developers will conflict and cause potential problems with the website. In this environment, the process for an individual designer might be as follows:

1. Arrive in the office in the morning, grab a cup of coffee, and check e-mail.
2. Download the latest copy of a site from the staging server to the local system using Dreamweaver.
3. Make appropriate changes to various local files that need updating or add new files for site expansion.
4. Upload those changes back to the staging server.
5. Test changes to make sure everything works.

Once the site is ready to go to production the designer or design team will ask the person responsible for releases to push the site to production and at that point it will become live for customers to access.

Using Subversion as part of your workflow will greatly improve the management of changes and provide many of the other benefits mentioned earlier in this article. I propose the following workflow:

1. Individual developers will arrive each morning and review a list of tasks related to site development. These could be enhancements or bug fixes to existing content. Many firms employ a feature or bug tracking system, such as Bugzilla, to keep track of these tasks.
2. The developers then update their local copies of files from the Subversion server by performing a check-out. This ensures they have all the current copies and changes that may have been checked in by other developers since their last updates.
3. Changes and additions can then be made to the files. To test these changes the developer can upload the content to the staging server.
4. Once the changes are tested on the staging server the developer can check in (commit) the files back to the repository. They are now available to other developers to check out. If there is a conflict on the check-in then the developer can contact the other team member to discuss the issues and decide how to resolve them. To aid in this the developer can compare the repository copy to their current working copy of the file using a diff tool.
5. On a periodic basis (either scheduled or when a development milestone is reached) a build developer will update his or her local copy of the site from the repository and push that version to production. Most firms will use advanced Subversion features such as tags to aid in this process.

This process should help your team to get Subversion integrated into your workflow. The process may become more sophisticated over time but this is a good starting point to get you started with using a VCS.

Where to go from here

To continue learning how to use Subversion with Dreamweaver CS5, go to Part 2 of this article series, Configuring Dreamweaver CS5 to use Subversion.

For more information on Subversion and version control, check out the following resources:

• The Subversion site
• The Subversion book
• Version Control with Subversion
• Subversion Version Control
• Practical Subversion