This section introduces the basic AccuRev concepts and procedures that will enable you to be comfortable and productive using AccuRev on day one.
AccuRev’s flexibility makes it easy to use for a variety of development scenarios. But like every software system, it has usage models that were foremost in the minds of its architects. This section describes the most common usage model.
AccuRev is a software configuration management (SCM) system, designed for use by a team of people who are developing a set of files. This set of files might contain source code, images, technical and marketing documents, audio/video tracks, or any other digital content the user puts into the system. The files and directories in AccuRev are said to be "version-controlled" or "under source control".
For maximum productivity, the team’s members must be able to work independently of each other, sometimes for just a few hours or days, other times for many weeks. Accordingly, each user has his own private copy of the version-controlled files. The private copies are stored on the user’s own machine (or perhaps in the user’s private area on a public machine), in a directory tree called a workspace. We can picture the independent workspaces for a three-user team comprised of John, Mary, and Derek as follows:
This set of users’ workspaces uses the convention of having like names, suffixed with the individual usernames. AccuRev GUI enforces this username-suffix convention. In this example, talon_dvt might mean "development work on the Talon product"; john, mary, and derek would be the users’ login names.
From AccuRev GUI’s perspective, development work in this set of workspaces is a continual back-and-forth between getting "in sync" and "out of sync":
- Initially, the workspaces are completely synchronized: each workspace has copies of the same set of version-controlled files.
- The workspaces become unsynchronized as each user makes changes to some of the files.
- Periodically, users share their changes with each other. When john incorporates some or all of mary’s changes into his workspace, their two workspaces become more closely (perhaps completely) synchronized.
You might assume that the workspace synchronization process involves the direct transfer of data from one workspace to another. But this is not the way AccuRev GUI organizes the work environment. Instead of transferring data directly between private areas (that is, between users’ workspaces), AccuRev GUI organizes the data transfer into two steps:
- One user makes his changes public, available to all the other members of his team. This step is called promoting.
- Whenever they wish, other team members incorporate the public changes into their own workspaces. This step is called updating.
The first step involves a public data area, called a stream. A stream is an AccuRev GUI structure with two very important features that support and simplify parallel development. First, as implied by the preceding illustration, numerous individual contributors can create workspaces on a single stream, allowing them to easily share their work with others, and to get changes from them when they wish. As you will see later, AccuRev GUI has numerous safeguards that prevent one user from overwriting another user's changes, and tools that help you resolve conflicting changes when they occur. Second, in a stream hierarchy, inheritance lets child streams automatically inherit changes from the parent streams above them, reducing the need for tedious merges that might otherwise be required when several developers are working on the same code.
AccuRev GUI has several kinds of streams, but the most common one is the backing stream. Later, we will show you how the data in this public stream "is in back of" or "provides a backstop for" all the private workspaces of the team members.
With the usage model described above, you will be able to accomplish most of your work with four simple commands: Keep, Promote, Update, and Merge. These commands are described in the following sections.