Basic VCS concepts

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 CS4 and Subversion use different terminology for VCS concepts. For the remainder of this article I will use the terminology used by Adobe in Dreamweaver CS4 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 CS4) 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 CS4 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.5.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.5.4). 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.

Page 3 of 4

Previous Page

Next Page