Source Control Concepts

From BriansWiki

Contents 1 Source Control - What is it? 1.1 * CFUGCNY Presentation slides 2 Source Control - Why should I use it? 3 What kinds of Source Control are there? 4 How can I use it in my development practice? 5 Glossary 5.1 Baseline 5.2 Branch 5.3 Change 5.4 Change list 5.5 Checkout 5.6 Export 5.7 Head 5.8 Import 5.9 Mainline 5.10 Merge 5.11 Repository 5.12 Resolve 5.13 Reverse integration 5.14 Revision 5.15 Tag 5.16 Trunk 5.17 Update 5.18 Working copy

[edit] Source Control - What is it?

[edit] * CFUGCNY Presentation slides

Source Control had its start in Engineering companies as a way to control the different versions of drawings. Software shops quickly adopted it and was popularized by the open source CVS and the proprietary Visual Source Safe appplications. All source control systems share the common features of a server based central repository and a local repository on the developers system

• Source Repository
  • The server based file storage system

• Local repository
  • Working Copy on the developers system

[edit] Source Control - Why should I use it?

Source Control is most useful in environments where there are multiple versions of software running similateously, this is common if you have production, staging and developement servers all running different versions of the same software.

• Multiple versions running simultaneously

Lets you revert to an explicit version of a project, for web development this is primarily used for dev, staging and production servers.

• Team Development

Source control allows the exact and current version of the software to be available to all members of the team.

• Accountability/Transparency

"Dif" tools allow for a quick way to evaluate changes to code

[edit] What kinds of Source Control are there?

There are strong feelings about the different types of versioning systems, I have been in companies where the use of Concurrent versioning was vehemently opposed. Ultimately I think the advantages of having multiple developers work on the same project simultaneously are greater than the hassle of merging files.

• File Locking

Only one developer can work on a file at a given time Issues; files left locked for too long, forgetting to checkin blocks other developers, no oversight till check-in. Encourages by passing the lock and leads to a synchronization mess.

• Version Merging

Concurrent Access - Multiple developers can work on the same file simultaneously, any conflicts have to be merged.

[edit] How can I use it in my development practice?

This is obviously a personal or work style preference but there are some basic models of working that have been effective for me and my co-workers:

• Projects have three branches: Dev, Staging and Production.
  • All Projects are local (on your harddrive) and checked-out from Source control at the beginning of a project, or every day if you are collaborating in a team.

• Compare the different versions
  • Merge as needed
• Check in code when you reach milestones
  • Dev code should be checked in regularly and should work.

• When Dev code reaches a deployment target, it branches to the Staging line of Source Control.
  • Always Compare when pushing to another server
• After Staging passes all QC, it moves to the Production line and all changes from Staging are merged back into Dev.

[edit] Glossary

Terminology can vary from system to system, but here are some terms in common usage.

[edit] Baseline

An approved revision of a document or source file from which subsequent changes can be made. See the discussion of baselines, labels, and tags.

[edit] Branch

A set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may be developed at different speeds or in different ways independently of the other.

[edit] Change

A change (or diff, or delta) represents a specific modification to a document under version control. The granularity of the modification considered a change varies between version control systems.

[edit] Change list

On many version control systems with atomic multi-change commits, a changelist, change set, or patch identifies the set of changes made in a single commit. This can also represent a sequential view of the source code, allowing source to be examined as of any particular changelist ID.

[edit] Checkout

A check-out (or checkout or co) creates a local working copy from the repository. Either a specific revision is specified, or the latest is obtained. Commit A commit (checkin, ci or, more rarely, install, submit or record) occurs when a copy of the changes made to the working copy is written or merged into the repository. Conflict A conflict occurs when two changes are made by different parties to the same document, and the system is unable to reconcile the changes. A user must resolve the conflict by combining the changes, or by selecting one change in favour of the other. Dynamic stream A stream (a data structure that implements a configuration of the elements in a particular repository) whose configuration changes over time, with new versions promoted from child workspaces and/or from other dynamic streams. It also inherits versions from its parent stream.

[edit] Export

An export is similar to a check-out except that it creates a clean directory tree without the version control metadata used in a working copy. Often used prior to publishing the contents.

[edit] Head

The most recent commit.

[edit] Import

An import is the action of copying a local directory tree (that is not currently a working copy) into the repository for the first time. Label See tag.

[edit] Mainline

Similar to Trunk, but there can be a Mainline for each branch.

[edit] Merge

A merge or integration brings together two sets of changes to a file or set of files into a unified revision of that file or files.

• This may happen when one user, working on those files, updates their working copy with changes made, and checked into the repository, by other users. Conversely, this same process may happen in the repository when a user tries to check-in their changes.
• It may happen after a set of files has been branched, then a problem that existed before the branching is fixed in one branch and this fix needs merging into the other.
• It may happen after files have been branched, developed independently for a while and then are required to be merged back into a single unified trunk.

[edit] Repository

The repository is where the current and historical file data is stored, often on a server. Sometimes also called a depot (e.g. with SVK, AccuRev and Perforce).

[edit] Resolve

The act of user intervention to address a conflict between different changes to the same document.

[edit] Reverse integration

The process of merging different team branches into the main trunk of the versioning system.

[edit] Revision

Also version: A version is any change in form. In SVK, a Revision is the state at a point in time of the entire tree in the repository.

[edit] Tag

A tag or label refers to an important snapshot in time, consistent across many files. These files at that point may all be tagged with a user-friendly, meaningful name or revision number. See the discussion of baselines, labels, and tags.

[edit] Trunk

The unique line of development that is not a branch (sometimes also called Baseline or Mainline)

[edit] Update

An update (or sync) merges changes that have been made in the repository (e.g. by other people) into the local working copy.

[edit] Working copy

The working copy is the local copy of files from a repository, at a specific time or revision. All work done to the files in a repository is initially done on a working copy, hence the name. Conceptually, it is a sandbox.

NOTE: This Glossary is from the excellent article on Wikipedia.