TFS Concepts

Workspaces
A workspace can be thought of as the container that bridges the gap between your local
computer and the Team Foundation Server repository.
Workspaces are identified by a name and the hostname of the computer the workspace is for.
The name can be up to 64 characters in length, and you can also provide a comment that may
be a useful reminder if you have multiple workspaces on the same computer. The workspace
also contains the working folder mappings that indicate which folders on your local machine
map to which folders on the server.
The workspace contains several important pieces of information: Attributes (name, owner,
computer, comment, location, file time, permissions), working folder mappings and versions.
Name and computer are just data associated with the Windows Security ID. Under the hood,
Team Foundation Server actually stored the Windows security identifier (SID) of the account.
The update call simply tells the server to update its cache with the current username for that
same SID.
The version control system needs to store information in the workspace, such as which
version of which files you have downloaded locally, which files you are in the process of
editing, etc. In Team Foundation Server 2012, the workspace state information can be stored
in either of two locations, locally on disk or on the server. This leads to the terms Local
Workspaces and Server Workspaces.
In a Local Workspace, state about that workspace is stored on the local disk. All the
information is stored inside a folder called $tf (or .tf on Unix-based file systems). The folder
resides at the root of your workspace folder mappings. If there is no common root folder then
it will reside at the root of the first active working folder mapping.
As well as storing the state information locally, Local Workspaces have a number of
important differences to the way they work. The primary benefits of Local Workspaces are
that you can edit files when offline from Team Foundation Server and that you can edit files
outside of Visual Studio or Eclipse without performing an explicit checkout operation first.
To achieve this, when you go to perform actions, such as a check-in operation, or go to see
what files you have pending changes for, the Team Foundation Server client will scan the
contents of your Local Workspace and compare the contents of it with a copy of the last
downloaded versions of those files (which are stored in the $tf folder). In this way, it can tell
which files were edited, which files have been deleted locally, and which files have been
added. Edits are automatically pended into your Pending Changes list; however, adds and
deletes of files performed outside of Visual Studio or Eclipse are classed as Detected (or
candidate) Changes. They are displayed to you, but they are not automatically added to your
pending changes list in case you did not mean to add or delete that file from the version
control repository. If you perform a rename or move operations outside of Visual Studio or
Eclipse, when the disk scanner runs, it has no way to tell that these files are related and sees
that as an Add and Delete of a file (add with the new name/path and delete of the file with the
old name/path). Therefore, in the Detected Changes experience, you are able to associate
those two changes together and promote as a rename.
With a Server Workspace, the information about the state of your workspace is stored on the
server. The server remembers which versions of which files you have downloaded to your
local computer, and also stores which of those files you are in the process of changing and
any files that you have decided to lock so that others cannot edit those files at the same time
as you do.
A cloaked working folder mapping tells the server that you do not wish to download the
contents that are cloaked. In other words, you do not want them to appear in your local file
system, nor do you want to get any. This is useful to apply for a subdirectory of an active
working folder mapping, if this subdirectory contains big files that we are not interested in.
For the cloaked mappings, we do not need to specify a local folder. Normally, mappings are
recursive, but we can make them non-recursive by using an asterisk. Notice that you can also
add a mapping for a single file.
Workspaces can have permissions: read/use/checkin/administer files in that folder if the
contents of that folder are changed on the server.
Get
We use the 'Get' operation to download the files from the Team Foundation Server repository
to your local file system
Get Latest: This downloads the latest versions of all the files as of the time you asked
to start getting them.
Get Specific Version: You can find Get Specific Version under the Advanced menu in
source control. This downloads a version that you have specified by date, label,
changeset number, or simply the latest version. This specification of the version is
called a versionspec in Team Foundation Server.
Versionspec
A versionspec specifies the version that you want to work with, and can be specified using
one of the following types: changeset, label, date, workspace, or latest.
* changesets are the fundamental unit of versioning in Team Foundation Server. Changesets
have a numeric ID associated with them. A changeset versionspec is denoted by C123456 to
Team Foundation Server, where 123456 is the ID of the changeset. * A label versionspec says
you want a version that belongs to a particularly named label. It is denoted by myLabel where
myLabel is the label name. * Date versionspecs are denoted with a D, and then, in the
command line, you can pass any date format supported by the .NET Framework on any of the
date formats for the local computer (for example, D2008-04-22T22:15). * A workspace
versionspec means the version most recently downloaded into the workspace. This is denoted
by a W, meaning the current workspace (or WworkspaceName;workspaceOwner) when
specifying a workspace written as a string. * Finally, the latest version is a versionspec in its
own right denoted by L when written as a string. When you use the Get Latest command in
Visual Studio or Eclipse, you are actually telling the client to perform a Get of versionspec L.
Ranges of versionspecs denoted by the tilde character (~). That can be useful for certain types
of commands
Check-out
With a Team Foundation Server Server Workspace, the initial files destined for your
workspace would be marked read-only in your local file system. Before you start editing the
files, you must check out the files from Team Foundation Server to let the server (and others
on your team) know that you are editing the files. This happens automatically for you if you
are editing files from within Visual Studio as soon as you start typing in the files. But you
must do it explicitly if you want to edit the files outside Visual Studio when using a Server
Workspace. If you are using a Local Workspace (which is the default), there is no need to
explicitly check out a file. If a file has been modified on your local file system, compared with
the version you last did a Get for, then the file is marked as having a pending edit, and it can
still be said by some that it is checked out. When you have finished with the file and want
to commit it back to the repository, you perform a check-in.
Locks
By default, with both Local and Server Workspaces, Team Foundation Server does not
automatically lock a file on check out. If needed, two types of locks are available:
Check-out Lock: Available only when working with a Server Workspace, it prevents
other users from checking out the locked file while you hold the check-out lock. A
check-out lock may not be placed on a file if other users already have that file checked
out in their workspaces. Remember that when someone uses a Local Workspace, he
does not check out the file; therefore, this would not prevent him or her from working
with the file.
Check-in Lock: Check-in locks are available for both Local and Server Workspaces.
With a check-in lock, other users can still edit the file on which you have placed the
lock but will be unable to check it in until you have released the lock. Check-in locks
can be placed on files that others have checked out, but, by placing the check-in lock
on the file, you are guaranteeing that you will have the right of first check-in.
You can unlock a file at any time using the unlock command, but locks are also automatically
released when you check in any changes related to that item in version control.
Administrators can also remove the locks from other users.
Check-in
A check-in is performed as a single atomic transaction. During the check-in operation, the
server first checks to see if you are able to perform the check-in for these files (that is, you
have the Check in permission for the files set to Allow), that there are no check-in locks on
the files, and that you are attempting to check in a change of the latest version of the file. If,
for some reason, the check-in cannot occur, then the entire check-in operation will fail.
Check-in can have associated policies; for example, the Changeset Comments Policy, that
forces to introduce a comment whenever we do a check-in.
While performing a check-in, it is best practice to also associate the change with a work item
(such as a bug, task, feature, requirement, user story, and so on). In this way, you can easily
get end-to-end traceability of requirements on through to changes of code, and into builds,
which is a key feature of Team Foundation Server.
Included and Excluded Changes
When checking in files, the changes that you wish to be included in the check-in operation are
listed in the Included Changes section of the Pending Changes page. You can exclude changes
by dragging them from the Included Changes section over to the Excluded Changes section or
by right-clicking on the files and selecting Exclude. In the Excluded Changes section, you can
also see an area called Detected Changes. This is important, as it shows changes that the
Local Workspace disk scanner has detected that have occurred outside Visual Studio, for
which you might wish to pend changes.
If the Local Workspace disk scanner has detected files that you never wish to be part of
version control, you can specify that they be ignored by right-clicking on the file and selecting
the appropriate option. This will create a file called .tfIgnore containing the details of the
filename (or pattern) that should be ignored. Once checked in, other team members will
inherit these ignore settings, which allows you to ensure that they do not accidentally add the
files that you have said should be ignored by Team Foundation Server. The syntax of the
.tfIgnore file allows for more complex ignore patterns than are possible to configure using the
menu options in the Promote Candidate changes dialog. The .tfIgnore file is a text file and the
settings in it apply recursively to all folders below it in the workspace unless the pattern is
prefixed by the \ character. Wildcards such as * and ? are allowed and you can begin the
ignore pattern with a path to make it more specific.
Check-in notes
Team Foundation Server provides a mechanism for capturing structured data about a check-
inthe check-in notes.
Check-in Policies
For more complex validation of a check-in before submission, check-in policies may be
configured by users who have the Manipulate security settings. A check-in policy is a piece
of code that runs in the client performing the check-in, which validates if the check-in is
allowed to occur.
Undo Pending Changes
Even the best developers sometimes make mistakes and wish that they could simply revert
their changes, instead of checking them in. In Team Foundation Server, this is accomplished
by performing an Undo Pending Changes. This will allow you to select which changes you
wish to undo, and those files will be rolled back to the previous version that you downloaded
into your workspace. If the change you are undoing is the addition of a file (called an add),
the pending add is removed from your list of pending changes. However, the file is not
automatically deleted from the disk, allowing you to go back to add that file if you have
mistakenly undone the change. Note that undoing a pending change reverts the state of the file
back to the point at which you last checked it in. If you want to actually undo a change that
you have already checked in, you should look at the rollback command.
Changeset
When you perform a check-in, all the information about that single atomic check-in operation
is stored as a changeset. The changeset is the fundamental unit of versioning in Team
Foundation version control. It is represented by a numberthe changeset ID, which is a
unique incrementing number across the entire Team Project Collection. The only way that a
change to the contents of a version control repository can occur is by creating a changeset.
The changes that occurred in a changeset are immutableyou cannot go back in time and
rewrite history. However, the owner of a changeset (or an administrator) is able to edit the
changeset comment and check-in notes after the event. In addition, a work item may be linked
to a particular changeset at any point after the changeset is created, and that work item would
show up in the associated work items channel when viewing the changeset details.
Shelvesets
Sometimes, when you work on a set of files, it is useful to store the changes on the server
without committing those changes to the main code line that the rest of the team is working
on. Perhaps because you want to save progress on a particularly large change, you might want
to share a set of changes with a colleague on a different machine, or possibly because you
must stop work on what you are currently doing and go work on a more urgent task before
resuming where you left off. Team Foundation Server provides a simple mechanism to help in
those instancesthe shelveset.
For many instances, judicious use of shelvesets can be a quick and easy way of passing
around and storing version control data with your team, and can reduce the need for
temporary private branches of code.
A set of pending changes can be saved to the server in a shelveseta process called shelving.
A shelveset is uniquely identified by the owner and a name given to the shelveset.
A shelveset is a temporary store of data on the server but one whose lifetime is controlled by
the owner of the shelveset. This means that:
if you delete a shelveset, the contents of that shelveset are gone. A shelveset cannot be
undeleted.
if the same person saves a set of changes to a shelveset with the same name, the
contents of that shelveset will be overridden with the contents of the new shelveset.
Shelvesets contain the same metadata as changesets (work item associations, check-in notes,
comments, and so on).
To get the contents of a shelveset into a workspace, you first find the shelveset and then you
unshelve
Branches
Generally speaking, a branch in Team Foundation Server can be thought of as a folder that
contains a copy of the source tree from another area in the tree taken at a point in time. A
branch is useful when parallel areas of development are required.
Source Control Explorer
Source Control Explorer as your master control area for Team Foundation version control.
The Source Control Explorer provides a view of your current Team Foundation version.
Labels
A label is a marker that can be attached to files and folders. This marker allows all the files
and folders labeled together to be retrieved as one collective unit. To create a new label, in
Source Control Explorer, right-click the file or folder you want to label, and from the
Advanced context menu, select Apply Label. You can also select the version that you want to
label. You can choose to label by Changeset, Date, Label, Latest Version, or Workspace
Version.
Merge
A merge takes the code in two branches and combines them into one codebase. For example,
if you had two teams of developers working on two branches, and you wanted to bring the
changes together, you would merge them. The branch containing your changes that you want
to merge is called the source branch. The branch you want to merge the changes into is the
target branch. The common ancestor between them is the base version. When you merge, you
can select a range of changes in the source branch to merge into the target branch.
If the same file has been edited in both the source and target branches, Team Foundation
Server will flag this as a conflict. Though significant changes have been made in the 2012
release to simplify the merge experience, if the same file has been edited in both branches, it
will always be flagged as a conflict, even if the changes are to completely different sections of
the file.
For certain changes (such as a file that was edited in two different places), Team Foundation
Server can make a good guess about what should happen (you want to see a file containing
the changes from both places). This is called an automerge.
Branch Relationships
When you branch a folder, the relationships between those branches form a standard
hierarchical relationship. Children who have the same parent are called sibling branches.
Branching and merging
TFS allows to do several types of merging:
Baseless Merge: A baseless merge is when two arbitrary branches in version control
merge without reference to a base version. This is sometimes necessary if the source
code was originally imported in a flat structure without the branch relationship being
in place, or if you want to merge between a branch and another branch not a direct
parent or child
Forward/Reverse Integration: Forward integration (FI) occurs when you merge code
from a parent branch to the child branch. Reverse integration (RI) occurs when you
merge code from a child branch to the parent branch. The terms FI and RI can often
shoot around quite freely during a branching debate, so it is important to understand
what they mean. If you are doing feature development in branches, it is common to
use FI at various points during the feature development cycle, and then to use RI at the
end