OurayCM is based on some very simple concepts (they do not in every case match commonly-held concepts). This article gives an overview of those concepts. For a fuller examination of the basis of these concepts, see 10 Qualities You Need in an SCM System.
The information here overlaps to some extent that provided in the OurayCM User Manual.
The core concepts we will cover are:
In OurayCM, the user's workspace is King. It is the starting point from which all SCM data comes, and is the standard by which OurayCM's concepts and algorithms are designed. That is why we say that OurayCM is Workspace-Centric. As will become clear, this approach is markedly different from many existing SCM tools.
The workspace is simply the area on your disk that holds the files you are working on. OurayCM assumes that your source, which can be in various forms including HTML and text documents, is organized hierarchically under a given directory. (A strewn model, where files are spread around the computer is possible, and will be supported in a future release of OurayCM.)
Every element of the workspace, whether it be a file, directory, symbolic link or other type, is generically referred to as an entry in OurayCM.
A typical workspace contains some files you want to include in your SCM repository (repo), and some you want to ignore. For example, you probably should not include compiled object files or editor backup files in your SCM repo. OurayCM provides a method for ignoring files by pattern or individually; see the OurayCM User Manual for further details.
A version is an efficiently-stored copy of the workspace as it was at a given point. This is the fundamental unit stored in the OurayCM database. These Durable Versions give you the means of recovering the state of your workspace as it existed at any point in the past, in a fine-grained way. They are stored in the repo as a difference from the previous version, so they do not take much space. (Binary files are not stored as a difference).
Because it is workspace-centric, OurayCM does not version individual files. That is because the unit of work that's important to programmers is not merely their individual files, but the file relationships and how they form a working system. The basic version creation command, 'ocm save', efficiently stores the single integrated workspace in a recoverable form.
Most SCM tools store file versions in their database. To get the behavior that comes naturally with OurayCM, these tools force you to run a potentially costly tagging operation to create an integrated workspace unit (and you have to keep track of these tags). But the fact is: when recovering old versions, one isn't normally interested in a mere file; one needs to recreate the workspace as it was at a given point. It is mostly beside the point to merely store sets of file versions.
The ACID database model (Atomicity, Consistency, Isolation, and Durability) is a different way of looking at the same issue. OurayCM implements the ACID database model as it applies to your workspace as a whole. (Some tools may implement ACID as it applies to your files, but not to your workspace as a whole).
A future article will explain how the ACID model applies to OurayCM versions in detail.
Different SCM systems use the term 'branch' in different ways. When trying to understand OurayCM branches, it is important to not strongly associate, say, VSS, or CVS branches, with OurayCM branches. They are similar in an abstract sense, but differ radically in details. (Some tools invent new terminology to help distinguish their concept of 'branch' from that of others; we think that practice is unnecessary and potentially confusing.)
In OurayCM, a branch is a sequential set of Durable Versions that provides a systematic means of transferring changes between other branches for the purposes of parallel development. OurayCM branches are powerful and easy to use: With OurayCM branches, there is no need for you to manually keep track of tags to figure out what has been merged where. Nor do you need to do special bookkeeping with tags to make sure that you can recover the state of a given branch--if a branch had a given state in the past, you can always get back to it. OurayCM eliminates the tedium, complexity, and risk typically associated with branching.
It is important to recognize both the similarities OurayCM branching has with common notions of branching, and the radical difference introduced by applying the ACID properties to the workspace. What is similar is the idea that branches allow parallel changes to be dealt with systematically. What is different is that the branch stores every past state it ever had. This makes your saved workspace Durable, i.e., recoverable at any future point in time.
An OurayCM branch is graphically depicted like this:
The rectangle with the overlapping circle and horizontal line represents the branch and first version implied by it (version 0). The branch is named "eric". The circles represent versions, i.e., the durable form of your workspace at given points in time (imagine a file hierarchy associated with each one). The numbers above each version are for clarity. The above sequence could have been created by successive 'ocm save' commands applied to Eric's workspace.
This diagram illustrates one aspect of branches--that they are a sequential set of Durable Versions. The following diagram illustrates the other crucial property, that branches facilitate the flow of changes:
This particular example shows two individuals working as a team. The individual branches exist to allow each person to have private SCM. They embody the evolution of the individual's workspace toward his individual goals. The branch in the middle is called a "shared" or "parent" branch. It embodies the evolution of the project as a whole toward the team's goals. (More complex, hierarchical branching structures are possible and useful; for example, see How to Design Branches.)
In this example, which would be typical for a small team, only 4 OurayCM commands are needed:
As you can see in the diagram, Eric can save versions on his branch as he needs using 'ocm save', giving him a means of recovering his workspace at any point in the past. When he reaches a point where he wants to share his work with the rest of the team, he submits them using 'ocm submit'. Likewise, Martin has his own private area and can recover any past versions, and when he desires, can get an update using 'ocm update'.
These 3 commands ('ocm save', 'ocm submit', and 'ocm update') fill most of the day-to-day SCM needs of the team. Another command, pull, is more rarely needed, but is required in some situations.
For example, suppose you have a team of 10, using simple one-level hierarchy as shown above (except with 10 private branches instead of 2). Then 2 of these 10, let's say Bob and Jim, get handed a task to work on together for a few days. They need to share work with each other, but they don't want their sharing to effect the rest of the team. The command 'ocm pull' allows Bob to pull any change from Jim's branch to his own, or vice-versa. This is a powerful feature you won't see in a lot of tools.
Again, OurayCM properly keeps track of all change flow; there's no possibility of a "double-merge". If Bob submits to the team's shared branch, and then Jim (who has pulled some of Bob's changes into his area) submits to the shared branch, only the new changes Jim made are incorporated; OurayCM already knows that Bob's have been incorporated. OurayCM does the bookkeeping for you.
For instance, if you run 'ocm update' twice in a row, it will say, for example: "Branch /eric is already up to date with /:3" (i.e., Eric's branch is already up to date with version 3 on the main branch) and refuse to do anything.
The bottom line: With OurayCM, you get powerful branching features, but OurayCM won't let you shoot yourself in the foot.
Because versions in OurayCM are durable, and because you can branch from any version, release management in OurayCM is very easy (at least from an SCM point of view). Basically, all you do is attach a convenient name to a given version, creating a "vref". If you need to patch the release in any way, you can simply branch from the release version.
The following shows the vref viewer on the OurayCM browser. Note the release names, such as "0.17", and that they point to specific versions, such as version 29 on branch /8 (/8:29). (We use the branch number instead of the branch name since branches can be renamed but not renumbered. See the OurayCM User Manual for details.)
This article gives a "bird's-eye" view of OurayCM, and it should be enough to get you started in thinking about how to apply it to your projects. Check out our other articles for additional information on how to use the tool, and of course, see the OurayCM User Manual.
If you have any feedback on this article, feel free to email the author.