Team Foundation Server Version Control

 

 

Version control is one of the main reasons that folks adopt Team Foundation Server. Most skilled developers have had some previousknowledge with a version control system. The first thing you need to come to terms with is that every version control system is unalike. Though change may be disturbing at first, there are clear benefits in migrating to Team Foundation Server.  Team Foundation Server offers a robust, powerful, and scalable version control structure that you may rely on to supports the requirements of your software development efforts. Team Foundation Server is a missioncriticalsystem supporting countless organization. It was built from scratch by MS, and is not founded on its earlier version control contribution, Visual SourceSafe.

Team Foundation Server keeps all its version control statistics in a SQL Server database together withthe work item and build data. Team Foundation Server’s version control system is intended to work using Internetbased protocols. It works great over high-latency network links, such as those establish in the typical enterprise wide area network (WAN), or over DSL lines. It offers highly flexible security and permission abilities tied into an integrated authentication methods.

 



Version Control Terminology In Team Foundation Server

You may just plunge in and start using Team Foundation Server version control with very little sweat or training. However, at some point, you might thump into a couple of areas that might demonstratepuzzlingunless you understand the basics of version control. The important concept you must understand is the idea of workspace.

Workspace
One of the first difficulties with the term “workspace” is that it may be a slightly overloaded term. For example, to Eclipse developers, the term   “workspace” may mean the Eclipse workspace, which is completelyunlike from the Team Foundation idea of workspace, even though they both conceptually comprise source code. To others accustomed with version control systems such as PolytronVersion Control System (PVCS) or ClearCase, the term   “workspace”   also means something similar,but exactly the same as Team Foundation Server. For SVN developers, the concept of a “workspace  ”   is totally foreign, and they might accept that this is just the working copy (it is, but also more than just that).  A workspace may be assumed of as the container that bridges the gap between your local computer and the Team Foundation Server repository. The workspace contains several important pieces of information. Workspaces are identified by a name and the hostname of the system the workspace is for. The workspace also comprises the working folder mappings that specify which folders on your local machine map to which folders on the server.      

 

 

Current Working Folder Mappings
The first working folder mapping is frank. This maps the matters of   $/AdventureWork/Main to   C:\s\AdventureWork\Main recursively. If you make this working folder mapping and then do a Get from   $/AdventureWork/Main/Hello, the contents of that folder would be downloaded to C:\s\AdventureWork\Main\Hello.

As stated previously, part of the info contained in the workspace is the working folder mappings. At the humblest level, a working folder mapping  declares which folders on your local machine map to which folders in the depository.

With Team Foundation Server, working folder mappings are stowed in your Team Foundation Server workspace. They are not shared among other employees using the repository (unlike PVCS, for example). Viewing the present set of working folder mappings is very easy:
From Visual Studio, go to File   >>   Source Control   >>   Workspaces >>Select your workspace and click Edit.  
From Eclipse, rightclick on the project in Package Explorer >> go to Team   >>   Manage Workspaces >>Select your workspace and click Edit.  

Alternatively, you may use the tfworkfold command or the Team Foundation Server Sidekicks. It is much more normal to see an example with only one or two Active working folder mappings.

 

 

Get
You have understood the term Get Latest a few times previously without clearlyknowing what it means. To transfer the files from the Team Foundation Server repository to your local system, you perform what Team Foundation calls a Get. Note that this is a unlike term from the one used by SVN or CVS to do this action (referred to in those systems as checkout). The term “checkout” means somewhat else in Team Foundation Server.  When you get files from version control you might do one of two things:

The merely time that you get files is when you specifically tell the server that you want to. This means that you can ensure that you see the state of your files, but, again, this can be a little different from what a VSS user imagines who is used to receiving the latest file as they perform a checkout.      

 


Check-out
When you originally get the files into your workspace, they are tagged as readonly in your file system. Beforehand you start editing the file, you want to check out the file from Team Foundation Server to let the server (and others on your team) recognize that you are editing that file. This occurs automatically for you if you are editing a file from within Visual Studio as quickly as you start entering in the file. But you need to do it openly if you want to edit the file outside Visual Studio. You will perform a check-in when you are done with the file and want to obligate it to the repository.

The concept “checkout” is used by many version control systems, but means dissimilar things, depending on the system. In VSS,   “checkout”  means   “ provide me the latest version of the file and lock it so that no one may edit it.”   In SVN (and also CVS),  “checkout”  means “get the latest version.”  With Team Foundation Server  “checkout”  means “tell the server I want to edit the file and mark the file as writable in my local filesystem.”   When you check out the file, you also get the option to lock the file using a lock type. At last, do not lock the file at all as you edit it is the default.



Check-out and Check-in Locks
By default, Team Foundation Server does not mechanically lock a file on check-out. That is, more than one employeemay edit a file at the sametime. The first employee to check in a file does so as normal — subsequent employees will be prompted to merge their changes with the other mods that have been completed since checking out theirversion of the file if it was no longer the latest.

This manner is extremely valuable in guaranteeingthat teams may develop on the same code base in parallel (especially with files such as a Visual Studio   .vbproj   or   .csproj  that need to be edited each time someone on the team adds or renames a file in the project). However, there are times when you wish to temporarily prevent someone from making changes to a particular file or folder in source control. For this cause, Team Foundation Server offers two types of locks that you may place on a file in your workspace, checkout lock or checkin lock.



Check-in Policies
For more difficult authentication of a check - in before compliance, check  -in policies may be configured by managers and administrators.  A check - in policy is a portion of code that runs in the user performing the check-in, which certifies if the check-in is allowed to happen. For Visual Studio, this code is coded in .NET. In Eclipse or the cross - platformcommand -  line client, the check-in policy is coded in Java. Additional check -in policies are accessible as part of the Team Foundation Server 2010 Power Tools. Also note that the check -in policies imposed by Team Explorer Everywhere in Eclipse and the from a Team Explorer Everywhere client by a user with appropriate authorization. This is because those clients use a distinct (Java-based) implementation for check-in policies. Once organized by the administrator in Visual Studio and in Eclipse, the check-in policies will be in outcome for all users checking in affected files to that team project. If a user attempts to perform a check-in that fails endorsement of the check-in policy, the user will be warned about the policy failure, .cross-platform command-line client need to be configured.  If necessary, it is possible to override the policy.