• TFS put changes into shelveset
• SVN put changes into sandbox / branches

Here are some of the reasons why:

• Checkin policies
• Integrated Work Items and Source control
• Visual Studio IDE integration
• Code Metrics
• HTTP access via webservices
• Integrated Build Server

Reasons companies choose Subversion (SVN)
-It's free
-It's easy to use
-No Build integration
-No Work Item integration
Figure: Better example, Subversion (SVN) is an OK choice
Reasons companies choose Team Foundation Server (TFS)
 -It's free (With MSDN)
 -It's easy to use
-It's easy to install
-High fidelity SQL data store
-No VPN required
-Does not require a server (basic configuration)
-Has Build integration
-Has Work Item integration
-Has Test suite integration
-Has reporting out of the box Figure: Better example, Subversion (SVN) is an OK choice

Bad Process  
1. Check out  
2. Compile  
3. Develop  
4. Compile  
5. Check In

Good Process
1. Get latest
2. Compile
3. Run Unit Tests
4. If Tests pass then start developing
5. Check out
6. Develop
7. Compile
8. Run Unit Tests
9. Get Latest (Always do a Get Latest before checking in as code you didn't change could break your code)
10. Compile
11. Run Unit Tests
12. Check In if all tests passed
13. Wait for gated check-in (GC) to complete
14. Reconcile your workspace if it was successful
15. Check that Continuous Integration (CI) build was successful(If GC was skipped)

That's why source code should be checked in regularly. We recommend a check-in:

• Immediately after completing a piece of functionality, where the code compiles and passes the unit tests Before lunch or dinner
• Before leaving your workstation for an extended period of time

More Information
To enforce this behaviour, you will need to:

1. Install Team Foundation Server Power Tools
2. Right click the Team Project in Team Explorer > Team Project Settings > Source Control
3. Select the Check-in Policy tab
4. Click Add
5. Select the Changeset Comments Policy
   

Figure: Bad Example: No work item is associated with changeset

Figure: Good Example: No work item is associated with changeset

More Information
In order to achieve this, developers need to choose the Work Item tab when check-in and "associate" code with a related work item.

Figure: Associate Work Item with Changeset

As the project administrator, you can take one step further to enable "Work Item Check-in Policy" to enforce this rule in your team.

Figure: Always enable the “Work Items check-in policy”

1. Changeset Comments Policy - To enforce that all check-in contain comments
2. SSW Code Auditor - To enforce coding standards and best practices before check-in
3. Testing Policy - To enforce that unit tests should all pass before code can be checked-in
4. SSW Code Auditor - To enforce coding standards and best practices before check-in
5. Code Analysis Policy – To enforce that code analysis rules are not broken
6. Testing Policy - To enforce that unit tests should all pass before code can be checked-in
7. Builds Policy – To enforce that the developer has built the project end to end before they check-in

More Information

To enable these policies:

1. Right click the Team Project in Team Explorer > Team Project Settings > Source Control
2. Select the check-in policies above
3. Click OK

Figure: Chose check-in policies in TFS

Figure: You can easily fix this by associating tests with a Test Case which in turn "Tests" a bug

/northwind
 /trunk
 /branches (or shelvesets)
  /experiemental-feature1
 /releases (or tags)
  /1.0.0.356

Figure: Bad example, SVN conventions are a dated and ignore releases, hotfixes and Service Packs

Trunk is the old way, Main is the new way as per the branching guidance, and it is the way that Microsoft does things.

Figure: Good example, this makes a lot more sense

Figure: A good format for all your Products/Projects makes it easy to know where things are and what they are for

Read the TFS 2010 Branching Guidance - http://tfsbranchingguideiii.codeplex.com

Figure: Include your original artworks in Source (eg .PSDs in Source Control)

We chose to exempt uncompressed video files as they tend to have large footprints and potentially cause delays in productivity. It is highly recommended that you have a separate backup procedure for these files.

1. Make Visual Studio remind you to check code in
   In Microsoft Visual Studio. NET sharing project code can be configured by ticking the two checkboxes on top, in Options (from the Tools menu) as shows below.

   

   Figure: Check-in files automatically the 2nd checkbox is very important so you get reminded to check-in your project when closing VS.NET. You know how frustrating it is when you want to fix an application and all the files are checked out by some one else!

   What about VB6 applications ?
   In Visual Basic 6 this is done by going through Tools -> Source Safe -> Options and setting it as shown in the diagram below.

   

   Figure: You can also check-in automatically in VB6

   What about Access applications ?
   We also use VSS for Access projects. Access 2000 had problems with MDBs (not ADPs) but Access 2003 works fine with both. The only thing you have to be careful of is that if a form is not checked out, it still lets you modify the form, but when you close the form, it rolls back to the VSS version and you lose all of your changes.

   

   Figure: You can also check-in automatically in Access

   

   Figure: All the basic functions are easily accessible.

   Note: Using VSS in Microsoft Access has a few limitations, most significant of which is the inability to reattach to VSS projects.  Once you have detached from a VSS project, you will need to create a new VSS project in order to place the Access application back into VSS.
   What about SQL Server Databases?
   We save the scripts of every SQL Server schema change in Source Control.

• Normally, you don't need to check the history very often. If you do need sometimes, then get it from VSS.
• Save much space for TFS. For example, we have a about 7G VSS history database, and we may only need a small bit of them every 3 months, so what's the point of coping about 7G file when we only need one line of code?

But there are also some considerations that you may want to migrate the history:

• If the history of source changes will be checked very often, so you can check the old history with the recent together via TFS.
• You are going to decommission the old VSS completely. Say you don't want to keep the old VSS database, and then it will be necessary to keep the information somewhere.
• If the project is very active, then it will be worthy to migrate the history because your developers may need them every day.

If you are going to move the history, the links may help:

• http://msdn2.microsoft.com/en-us/library/ms181247.aspx
• http://blogs.msdn.com/buckh/archive/2004/06/10/152609.aspx
• http://blogger.xs4all.nl/tty1/archive/2006/04/09/85962.aspx

Only use 'Check Out - Prevent other users from checking out and checking in' when checking out binary files e.g. Word documents or third party compiled dll’s. (This will be the default this will be the selected option due to the inability for binary files to be merged on check in.)

Figure: Correct checkout settings at the file level - don't lock files

Do not enforce single check-out at the project level - make sure the 'Enable multiple check-out' option is ticked under Team Project Settings, Source Control.

Figure: Correct check-out settings at the team project level - enable multiple check-out's.

Whenever we setup a new Team Project we implement a basic version control structure. We put "readme.txt" files in the folder structure explaining the different levels, and a solution file called [Client].[Product].sln?located at ?/[Client]/[Product]/DEV/Main?within version control.

Figure: Bad Example, how would anyone know how to sort this mess out?

Figure: Good Example, The ideal solution.

For more implementation details see:
http://blog.hinshelwood.com/archive/2010/05/17/guidance-how-to-layout-you-files-for-an-ideal-solution.aspx

In particular, you should make it as easy as possible to see who changed what and who deleted what and allow a simple rollback to previous versions of non-code files. Files you should put in source control include:
• XSL files
• Word documents
• Excel Spreadsheets
• Visio Diagrams
• HTML files
• Image files, Flash animations and psd files  (yes this takes room in your source control database - but we still want to be able to revert to an old version easily)

Things you don't store are:
• Video files eg. avi
• Installers eg. .msi

Figure: When you use Check-in policies you often will need to select a work item that you selected recently

Make this easy on yourself by adding a query 'Recent'
1. Create a work item query that returns you the last changed work item

   

   Figure: Add a query just for your associated check ins

2. Just copy the 'Tasks - My' query
3. Add the sort date of 'Changed Date' sorted by descending

   

   Figure: The query should be sorted by 'Changed Date'

4. Use that query on your check ins and you find the relevant work item easily

Figure: Visual Studio Team System Web Access Power Tool

There are two ways to do this:
1. If you haven’t checked in any files since you started modifying them then the process is simple:
   • Right click your solution and Undo Pending Changes

     

2. If you aren’t so lucky and have made some commits along the way then the only option is to use the Rollback command.
   • To use this you will need to install Team Foundation Server Power Tools v1.2
   • Find the revision before you started checking code in using the History command

     

     Figure: The last revision before Tristan made changes was 5367

   • Open the Command Prompt in your current working directory and type “c:\Program Files\Microsoft Team Foundation Server Power Tools\tfpt.exe” rollback /changeset:5367

     

   • Click Yes and the rollback will proceed

It would be nice if there was a GUI for this tool so that I can just right click and select rollback. See Better Software Suggestion – TFS

Figure: Use TFS Sidekicks and search for files older than 48 hours to find the naughty boys.

Suggestion for TFS Sidekicks: Add a button to “Email all people their shame list”…. showing their files that are still checked out (until then I do it manually)

If a developer had code checked out to a workspace that they have not even looked at in months, what is the likelihood that they even remember what changes they were making?

Why do workspaces build up?
• Developers use multiple computers
• Developers use volatile virtual computers
• Developers reinstall their workstation
• Developers get new workstations
• Developers leave

Developer checklist:
• Check workspaces often to see what you don't need
• Delete any workspaces you no longer need

TFS Master Checklist:
• Delete all workspaces that have not been edited in 6 months
• Warn developers for workspaces that have not been accessed in 3 months

Figure: Bad example - Rebecca has a workspace that has not been accessed in a while

Figure: Good example - All of Julian's workspaces are current

1. Open VS 2010, File | Source Control | WorkSpaces, click the "Show remote workspaces":

   

   Figure: Manage Workspaces

2. Keep press "Ctrl", select the workspaces which haven't been used for a long time.
3. Click "Remove" button.

Read Refresh the TFS Warehouse manually for more detail.