2. Source Control System Overview

Below you can see a brief SCS terminology explanation. Please refer to [4] for detailed explanation.

Team Development Terminology

Workspace is a private work area for an individual developer.
Repository is a persistent store that coordinates multi-user access to projects and team streams (branches).
A stream is a shared work area that lets team members release their work and use code updates from the others. A repository can contain multiple streams for different projects or different development stages.
Synchronizing. When you make changes in the work branch, resources are saved in the local workspace. You need to release resources in order for other team members to access them.
A repository can branch into multiple streams, which are distinguished by name. When the same project appears in different streams, the resources evolve independently. Changes released in one stream have no effect on other streams until they are merged.
A version of a file resource captures the content of the file. A version of a project captures the configuration of folders and files as well as their specific versions.
Check in (or commit) is an operation of sending changed workspace to the repository.
Check out is an operation ofdownloading content from a repository to a local folder.

As long as Sitecore does not utilize special features of a particular SCS system, the decision which SCS system to choose is up to you and your team. In the present article we will describe a Source Control System setup by the example of Subversion.

2.1. Subversion VCS Feature Overview

In this section we give a brief overview of Subversion VCS. Please refer to the Subversion home site for more detailed documentation:

http://subversion.tigris.org/

Directory versioning

Subversion implements a virtual versioned file system that tracks changes to whole directory trees over time. Files and directories are versioned.

True version history

With Subversion, you can add, delete, copy, and rename both files and directories. Every newly added file begins with a clean history.

Atomic commits

No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file; log messages are attached to the revision and are not stored redundantly. This allows developers to construct and commit changes as logical chunks, and prevents problems that may occur when only a portion of a set of changes is successfully sent to the repository.

Versioned metadata

Each file, as well as each directory, has a set of properties associated with it; for example, keys and their values. You can create and store any arbitrary key/value pairs you wish. Properties are versioned over time, just like file contents.

Choice of network layers

Subversion has an abstract notion of repository access, making it easy to implement new network mechanisms.

Consistent data handling

Subversion is equally efficient on binary and text files, because it uses a binary diffing algorithm to transmit and store successive revisions.

Efficient branching and tagging

There is no reason for these operations to be expensive, so they aren't.

Subversion creates branches and tags by simply copying the project, using a mechanism similar to a hard-link. Thus these operations regularly take up small amount of time.

Hackability

Subversion has no historical baggage; it is implemented as a collection of shared C libraries with well-defined APIs. This makes Subversion extremely maintainable and usable by other applications and languages.

2.2. Known Issues

Subversion will not overwrite existing files/folders when performing a check-out. This means that you will not be able to seamlessly check-out a project into an existing Sitecore installation - subversion will throw an error saying that some of the files already exist. As a workaround, you may checkout a project into a separate folder and then copy the contents manually to the solution root. Subversion might also have “—force” option available in future.
If you use web VS.NET projects, then Visual Studio will not be able to refresh a solution because of the hidden '.svn' folders. There are several workarounds for this problem; one of them is using the modified version of TortoiseSVN client that works with '_svn' folders instead of '.svn'. That might not be a problem though, since the majority of Sitecore V5 projects are class libraries and not web projects.

Prev Next