PureCM uses a client-server architecture with a centralized server. To get started with PureCM you need to install the PureCM Server and the PureCM Client (on the same or different machines). Using a PureCM Client (GUI, command line, Visual Studio or Explorer) you then need to create a connection to the server. Each server will contain one or more repositories.
This is the place where all your data is stored. You can put multiple projects into a repository, allowing you to manage shared libraries easily. Note that the repository defines the context for the PureCM GUI, e.g. displaying all projects of your current repository in the Repository View.
Each developer creates a workspace on their computer for a selected version, feature or release. The workspace will mirror the files stored on the server. File additions, deletions and edits are then performed in the workspace before being submitted to the server in a changeset.
A project is a self-contained piece of work which includes a collection of files and folders. Examples of projects include: a software application, a website or documentation. A project is self-contained in the sense that it contains all the files it needs. Different projects can share files using components. Each project will have at least one version.
A version is a particular variation of the project which is being developed. For example, you might have version 1 and version 2 of an application. You need to create different versions if you work on the two versions at the same time (concurrently). Alternatively you can create different versions to help visualize your project’s progression.
A release is a snapshot of a version at a particular point in time. For example, you submit changes to the version and when the version is stable and tested you create a release which goes out to your customers.
A task is a small piece of work which involves changing files to a version of the project. As a rule of thumb a task should take no longer than half a day to complete. Otherwise you should create a feature and break the work down into smaller chunks which get created as tasks within the feature.
A feature is a large piece of work which can be broken down into smaller pieces of work (tasks). As a rule of thumb we recommend a feature is created for any piece of work which takes longer than half a day.
A project folder is a container for features and tasks to help organise related pieces of work.
A ‘time machine’ for a collection of files and folders. The stream contains all revisions of every file and folder so you can go ‘back in time’ and get the files for every changeset that is submitted. Each version and feature has a corresponding stream.
Changesets and Version Control
Change management allows version control of files and directories using a changeset-based approach. A 'changeset' is a related group of file additions, deletions and edits, defined by the developer and annotated with a description on submission to the server.
PureCM provides a tool allowing you to compare 2 versions of a file. Line differences are colour highlighted.
PureCM provides a tool allowing you to resolve 2 versions of a file which have a common base. Changes to different lines are automatically resolved but if the same line is changed in the 2 versions then the conflict must be resolved manually.
PureCM provides a tool allowing you to view all revisions of a file. When a changeset is submitted, a revision is created for each file. You can view each revision, compare 2 revisions with the Diff Tool or even rollback a revision.
Annotated File History
PureCM provides a tool allowing you to view the history of each line within a file. This is useful if you find a bug in a particular line and want to isolate the changeset in which the bug was submitted.
Checking the consistency of a workspace involves seeing if any files have been edited, added or deleted without being checked out. An inconsistent workspace is dangerous because you may submit a partial change.
Shelving is the ability to save unfinished work on the server as a shelveset. The changes can then be unshelved into a workspace. This is useful if you want to save work on the server or if you want to move a piece of work from one workspace to another.
A merge rule defines the merge history between 2 streams. Each merge rule specified the source stream and the destination stream. The merge rule keeps track of which changes have been merged and which changes need merging. You can setup the merge rule to try and automatically merge every change when it is submitted in the source stream. Alternatively you can setup the merge rule to notify you when a change has been submitted in the source stream.
Switching a Workspace
A workspace is based on a stream. You can switch a workspace to a different stream. Conceptually this is the same as deleting the old workspace and creating a new one. In practice this a lot quicker because the files which have not been changed do not need to be downloaded. This can also be preferable because the file modification times are not updated - so a rebuild is not necessary.
Components are a great way of managing shared code which is used in many projects. They allow a single copy of the library to be accessed in many placed in your repository but also allow the library to be updated from any of those locations. A component is made from a link between a two folders (usually in two different streams). Any files or folders inside the component folders are shared in the two places. Any changes to a file in one part of the component will be replicated exactly to all of the other parts.
Client/Server Architecture over TCP/IP
TCP/IP is used to allow the client components on the developers' computers to communicate with the central server component. As well as password authentication, support is included for strong authentication using Windows domain authentication or certificate authentication.
Before submitting files to the server the latest changes are downloaded to the client and can then be integrated with your changes. In this way the same files can be edited simultaneously by different developers, with conflicts being handled by the PureCM Resolve tool. In addition, concurrent development is supported with two sets of developers working on separate developments in separate streams which will be integrated at a later date.
Support for remote development is built-in and the PureCM client can be run even when a connection to the server is not available. For example a developer can checkout files, make local checkins, view a file's revisions, or view issue summaries while working 'offline'.