|
|
|
Productions
Syntactical Notes
Definition of Productions
Detailed Simple Example
The Mechanics Behind Creating a Version of a Production
The Tip Revision
Advanced Usage (Controlling External Libraries)
Syntactical Notes
The syntax used throughout Evolution, documentation, and this site is that versions are designated by [vX] where X is a version number. When referring to file string.cpp version 7, you will often see it referred to as string.cpp [v7].
Definition of Productions
A Production is defined as a revision-tracked logical grouping whose versions link to specific versions of files and/or other Productions.
Productions can be thought of as folders that retain a version history. In contrast to file systems which offer directories whose states are stored (therefore making it possible to conduct a search based on a timestamp and see what the directory looked like at a point in time), versions of a Production are created for an explicit purpose.
Detailed Simple Example
Because Productions are created for a specific purpose, the user gains an additional level of control over what can be accomplished. As a trivial example, a team member is developing a small widget utility made up of several files in a single project, all contained in a single folder called "Widget".
Importing this folder into Evolution, the system creates a Production also called "Widget" and adds the files in the folder to the Production.
At this point, the Production called "Widget" exists, but there are no versions for it yet. Files or other Productions can be added or removed from "Widget". Files can be checked out and into "Widget" and Evolution behaves similarly to traditional source control. Let's assume changes are made to various files in "Widget".
Because a set of changes have been made and the code is compilable, this is a good point to save away the state of the "Widget" Production using Evolution's Version Manager. The act of versioning the Production in this case is simply to open the Production for editing and then to commit the changes.
After committing the changes, "Widget" now has a version history viewable from the main application.
Subsequent changes are made and a version 2 of the "Widget" Production is made to store the new state of the code.
After some testing and usage, it is discovered that a bug was introduced causing the application to crash. So, we need to find out what changed between the last known good build ("Widget" version 1) and the discovery of the bug.
The screenshot above shows that CwidgetEngine.cpp and CwidgetGUI.cpp have both changed since "Widget" [v1]. A diff can be performed directly from the Version Manager on the actual files to determine the cause of the bug.
This is a simple application of the Production system.
The Mechanics Behind Creating a Version of a Production
A Production must be locked for editing. This is analogous to file checkouts. To edit the data in a file, a user must own a lock on the file. In the context of Productions, to "edit" means to manipulate the items and versions to be referenced in the version of the Production in question.
However, for a file, there is a local copy stored on the user's drive that is edited and then checked back into the source control system. For Productions, there is no local copy. Any operations to add, remove or change the version of items in the Production are executed immediately on the server. But these changes are not committed to the system until the user explicitly does so. The user can choose to discard any changes that were made. The non-committed version is simply deleted by the server, returning the system state to normal.
If the user commits the changes to the Production version, the new version is then permanently created by the server.
The Tip Revision
Another difference between files and Productions is the concept of a "Tip" revision. When a file is first created in the source-controlled system, the data in the file is [v1]. When it is checked out and checked in again, [v2] is created, and so on incrementally.
On the other hand, when a Production is created, there is no [v1] that is created automatically. The Production does exist in the system, but there is no historical copy of it because Production versions are not created until a user explicitly does so. What you see in the Production Explorer is the Tip revision (or [v0]).
Tip revisions are fluid and constantly changing. Changes are not recorded. Production tips can be viewed as the real world- what developers are actually working with. And Production versions are snapshots in time, saved for historical purposes (primarily for builds).
When a Production version is created, it is usually created based on the Tip (what appears in the Production Explorer). But versions can be created based on any other version as well. The version to act as the new version's basis is specified by the user upon opening a Production for editing.
Advanced Usage
Using Productions introduces an entirely new dimension of control. Team A within an organization that develops an internal library can create versions and release only what has been tested and passed quality assurance measures to the rest of the company. If Team B does not want to use newer releases of Team A's library, they can simply still include an older version of it and not be affected by any changes at all until they are ready to upgrade.
Another example is using an external API, such as Microsoft's Platform SDK. Wrap the entire PSDK in a Production and whenever Microsoft releases a new version, update the files and version the PSDK Production. Now teams can decide to use the PSDK and make any fixes required due to the changes, or simply stay with the older version until their schedule allows an update.
Productions provide sharing similar to shared projects in other source control solutions, at zero cost. Beyond simple sharing are reflections, a unidirectional relationship.
|
|
 |
People are talking...
"Evolution has already made quite an impact on timescales, with a great reduction in accidental overwrites and deletions from previous projects."
Mark Docherty
Lead Developer
d2 Digital
Read what Nick Ni, ionForge's Director of Technology, has to say in
Software Test & Performance MagazineBuild Management
Best Practices
|
|
