From VSS to TFS

8/8/2019 From VSS to TFS

1/25

Copyright 2006 Steven St.Jean

Last Updated: 20 Oct 2006

From VSS to TFSAn Introduction to Team Foundation Server Version Control from a Visual

SourceSafe Users Perspective

BY STEVEN ST.JEAN


2/25

From VSS to TFS

Copyright 2006 Steven St.Jean

Table of Contents

License ............................................................................................................................................ 2

What is TFS? .................................................................................................................................. 3

What is a Team Project .......................................................................................................................... 4

What it looks like (IDE Integration) ..................................................................................................... 4Working folders vs. Workspaces .................................................................................................... 5

Selecting the correct Source Control Plug-in ....................................................................................... 6

Workspace Mapping .............................................................................................................................. 7

Getting Files ................................................................................................................................... 9

Get Latest Command ............................................................................................................................. 9

Get Specific Version Command .......................................................................................................... 10

Pending Changes and Changesets .............................................................................................. 10

Pending Changes................................................................................................................................... 10Changesets ............................................................................................................................................. 11

Check-outs .................................................................................................................................... 12

Lock Types ............................................................................................................................................ 14

Check-ins ...................................................................................................................................... 16

Add to source control ................................................................................................................... 17

Delete ............................................................................................................................................ 18

Merge ............................................................................................................................................ 18

Setting a custom tool for comparison and merge ....................................................................... 19

Sharing of files between folders/projects .................................................................................... 21

Labels ............................................................................................................................................ 21

Shelveset ....................................................................................................................................... 22

Tips, Tricks & Shortcuts .............................................................................................................. 23

Additional References .................................................................................................................. 24

Sources ......................................................................................................................................... 25

License

You are given license to use this document for any commercial or non-commercial purpose as

long as it is not modified in any way.

If you modify and redistribute or otherwise try to pass it off as your own, please be aware thatyou will be plagued by 10 million monkeys (chimpanzees really and maybe an orangutan if he

has some free time) pulling on your nose hairs for eternity.


3/25

From VSS to TFS

Copyright 2006 Steven St.Jean Page 3 of 25

What is TFS?

Team Foundation is a client-server source control system that uses a .NETWeb service to access items stored in a SQL Server database.

[MSDNIntroTFS]

Microsoft Team Foundation Server (TFS) is an integral part of the Visual Studio Team

System that offers a myriad of features to allow the different disciplines within adevelopment team to collaborate effectively to produce software products. The blue

rectangle in Figure 1 shows that Change Management (Version Control) is just a small

part of the overall TFS platform but plays a vital role in safeguarding your intellectual

property.

Figure 1 Visual Studio Team System (Copyright 2006 Microsoft Corporation)

Visual SourceSafe is a client-only source control system. Its clients, such as SourceSafe

Explorer and the plug-in for Visual Studio read from and write to a Visual SourceSafe

database, which is a collection of files that are usually stored in a shared network folder.


4/25

From VSS to TFS


What is a Team Project

The question What is a Team Project has been bantered around in the MSDN forumsand blogs since the release of TFS Beta 1. Each organization has their own description of

how they will map their internal processes and products to Team Projects. I am going to

take the easy way out and copy in the definition from Microsoft.

In Team Foundation, a team project is a collection of work items, code, tests,work products, metrics, and so forth that is used by a defined team to track acommon set of related work. Logically (or conceptually), a team project is asingle infrastructure that encompasses all of the separate tools and elementsused in the life cycle of the development of a software application. Eachsoftware application, or "team project," in development is virtually grouped inits own namespace intended solely for the team project. Therefore, a team project is simply a container isolating all of the tools and artifacts associatedwith a particular software application in development, such that all other team projects will not have access to those tools or artifacts (for example, source

code, work items, and documents).

The team project is the central concept that holds together the team endeavor ofcreating a specific software technology or product. For the team members, theteam project concept eliminates the problem of having access to multipleartifacts not relevant to the team project; such an excess of artifacts causesconfusion and delays the software development process.

[MSDNTeamProject]

What it looks like (IDE Integration)

When Team Explorer is installed on a machine that hasVisual Studio 2005 it integrated itself into Visual StudiosIDE. There are three entities that are added, the Team

menu, the Team Explorer pane and the Source ControlExplorer window.

The Team menu gives you access to project alerts, Team

Project and Team Foundation Server configuration settings,

access to the Project Portal (if created), access to the TeamProject Reports site as well as workitem related actions.

The Team Explorer pane is located in the same area as the

Solution Explorer. It is the dashboard for your connectionto the TFS server. From here you can see a filtered list ofTeam Projects that you have access to. Within each Team

Project are nodes for viewing and editing workitems and

documents, viewing reports and viewing and running TeamBuilds. There is also a Source Control node that brings up


5/25

From VSS to TFS


the Source Control Explorer window in the main work area with the current TeamProjects source control root node selected.

The Source Control Explorer is a window that shows a tree view of the source control

repository on the left and the list of files and folders in the currently selected folder on the

right. This view is similar to the main view of a VSS repository. From here you can

check-out, check-in, branch, move, label and manipulate the files and folders in therepository. These actions will be describe in detail later in this document.

Working folders vs. Workspaces

When working with VSS, we always had to configure a working directory prior to

retrieving files. This directory was used house the local copy of the files and folders inthe source control repository. When we did a Getor a CheckOut, our files were placedhere. Under TFS Version Control (TFSVC), we

still have the concept of a working folder called

the Workspace. The workspace is your client-side copy of the files and folders on the source

Workspace - A workspace is your client-side

copy of the files and folders on thesource control server.


6/25

From VSS to TFS


control server [Workspaces]. This is the location where you can work with your sourcefiles in isolation. Your source code modifications do not get back into the repository

until a CheckIn occurs. This allows you to work in a stable environment during your

development as well as allowing the rest of your team to be insulated from your changesuntil you have had a chance to finish and test their functionality.

The Workspace also has the additional benefit of allowing you to synchronize your localfiles with the files on the server, for instance, if a team member deletes an obsolete file,

the next time you perform a Geton that project, the obsolete file will be removed fromyour drive.

Workspaces also hold additional information, such as the versions of all the files you

have locally, the pending change status of those files and the lock status of those files.

This information is used to assist in the synchronization and merging of source filesbetween the server and your machine.

Selecting the correct Source Control Plug-in

The first step to working with Team Foundation Server Version Control is to let yourVisual Studio 2005 IDE know that you want to work with TFSVC. You do this by

following these steps:

1. Within the Visual Studio 2005 IDE, select Tools | Options. The Options dialogwill appear.

2. In the tree view, click on Source Control. The right side of the dialog will showthe Plug-In Selection view.

Figure 2 VS 2005 Options Dialog Source Control Plug-In Selection


7/25

From VSS to TFS


3. Make sure that Visual Studio Team Foundation Serveris selected as the currentsource control plug-in. Click Ok to close.

When you have completed this, you will notice that the Source Control Explorer

toolbar is active.

Figure 3 Active Source Control Explorer Toolbar

If you later open a project that is bound to Visual SourceSafe, Visual Studio will do you afavor and change your selected source control plug-in from TFSVC to VSS. When you

return to working in TFS bound projects, you will see that the Source Control Explorer

toolbar is inactive, the workspace combo is grayed out and your context menu shows NoCommands Available. This is a dead giveaway that your Source Control plug-in is not

set to TFS.

Figure 4 Inactive Source Control Explorer Toolbar

Workspace Mapping

Once you have your source control plug-in configured, you will need to map the servers

files and folders to a location on your local machine. This is accomplished by creating a

workspace. The workspace contains the

mapping from server-side Team Projects/foldersto your local cache. A workspace is unique to a

machine and user, but can contain any number

of mappings from the server to the localcomputer.

Workspace mapping rules:

1. A single server-side folder can be associated with only one folder on the local PC2. A single local folder can be associated with only one server-side folder3. A single local folder can be associated with only one workspace (therefore only one user)4. A workspace can contain multiple server-to-local folder mappings5. A single workspace can contain mappings for one or more Team Projects

Local Cache Refers to the set of folders on the

local machine that are kept in sync withthe TFVC Server through a workspace.


8/25

From VSS to TFS


To create a workspace mapping:

1. From the Source Control Explorer toolbar, click on the Workspaces drop-down.

Figure 5 Source Control Explorer Toolbar - Workspaces

2. In the drop-down click on the Workspaces entry. TheEdit Workspaces dialogwill appear.

Figure 6 Source Control Explorer Toolbar - Workspaces selection

3. Select a source control folder and a local folder to map it to.

Figure 7 Edit Workspaces Dialog

Note: You are not forced to map strictly at the Team Project level. You can map from any point in the source tree

from $/ down to the lowest leaf folder. If you do map at a high level (Team Project or project folder), all of the

folder below that point will automatically be mapped into your local cache.


9/25

From VSS to TFS


4. Make any additional mappings as needed and then click the Ok button to close thedialog.

Getting Files

In the world of VSS, the Get Latestis a simple command. By simple I mean that itlacks the intelligence that is baked into TFS. VSS doesnt have any knowledge of the

state of your working folders at the time the Get Latestis invoked. It just goes out and

indiscriminately grabs the tip of the source control tree and throws it onto your localdrive, nothing more. This behavior may be fine if you are retrieving a small set of files

over your local network, but can be a significant time sink if you are grabbing a large

project or are working remotely over a VPN or WAN (or both). Another drawback ofVSS is that it doesnt clean up files that have been removed from source control since the

last time you invoked a Getoperation.

TFS Getcommands(Get Latestand Get Specific Version) on the other hand are

intelligent commands since they have the advantage of a Workspace. By using the

Workspace, they can determine which version of files you already have in your localcache and will only retrieve those files that are either out of date or missing. By

comparing your local versions to the servers versions and only retrieving the missing/out

of date files, they save time and network bandwidth by not pulling redundant fileversions. The Getcommands are actually misnamed. They do more than just retrieve

code from the source control tree; they also synchronize your local cache to the files and

version on the server. The benefit of this is that if a file or folder is deleted from sourcecontrol between Gets, on your next Get(sync) TFS will remove the deleted folder from

your local cache. This ensures that your local cache accurately reflects the state of the

server.

Get Latest Command

As you would expect, the purpose of the Get Latestcommand is to retrieve the files and

versions that represent the latest or tip of the source control tree. This is just part ofits function. As stated earlier, the Getcommands actually synchronize your local cache

to the state of the files on the server. Any out-of-date (not latest) and new files are

downloaded and any deleted files are removed from your local cache. Any renamed filesare also updated on your drive. When it is complete, your workstation will have an exact

replica of the files on the server as they exist at the moment you asked for them.

Heres the drawback to this functionality. TFS tracks the files and version you have

retrieved in your Workspace. It doesnt read the file or version data from your local files,

but rather from the Workspaces cached data. If you remove (some or all) files from yourworkspace through some mechanism other than Visual Studio, TFS will not have any

idea that a change has occurred. If you then invoke a Get Latest, TFS will happily tell

you that all of your files are up to date and get nothing. This is usually the first bugthat a user reports.


10/25

From VSS to TFS


Note: If you remove files from your local cache without Visual Studio, TFS will not know of the changes.

If you need to force the download of files to your local cache, you must use the Get

Specific Version command.

Get Specific Version Command

The Get Specific Version command is used to retrieve a selected set of files and versions

based on some criteria. Those criteria may be a label, changeset, date, workspace versionor latest. This command also has two options which are very useful.

The first is Overwrite writeable files that are not checked out. We have all had times in

VSS where we wanted to play with a file, but didnt or couldnt check it out of source

control. In this situation, we opened up Windows Explorer, navigated to the file andturned off its Read-only flag. This option will make sure that when you synchronize with

the server that your changes to that files are overwritten with the servers version.Without it, you will get a warning dialog asking you how you wish to handle thesituation.

The second option is Force get of file versions already in workspace. This is the one that

you will use to make TFS behave like VSS. When youve deleted files from your local

cache, this option will force them to be retrieved from the server even if TFS thinks youalready have the most up to date version.

Pending Changes and Changesets

In the world of VSS, an activity was completed as soon as a command was used, so when

a Check-out command was given, VSS gave you the latest version of the files(s) selectedand marked them all as Checked-out. The same was true when you deleted an item

from VSS, the delete was immediate; your request was carried out with only an Are yousure? dialog shown.

Pending Changes

A Pending Change is a change to files in your workspace that only exist within your localcache. This mostly consists of edits, adds, deletes and renames of files and folders. They

are pending because the TFS server has not been notified of them. It will only become

aware of them when a check in occurs. At this point, all of the local changes are

propagated to the source control server and a changeset is created.


11/25

From VSS to TFS


Changesets

In TFS, actions are a bit different due to a new (to VSS users) concept called theChangeset. Microsofts MSDN site defines a Changeset as

a logical container in which Team Foundation stores everything related to a

single check-in operation, specifically: file and folder revisions, links to relatedwork items, check-in notes, a comment, policy compliance and system metadatasuch as owner name and date/time of check in.

When you check in a set of pending changes, Team Foundation creates a newchangeset in the source control server and assigns it a unique changesetnumber. Changeset numbers increase sequentially. For example, changeset #3 precedes changeset #4, and so on. No two changesets may have the samedate/time of check in. Because of this property, changesets also representparticular points in time for the state of the server.[MSDNChangeset]

In VSS we had changes that occurred to each file independently. Each file had its ownversion number even if multiple files were checked in at the same time. We had no way

of logically grouping a set of revisions that made up a bug fix or new piece offunctionality together. We sure couldnt attach that group of files to a unit of work that

we were assigned to show that the work was completed.

Changesets, as atomic physical units of work, allow us to group together all of the source

code revisions that make up a logical unit of work, such as a feature. I think an exampleis in order here.

Lets say that you are given the task of

updating the current find function in a text

editing application that you are working on,to a find in all open files function. During

the course of this change, you refactor the code in three existing files, create a new file to

hold a new find base-class and delete an old file that you refactored all of thefunctionality out of.

In VSS, the deletion of the old file would be a single change to that file (really the folder

in VSS). The modifications to the 3 files would bump up each of those files versions by

one, and the new base class file would be added to the project as version 1.

If at some later point, you needed to retrieve all of the source code in the project as itlooked prior to adding the Find in files feature, you would have a very hard time,

especially because you deleted a file from VSS. Hopefully, you didnt check the Delete

permanently box when asked for confirmation.

Now lets look at the same scenario with TFS. We modify the same 3 files, add the newbase class and delete the old refactored-away file. The first thing we notice is that Source

Control Explorer has placed some icons next to each file name manipulated. The three

modified files have an icon next to them to signify that they have a Pending Edit.

Changeset a logical, uniquely numbered

container that TFS uses to store all theinformation about a single check-in.


12/25

From VSS to TFS


The deleted file has an icon and the new file has an icon signifying a Pending

Delete and Pending Add respectively. We also notice that the Pending Edit column in

Source Control Explorer shows edit, add, and delete respectively.

Note: For a full list of the icons used in Source Control Explorer, see the MSDN article How To: Identify SourceControl Item Status in Source Control Explorer

We then do a check-in of all of the files in the project and we see that the Check In

Source Files dialog has all of the files that we worked with. It shows the edited files

(marked as edit), the new file (marked as add), and the deleted file (marked as delete).After you add a comment and click the Check In button, the add, edits and delete will

be saved as a single transaction. They will be given a single, unique changeset number

and referred to as a unit. Because the changeset is atomic, if any of the files in the check

in had caused an exception or merge to occur, the entire check in would be aborted. For

the rest of this discussion, we will assume that the changeset number applied to this checkin is 2056.

After a week or two you find out that you need to get back to the version of source code

as it existed just prior to the addition of this feature. A number of check ins by you andyour team members have occurred since changeset 2056 was checked in. In this case,

you could use the Get Specific Version command to retrieve changeset 2055. This

would update your local cache with all of the files in the project as they existed when youstarted working on the new feature. The base class that was added will not exist, the

deleted file will be back and the edited files will not contain any of the new feature code.

Check-outsJust like in VSS, TFS check-outs allow you to signal to the system and other team

members that you are making modifications to the code. A VSS check-out always

performs three steps; the first is that it performs a Get Latest on the file(s) being checkedout. In the second step, VSS marks the file as checked out at the server and third, it turns

off the read-only attribute on the local files. There is an optional fourth step that occurs,

depending on your VSS configuration. If VSS is configured for exclusive check-out, alock is also applied to the checked-out files which stop any other team members from

editing the files. At this point, you are able to make code changes to those files.

In TFS, a check-out always consists of two steps; the files are marked as having pending

edits in your workspace and the local fileshave their read-only attribute turned off.

There is an optional third step where a

Check-out lock is placed on the file. This

will only happen if the Enable MultipleCheck out option is unchecked in the Source Control Settings dialog.

Pending Edit a modification that is made to a file

in your local cache that has not yet been

committed to the source control server.


13/25

From VSS to TFS


Figure 8 Source Control Settings Enable multiple checkout

To access this dialog, right click on the Team Project in Team Explorer and on the subsequent context menu

select Team Project Settings | Source Control

You will notice that I didnt say anything about a Get Latest occurring on the checked-

out files. This is by design, but still trips up many users migrating from VSS. This

behavior, while significantly different fromthe behavior of VSS, is in-line with industry

best practices for software configuration

management. Divergence from the wayVSS operates has been a point of contention between Microsoft and a portion if the TFS

user base. To address this point, Doug Neumann, PM for Team Foundation Version

Control wrote the following;

When you perform a get operation to populate your workspace with a set offiles, you are setting yourself up with a consistent snapshot from source control.Typically, the configuration of source on your system represents a point in timesnapshot of files from the repository that is known to work together, andtherefore is buildable and testable.

As a developer working in a workspace, you are isolated from the changes beingmade by other developers. You control when you want to accept changes fromother developers by performing a get operation as appropriate. Ideally whenyou do this, you'll update the entire configuration of source, and not just one ortwo files. Why? Because changes in one file typically depend on corresponding

Note: Check-out does not Get Latest.


14/25

From VSS to TFS


changes to other files and you need to ensure that you've still got a consistentsnapshot of source that is buildable and testable.

This is why the checkout operation doesn't perform a get latest on the files beingchecked out. Updating that one file being checked out would violate the

consistent snapshot philosophy and could result in a configuration of sourcethat isn't buildable and testable. As an alternative, Team Foundation forcesusers to perform the get latest operation at some point before they checkin theirchanges. That's why if you attempt to checkin your changes, and you don't havethe latest copy, you'll be prompted with the resolve conflicts dialog.

Doug Neumann (PM Team Foundation Version Control)

To address customer concerns, Microsoft will be adding an option to TFS Version

Control to force a Get Latest on all check-outs. This option will be included in a future

version of Visual Studio.Net, probably post-SP1.

Lock Types

Most organizations left the Exclusive Check-Out option turned on in VSS so that they

could avoid having to merge code. When VSS applied a lock to a file, no other user ofthe system could touch it until the lock was removed by either a check-in, undo check-

out, or a forced undo by the VSS administrator. Because this option was nearly

universally used, most VSS users think of check-outs and locks as being one and thesame. In reality, they are two separate concepts.

In TFS these concepts have been separated by default. With this in place, we have the

ability to lock files without performing a check-out and also can check-out without

stopping other users from doing the same. The decision to apply automatic locks on

check-out can be made on a Team Project by Team Project basis.

We now have two types of locks available to us, Check-out and Check-in. You will

notice in the check-out dialog there is also a None option, this is the default locking

strategy in TFS, and allows anyone to checkout any file at any time, even if someone

else also has it checked out. This is useful

for teams that are working in different codefiles and also different areas of the same

code file. It gives the highest availability to

source files in your Team Project. Since no

lock is applied to these files, merging ofchanges is a common occurrence.

The lock types Check-in and Check-out have one thing in common; each guarantees you

the right of first check-in. By this I mean that if you apply either lock, no other user

will be able to check-in their changes to the locked file until you either check-in yourchanges, undo check-out on that file, or explicitly release the lock. The big difference

Lock types:

None shared check-out

Check-in others can check-out, but not check-in

Check-out exclusive lock, no one can check out

or in


15/25

From VSS to TFS


between these two locks is what other users can do to the file while you are working onit.

Figure 9 Source Control Explorer context menu Lock menu item

With a Check-out lock, you have exclusive control of the file so no other user can itcheck out. This also means that if someone else has the file checked-out, you cannot

acquire a Check-out lock. Using a Check-in lock, you are still assured that youre goingto be able to check-in your changes first, but you are not stopping other users fromchecking-out and editing the locked file. They will just have to merge their changes into

the file after you have checked in yours.

The Solution Control Explorer pane in the Visual Studio IDE indicates that a file is under

a Shared lock (no lock) by not displaying the word lock under the Pending Changecolumn whereas both Check-out and Check-in locks have the word lock displayed

there. Unfortunately, the Source Control Explorer view does not directly give an

indication as to the type of lock that is held. To find this out, you have to hover yourmouse over the file name and check the tooltip that is displayed.

Figure 10 Source Control Explorer Source Control entry tooltip

Locks are acquired on a first-come first-served basis and are applied recursively. This

means that even if you are not the first person to check-out a file, you can still acquire a

lock on it as long as nobody else has a lock on it. Similarly, if you lock a folder, all of itschildren are also locked. The following rules apply when acquiring locks:

You may only lock an item if you have Lock permission on it A given item may only have one lock on it at any given time You cannot lock an item whose parent is locked by someone else.


16/25

From VSS to TFS


You cannot lock a folder if someone else has a lock on a child of that folder.A file is implicitly unlocked when you check in any pending changes or if pendingchanges are discarded using the Undo command.

So how do you go about getting a lock? There are two ways; by using theLockmenu

command or through the GUI during a Check-out operation. Locks can be applied priorto any of the following operations Rename, Check-out, Delete, Undelete, Merge, Branch,and Add to source control. The Check-out dialog combines check-out and lock

operations into a single dialog. For the other operations, you will see the Lock dialog.

The Lock dialog is where you select the type of lock to apply. The Check-out andCheck-in options are available and will apply to all of the files that are checked in the

Files section.

Figure 11 Lock dialog

In some instances, Team Foundation will apply additional implicit locks to source control

items to give the operation a better chance of success. For example, when the Rename

operation is performed on a file that is locked, both the old named and new named itemsare locked. On a Branch or Add to Source Control command, a lock is placed on the

server side folder where the new item is to be created to stop other users from branching

to the same folder.

Check-ins

Check-ins are very different between the two systems. This is an area that causes a lot of

trouble and takes some time to wrap your brain around.


17/25

From VSS to TFS


When we checked in a group of files that comprise a feature or bug fix into VSS, eachfile received its own version number which may or may not be the same as the other files

in the check-in set. There is no way in VSS to determine which files were checked in

together or comprise a given feature or fix.

In TFS, check-ins utilize a Changeset. Earlier, I described the concept of a Changeset.

This was the logical container that held all of the information regarding a single check-into the repository. All of the files committed during a single check-in will have the same

changeset number. So in this way, we can know that the three modified files, one deletedfile, one renamed file and two added files that comprise our work on a given task, feature

or fix are associated.

Check-ins are also where we will find version conflicts between our local files and the

files on the server. In a shared check-out environment, it is possible for a file to changewhile you are working on it. TFS uses your Workspace to keep track of which versions

of files you have pending changes to. If another user checks-in a file that you are

working on before you finish your changes, you will be notified of a version conflictwhen you check-in your code. At this point you will have to use the built-in comparison

and merging tools to determine what code has changed and to merge your code into the

new server code.

Add to source control

The Add to source control command does basically the same thing in TFS as it did in

VSS, it updates the source control bindings in the file (if applicable) and then adds theitem to the source control repository. There are a few differences in how this is

accomplished however.

The first and most significant difference is that in VSS all operations are single-stage.

When you add a file to source control, ithappens immediately. In TFS, all source

control operations are two-stage, so TFS

does not immediately upload the files to

the repository, but instead just marks theitems as having a Pending Add. When you are ready to commit the change, you check-in

the items at which time they are uploaded to TFS.

Pending Add a new source control file that exists

in your local cache and has not yet been

committed to the source control server.


18/25

From VSS to TFS


Newly added files are displayed in Source Control with the Pending Add symbol and thePending Change column shows the word add. These files only exist in your local

cache and not on the server so there is no chance that another team member will get this

file until you have checked it in.

Figure 12 Source Control Explorer Pending Add

DeleteIn the same vein as the Add operation, the Delete operation in VSS and TFS are different

in their immediacy. VSS Deletes occur immediately on the local drive and also in the

repository. TFS Deletes occur immediately in the local cache and create a Pending

Delete in the workspace. At this point, the server doesnt know about the delete andwont until it is committed to the server using a Check-in.

Once you commit the Delete with as Check-in, any team member performing a Get

Latest on the repository will find their copy of the file removed from their local cache.

Merge

Microsoft has built TFS with much better merging and comparing tools than we had in

VSS. They have also given us the ability to replace the standard compare and mergetools with own favorites. Since we no longer have to fear the merge tools that are

provided to us, we can begin to discover a world where more than one developer can

have access to a file at the same time.

When you check-in a file to the repository that has been changed since you checked itout, TFS realizes that a conflict has occurred and prompts you to resolve the conflict.

You are offered 3 options; discard local changes, discard server changes and merge.

Undo Local Changes will discard the changes that you have made to the file, UndoServer changes will overwrite the changes that have been made on the server with the

code on your local drive. Merge has two versions that you can select from, automatic andmanual. Automatic merge will look at the changes on the server and your local changesto make a determination if the code can successfully be merged without losing either

change. TFS can automatically merge the code only under specific circumstances,

specifically, when the changed lines do not overlap in any way (even whitespace). The


19/25

From VSS to TFS


manual merge is just that, you would use the built-in merge tools (or your preferredcomparison and merge tool) to merge the changed files.

In VSS we saw that once a merge was completed, the merged files were checked into the

repository. In TFS, code files are not automatically checked in after a merge, but rather

are left in a Pending Edit state so that you have a chance to review, recompile and retest

the code prior to checking in the new changes.

Setting a custom tool for comparison and merge

You may want to replace the built-in comparison and merging tools with your ownfavorites in this area. In VSS this wasnt an option, but TFS has exposed this to allow for

a more efficient user experience. Follow these steps to replace the built-in comparison

and merge tool with your own. I will be configuring Team Explorer to useBeyondCompare.

To replace the built-in comparison and merge tool with your own:

1. Select Options from the Tools menu in the Visual Studio IDE. The Optionsdialog will appear.2. From the tree list, open the Source Control node and select the Visual Studio

Team Foundation node.

Figure 13 Options Dialog Configure User Tools

3. Now click on the Configure User Tools button to display the Configure UserTools dialog.


20/25

From VSS to TFS


4. In the Configure User Tools dialog, click on theAdd button. The Configuretool dialog will appear.

Figure 14 Configure User Tools dialog Add button

5. In the Configure Tool dialog,

Figure 15 Configure Tool dialog

a. Enter .* (dot star) in theExtension text boxb. Select either Compare or Merge for the Operation list, put the fullc. Enter the path to the comparison application in the Commandtext box or

use the ellipsis button to search for the file


21/25

From VSS to TFS


d. Enter any arguments needed for the tools command line. The arrowbutton will display the list of argument variables:

e. Click Ok all the way back to the Options dialog to save.

Figure 16 Configure Tools dialog Arguments button menu

Sharing o f files between folders/projects

In VSS, we could perform a Share which created a pointer in one folder back to a file or

folder in another. In this way, file changes checked-in to either location would show up

in the other. There is not comparable feature in TFS.

VSS also had the concept of a Pin. A Pin is a pointer to a specific version of a given file.When a Get Latest was performed on that file, the Pinned version was retrieved instead of

the tip of the trunk. This bit of magic was implemented by VSS creating a share of that

file to itself. Since Sharing is not a feature of TFS, neither is Pinning.

LabelsFrom our use of VSS, we have come to think of labels as being synonymous with a

point in time view of our source code. This view meant that we could safely assumethat all versions of code before the label in a files History were within the label and all

versions after the label were not. This definition when mapped to TFS, defines a

changeset. In TFS, labeling is much more powerful. You have the ability to placeversions of files from different points in time into the label. This allows you to modify

the label when a defect is found by either moving a file back a version, to remove newly

added code, or forward a version, to include a repair.

Because a label contains a collection of points in time represented by file version, the

labels do not show up in a files History view.

To view the files in a label:

1. Select an item in Source Control Explorer2. Select File | Source Control | Labels | Find Label from the menu bar.


22/25

From VSS to TFS


3. Enter the appropriate criteria and click Search.4. Once you find the label to view, click the Edit button to see the files and

version contained in the label.

Shelveset

Shelving is a new concept in TFS. With shelving, a developer can take a batch of

pending changes and place them into a

holding area on the server in a

shelveset. These files are not checked-in,but rather put aside while you work on other

things. This allows you to set aside a set of

pending changes to work on higher prioritytasks or to share your code with another developer outside of the repository.

Once the files are shelved, you can delete them from your workspace with the knowledge

that they are safely stored on the server waiting for you to retrieve them when you are

ready. In the mean time, you can work on other tasks. This feature is especially usefulfor support developers. You are now able to easily switch from coding enhancements to

fixing bugs without a lot of fuss. A typical switching scenario would look something like

this:

1. Shelve the enhancement code2. Perform a Get against the label or branch that contains the code base that

contains the bug code

3. Fix the bug4. Check in the bug fix changeset5. Retrieve the enhancement code from the shelf6. Continue working on the enhancement.

Shelving code can also be useful in code-sharing/code review situations. You can use ashelf as a hand-off mechanism to allow other users to have access to your source code

changes without first checking in the code to the repository.

To hand-off code through a shelveset:

First Developer

1. In Source Control Explorer, select the folder to shelve code from in the Folderstree.

2. Right click on the selected folder and select the Shelve Pending Changes itemfrom the context menu.

3. In the Shelve dialog, enter a Shelveset Name. This name must be unique.

Shelveset a group of files with pending changes

that are placed on the server for safe

keeping (but not checked-in) while

working on other tasks.


23/25

From VSS to TFS


4. If you want to have the local files removed from your drive, uncheck thePreserve pending changes locally checkbox.

5. Click the Shelve button to shelve your pending changes.Second Developer

6. In Source Control Explorer, select a folder in the team project you are pullingcode from.7. From the File menu, select Source Control | Unshelve pending changes8. In the Unshelve dialog, enter the

username of the developer that you are

pulling code from and click the Find

button.

9. Select the shelveset from the Results listand click the Unshelve button to pull the code into your workspace.

When the code is Unshelved, any files that the first developer had checked out when theshelveset was created will automatically be checked out to the second developer. At this

point, the files are checked out to both developers. The first developer can Undo pendingchanges on his side without effecting the second developer.

Tips, Tricks & Shortcuts

Check-in If you use the Pending Changes window to check-in code, yourcomments will persist through any merging that you have to do. If you use the

Check in Pending Changes menu item, the resulting dialog will lose your

comments if merging needs to occur.

Check-in When associating a work item to a changeset during check-in, youcan double-click on the work item entry to see its details. You can also makeupdates to the work item from this view. Any changes that are made are separate

from the changeset, and as such will be saved even if the check-in fails.

Note: To Unshelve another users source code

you will need to know their username and

the name that they gave to the shelveset

when it was created.


24/25

From VSS to TFS


Additional References

Team Foundation Concepts MSDN

http://msdn2.microsoft.com/en-us/library/ms181233.aspx

Team Foundation Walkthroughs MSDNhttp://msdn2.microsoft.com/en-us/library/ms181244.aspx

How Do I in Team Foundation MSDN


Team Foundation Source Control Naming Syntax, Conventions, and Limitations MSDN - http://msdn2.microsoft.com/en-us/library/ms245472.aspx

Using Source Control Explorer MSDN


Working with Team Foundation Source Control MSDN


Visual Studio Team System Glossary MSDNhttp://msdn2.microsoft.com/en-us/library/ms242882.aspx


25/25

From VSS to TFS


Sources

[Workspaces] Working with Source Control Workspaces, MSDN,http://msdn2.microsoft.com/en-us/library/ms181383.aspx

[MSDNIntroTFS] -Introduction to Team Foundation for Visual SourceSafe Users, MSDN,


[MSDNChangeSet] Working with Source Control ChangeSets, MSDN,http://msdn2.microsoft.com/en-us/library/ms181408.aspx

[MSDNIdentify] How To: Identify Source Control Item Status in Source Control Explorer,MSDN, http://msdn2.microsoft.com/en-us/library/ms245455.aspx

[Neumann] Response to Automatic retrieval of latest version on checkout?Doug Neumann - MSDN Forums - 29-Sep-2006,http://forums.microsoft.com/msdn/showpost.aspx?postid=70231&siteid=1

[MSDNTeamProject] Team Foundation Team Project, MSDN,


Date post:	10-Apr-2018
Category:	Documents
Upload:	electrondude
View:	218 times
Download:	0 times

From VSS to TFS

Documents