Does Tfs “Check-out lock” consume more resources and slow down VS 2015? - visual-studio

I recently joined to a team at my work that uses "Check-out lock" in TFS.
Check-out lock means that none of the team members can edit a file while it's checked-out in other team member's computer.
This is the first time I use that kind of lock, usually I work on projects without any locks and I notice that my VS(2015) and my team mates is extremely slow, especially when doing actions such as: adding a new file, get latest version(visual studio is not responding for a while) and writing code.
I recently installed Resharper(VS was slow before I installed it) and under it Performance Guide it marked:
Source control plug-in in use as a affecting performance.
Is there a way to prove my concern so my TL will accept my opinion and remove this lock type?

When using exclusive checkouts with TFVC each time you start editing a file, Visual Studio will need to make a server roundtrip to check for the lock status of the file on the server and subsequently lock it. If the TFS server is slow or far away this can take a while. It's likely this team has also configured "Get latest on checkout" which will do a couple of extra round trips.
When adding a file to the solution the problem is aggravated, as Visual Studio will need to lock the project file and the file being added. In case of a new form or control this often results in the creation of multiple files.
In 2012 TFS has introduced a new workspace type of TFVC, the local workspace. This type doesn't support exclusive checkout and keeps edit state locally. As such it's much faster, works better when you're not always connected and generally has much better performance (up to a certain size of workspace). This workspace type is the default workspace type for recent versions of TFS.
The perf issues of your colleagues don't seem to be directly related to the TFVC workspace type nor the use of exclusive checkout though. The warning from Resharper is simply that you have any source control integration enabled:
Source Control | Plug-in Selection: select None for the source control plug-in. This will turn off Git or another VCS provider and improve overall performance.
When using TFVC, only actions that cause server interaction will be slowed down due to the additional network roundtrips. Normal work shouldn't be negatively impacted by it. This suggests your colleagues have other issues on his machine or with the solution they're using. It's likely caused by some extension or due to the large project size. Visual Studio 2015 is the first version of Visual Studio that depends on Roslyn for compilation and it has its issues. In Visual Studio 2017 (especially in 15.6 and later) performance issues have been drastically reduced.
Should you want to convince your boss to stop doing exclusive checkouts, I have some other ammo for you:
Exclusive checkouts were added to TFVC in order to support the older workflows in Source Safe and to prevent issues with merging binary files.
Exclusive checkouts have been discouraged even in version 2005.
Local Workspaces which were introduced in 2012 removed support for Exclusive checkout completely.
The new defacto standard source control mechanism in TFS and VSTS is Git. It has no concept of exclusive checkouts due to its distributed nature.
Exclusive locking is an indicator of other issues in the codebase and the collaboration patterns of the team in many cases.
If the concern is to remove merge conflicts, get better at merging.
Your team is likely used to the fact that they never have to merge things as long as they lock everything. It causes different frustrations. Some perf impact is one of them. But not the perf impact you're describing.


Visual Source Safe --> TFS Migration

Around here we have been working with a bunch of Visual Source Safe repositories for about 10 years or so.
Now I want to get rid of sourcesafe and move on to Team Foundation Server.
Do you have any tips or tricks for me before I embark on this migration? What are the things I have to be careful about?
I am sure this migration will mean that our working habits have to be modified in some way. Do you think that these changes could be a problem for the organization? Think about a group of about 20 .NET developers in a single site.
I just googled, but this walkthrough seems like a good reference, and it mentions the tool VSSConverter which should help you make the migration as painless as possible.
I would like to recommend one thing though: Backup. Backup everything before you do this. Should anything go wrong it's better to be safe than sorry.
My links aren't showing up. This is the address:
There are a few different ways you can migrate. The tool will pull your history, etc. over, but the more pragmatic and simple way is to lock VSS as a history archive and start fresh:
Have everyone check in all changes into VSS, make sure everything builds, etc.
Set all VSS databases to "locked" (read-only rights for all users)
Get Latest on the entire VSS database into a "clean" set of folders on a workstation
Check all of the files into TFS from the workstation
For any history prior to the conversion, folks need to go to VSS, but after a week or two it's realistically unlikely to happen all that often. And you know that the history in VSS is accurate and not corrupted by the conversion process.
Be aware that TFS does not support sharing files between different projects, as VSS does. If you have any such shared files the link between them will be broken during the migration, resulting in initially identical, but now distinct files in each project. Updates to one of these files in TFS will no longer propagate to the copies in the other projects.
If you do choose to use the VSSConverter.exe tool that ships with Visual Studio Team Foundation Server, then you should install TFS 2008 SP1 first as it includes a number of improvements as detailed on this blog by the migration tools team.
Some of the key features of the
release include:
Elimination of namespace conflicts. I
previously blogged about this as "the
rename problem" and we have fixed the
converter to correctly migrate files
with overlapping namespaces. This was
the biggest pain point for most users
trying to use previous versions of the
Automatic solution rebinding.
In this latest version, VS solution
files will be automatically upgraded
to the 9.0 version and checked back in
to version control. Previously users
were required to do this manually.
Correcting of timestamp
inconsistencies. The use of client
timestamps by VSS can lead to
revisions being recorded in the
opposite order that they actually
occurred in. The tool now recognizes
this issue and continues migrating
changes where it would previously
Improved logging. Although
we've fixed a lot of issues, providing
better, more detailed logging will
help users that do run into issues
diagnose the problems.
We are currently in the process of doing this at my day job. We are actually making the switch over in about a month. I am a main part of the migration and a big part of why we are getting off of SourceSafe. To help in the migration, I used the Visual Studio® Team System 2008 Team Foundation Server and Team Suite VPC Image. It was very useful. Right off the bat, the image contains a full working TFS installation for you to play and demo with. It also includes Hands on Labs and one of the labs is running the VSS -> TFS migration tool. If you have an MSDN subscription, once you have played with the image, the next step would be to install the TFS Small Team edition that comes with your subscription.
One thing to note is to make sure you get the latest Service Packs for Visual Studio 2008 and the .NET Framework installed on the image. The service packs fixed some annoying bugs and it definately increased the usability of the system. We have a farely large SourceSafe database with about 90+ projects and the migration tool took about 32 hours to complete. First I made a backup of our sourcesafe database for testing. Then I made the migration on the test sourcesafe database. Afterwards, I checked the source tree in TFS and everything transferred fine. We kept all the history for our source files from VSS which was great. No need to keep that stinking VSS database around after we go live.
We are taking the migration in steps. First the source control and letting our developers get use to using it. Then after that we will be migrating the QA and Business Analysts over to use the Work Item tracking features.
My advice is to take the migration in steps. Don't do too much at one time. Give time for people who will be using the system to train up.
VSS Converter is a far from perfect solution. And there are significant differences between the 2005 and the 2008SP1 version of the converter.
For example, in a VSS DB that's been in use for a long time, there will have been a large number of users contributing to VSS. Many of these users will have left the organisation a long time ago and therefore will no longer have domain accounts. TFS requires mapping VSS users to domain accounts, so you will have to decide whether you map old users to a single 'dummy' domain account or to a current team member.
In addition, VSS Converter 2008 requires these domain accounts to be valid TFS accounts. Whereas the 2005 converter does not enforce this.
If your VSS history contains significant folder Moves, then it's likely you will loose all history before this Move. For example, if you Move a folder to a new location, then Delete the previous parent, you will loose all history. See this article for more explanation:
In one migration I was involved with, we had a 10 year old VSS database that lost all history prior to 6 months ago. This was due to a significant tidy up that took place 6 months ago.
TFS conversion tool <-- Use this
I've used this tool for some times already, the results are pretty satisfatory as it comes with the history of changesets from SourceSafe if you desire too.
Anyway, using this tool you should always pay attention to errors and warnings in the log, and check if everything built okay / passed okay.
It's recomended to also run an Analysis on SS before running this.
Hope it helps
Good guidance there from my former colleage Guy Starbuck. Another thing to add with that approach - you may have decided over time that you want to refactor the way your application is organized (folders etc) and this will give you an oppurtunity to do so.
I've been in situations where we organized a solution haphazardly without thought (let alone major changes in the application) which led to a desire to organize things differently - and the move from VSS to TFS is a great oppurtunity to do so.
As far as the original question:
And: this migration will for sure mean that our working habits have to be modified in some way. Do you think that this changes could be a problem for the organization? Think to a group of about 20 .net developers, in a single site
I would say - yes your working habits will change but much more for the better.
You no should use "Check-out" Locks and "Get-Latest on Check-out".
You can now effectively Branch and Merge
You will now have "Changesets" all files checked-in at the same time will be grouped together. This makes historical change tracking much easier - but more importantly - rollbacks are much easier (ie find all files checked in at the same time and roll them back)
Associating Check-ins to Work Items. Don't overlook Work Items! The biggest mistake you can make is to only use TFS as a VSS replacement. The Build and Project Management features are excellent - you paid for them - USE THEM!
As far as details on how your experience will change, another former colleague of mine (and Team System MVP) Steve St. Jean wrote a detailed article on the differences: From VSS to TFS

Team Foundation Server vs. SVN and other source control systems [closed]

We are currently looking for a version control system to use in our projects. Currently our team is less than 10 people. We have been using VSS for the last 5 years. I have never worked with SVN and other version control systems.
Up to now we have been using VSS, but nowadays more powerful source control systems exists like TFS, SVN, etc. We are planning to migrate our projects to Visual Studio 2010, so the first idea coming to mind is to start using TFS 2010.
My question is: how good is TFS compared to other source control systems? Is it a good idea using it, or should we rather use SVN (or any other system)?
Team Foundation Server is a full Application Lifecycle Management suite. If you have a Professional, Premium, or Ultimate version of Visual Studio 2010 with an MSDN subscription, Team Foundation Server 2010 is now free. All of your Visual Studio users that fall under that classification, as well, and do not require an additional CAL. Other users, however, will require that you purchase CALs to stay compliant with the license.
Using Team Foundation Server 2010, you will get source control, process management, defect tracking, build services, reporting, project portals, and more. SVN is strictly source control. I have used both, and they are different beasts. It would be fair to say that the type of features offered by SVN are a subset of Team Foundation Server, on the whole. While there are third party connectors to make it easier to work with SVN inside of Visual Studio (free, I believe - as well), the native integration between Visual Studio and Team Foundation Server is fairly seamless. From an administrative standpoint, both on the server and project level, you have an excellent balance of ease of use and features.
For the last three years, or so - between two different employers - I have setup and installed Team Foundation Server and maintained it over its lifetime. Both companies have used it to their advantage to be able to bring ordered process to their SDLC. The MSF Agile v5 template, if you are an Agile/Scrum shop, is outstanding. Sprint planning and management has never been as easy with any tool as it is now.
Edit - Added information about small teams:
I noticed a comment to the question regarding small teams. Team Foundation Server 2010, given its price point, makes sense for small teams now, as well. I would not have recommended it with Team Foundation Server 2008, though. With the latest version, there is a very nice "Basic" configuration that provides a lightweight installation, sans reporting and portal functionality. You can also install it locally, as well, if you are a "one man shop" with this configuration (Microsoft actually lists it as an acceptable configuration for a client install.) I have it on my laptop for my POC work - having set up a nightly maintenance plan and moving my backup to Dropbox. Works very well for peace of mind. ;-)
Having worked with TFS, Git, Subversion, CVS and VSS, let me quickly summarize my experience:
It's fair to say that both Visual SourceSafe (VSS) and Concurrent Versions System (CVS) are pretty much obsolete these days.
Git is technically the most powerful tool, but requires some time to understand the concepts. It also plays most of its advantages only if you really go for a distributed scm approach. The number of third-party software supporting Git is increasing rapidly, but is not yet as ubiquitous as for SVN.
Subversion (SVN) offers clean and easy-to-understand concepts with a fairly common-sense and generic approach. A vast amount of integration software for most IDEs and file managers, as well as a lot of extension software is available. Because of the use of standard protocols like HTTP and WebDAV, it also integrates with software that wasn't actually designed to work with SVN, such as Microsoft Office ("Windows Web Folders") and more. SVN would be my recommendation if you are planning for a more traditional, centralized SCM approach.
TFS version control is tightly integrated with Microsofts "Visual Studio" product line and the rest of the TFS development lifecycle platform. For use outside Visual Studio, there are a number of tools and a command line interface, but it really doesn't make sense to use TFS without Visual Studio, believe me. TFS version control is technically one of the worst I've ever worked with. Reasons:
It needs explicit checkout of every single file you work with. The same file being checked out by more than one person at the same time means TFS sees a conflict, no matter whether these people actually changed anything.
TFS uses a "workspace" concept, where actions in your working copy are recorded on the server as you work. You can't just checkout multiple copies of the source tree to multiple folders, you need constant online connection to the server (there is an "offline" mode, but that messes things up). All changes to anything in the local working copy have to go through TFS client tools first, since files are downloaded as read-only.
The fact that TFS shows more conflicts in the UI than are actually there encourages users to just bulk-accept or bulk-reject changes, which leads to loss of changes in one way or the other. It thus obstructs your view to what is actually important, which is a dangerous thing for a version control system.
The UI integration in VS doesn't support many useful operations you need when working with a SCM system seriously, like atomic (server-only) creation of branches, Branching from earlier revisions, undeletion, reverting of changes of a given changeset, and many more.
It is horribly slow, because creation of a branch implies downloading a whole new copy of the source tree if done via the VS GUI. A simple rename of a folder is also really slow. All in all it seems to create a lot of network traffic for simple operations.
The built in "shelving" feature, where you can save away your current changes without checking them in, is a nice idea but very much useless in most scenarios, since it doesn't support conflict resolution or merging when you re-apply your shelved changes to your working copy. If creating branches was as simple, reliable, fast, and straightforward as e.g. in SVN, you wouldn't really need such a feature, since every developer could create their own branches to manage this requirement.
In our environment, a number of bugs have turned up in TFS version control where files that had actually been changed where not recorded as such, and in few cases files were reverted to an earlier version without notice. This really shouldn't happen in a version control system!
Martin Fowler has an interesting post about this topic on his website.

Is TFS's source control just a beefed up VSS or is it significantly different?

My workplace is planning on moving to Team Foundation Server and it's not a moment too soon - anything to get away from the cancer that is Visual SourceSafe.
However, I must ask - is the source control in TFS significantly different (and better) than VSS or is it just a "beefed up" version of the same thing?
I ask this now since this is probably my last window to suggest something like Subversion.
We've been using TFS for the last 18 months, and like many products the first version left a bit to be desired (one of the favourites of TFS 2005 was not to get latest when it said it had, resulting in many build breaks).
However now we're on TFS 2008 SP1 it works exceptionally well. The source control system is fast and intuitive, and integrates seamlessly with Visual Studio. For things like renaming, moving, branching and merging it easily surpasses other tools such as Subversion in terms of how well it tracks things and its ability to merge branches.
In spite of what anybody says, there simply is no comparison between TFS source control and VSS. And you don't have to worry about your repository getting corrupted either!
The only problem that still seems apparent is that every couple of weeks TFS slows down and getting latest takes ages, requiring a restart of the SQL Server to fix. I don't know why this is.
TFS source control is backended with SQLServer. I've used CVS and SVN in the past and TFS source control provides me with everything I need. Note that I don't do a lot of branching, mainly straight-line development with tags for releases. I have used it with multiple developers and I like the merge features -- side-by-side GUI allowing me to choose which version of conflicts to apply. I haven't run into any insoluble problems yet. I'm happy enough that I'm not looking for anything else. I much prefer it over VSS.
I have first hand experience with both TFS and VSS. About the only commonality between TFS and VSS is the icons used in solution explorer to display file status.
TFS is an excellent source control and project management solution. It can support agile practices and comes with support for CI and testing. Backed by SQL it is robust and fast. You can have SVN style access if you want using SVNBridge. It scales awesomely, and copes with huge projects. The TFS team actually dogfooded this one to great success. Its main downsides are cost, and learning curve.
VSS is probably the worst attempt I've ever seen at source control and I think one would be better off using a nightly zip file backed up on an old tape drive than use VSS.
Sourcesafe is recommended for teams of five or less.
TFS is dogfooded by MS, in that they are using it for an ever increasing number of projects and in the thousands of users. There's lots of details of why it's more robust but this should illustrate the paradigm step between the two.
I've been using TFS since early 2006 and all faults I've discovered are PEBCAK. It is extremely reliable.
For starters you can have multiple persons have the same file checked out (however there is still the option to exclusively check out as well).
The storage is database driven, instead of file driven. For me this has made searching the codebase harder, but it allows far easier merging and annotations (who wrote this line of code?).
TFS is much more than just source control as well. Task management, check-in policies, the list goes on
I don't have first hand experience with TFS, but I've used both source safe and svn. From what I've read, your answers are yes, and yes. You can definitely feel the source safe history, but at the same time it's a modern system with the features you'd expect and then some (it does a lot of project management stuff too).

Avoid accidental overwrite between different developers upon checkin or merge

Different developers check in the code touching the same file or different branches could be getting merged. I am new to TFS from the admin side but I do know how to do basic check-in of the code. How can I avoid the code collision from admin side? We are using Microsoft Team foundation server as version control.
Version control systems are made to allow different users to edit the same files and so that when merging, it provides a reasonable experience upon merge. The ability to check out the same file by multiple developers is one of the things that allows teams to become highly productive. When multiple versions of the same product are being developed or maintained, it's impossible to prevent conflicts altogether.
There is a lot of additional guidance available through the ALM RAngers' guides. I highly recommend you and your developers read this.
Visual Studio 2013 offers a much better merge experience than older versions. 3rd party tools like Semantic Merge further improve the experience by parsing the code being merged and applying some additional intelligent logic to prevent conflicts.
For certain notoriously hard to merge files, like SSIS packages, there are additional specialist tools such as BIDS Helper Smart Diff.
Some things you can do:
Make sure developers communicate
Teams that do a daily scrum (stand-up meeting) or have the ability to use Team Rooms in TFS can signal intent and keep others up to date on what they're doing pro-actively. Making sure that there is a dedicated communication channel available and that the users have the Team Rooms extension installed in case they're not co-located. Communication prevents many of these type of issues and is the best solution once such a merge issue occurs.
Have developers perform a get-latest and check-in frequently
While there is no server setting for this, having your developers trained on branching, merging and general source control patterns can help a lot. If a user regularly checks for incoming changes (get latest) and checks in as soon as he is relatively confident about his code (say after the first test passes when using TDD), then chances of conflicts is substantially lower.
The Incoming Changes Lens
Codelens has been updated with a new Lens as one of the updates that was released after RTM. The lens requires both the Client and the Server to be upgraded to at least Update 2 and at least Visual Studio 2013 Ultimate Update 2. It's recommended that when you start applying the Updates, you always stay current, thus I'd recommend you install Update 4.
While Code Lens is an Ultimate feature, it will be moved into Professional with the release of Visual Studio 2015.
Use Exclusive Checkout
If users use the Checkout and lock option to check out a file, they can signal other users that the file is undergoing major changes. This feature requires that all users have their workspace type set to "Server Workspace". Local workspaces, given their disconnected nature, ignore the Lock flag. Though individual users can always override their workspace type, it is possible to set the default workspace type at the collection level.
Disable Merging and Multiple checkout for individual file types
A better solution is to mark file types that are hard to merge, the old style SSIS packages with lots of XML and GUIDs are agood candidate here. Open the Source Control settings and add the extensions of "bad files". This setting applies partially in Visual Studio regardless of the workspace setting (Visual Studio will only offer Take Local or Take Server and will not offer to merge.
Disable Multiple Checkout
It is possible to set the Project's Source Control option not allow "Multiple Checkouts", this will automatically acquire a Lock when a file is checked out. It's not recommended to turn this feature on, as it introduces a lot of frustrating things while working in Visual Studio (most importantly when adding any file, one has to acquire a lock on the project file). As with Exclusive Checkout, this requires all users to use Server Workspaces.
As this feature will prevent any file from being checked out by multiple people, it's often trying to apply way to much force to solve this issue. Only in case your developers mess up on a high frequency, you may enable this feature temporarily while they receive training.

Visual Source Safe Changelists

Maybe just maybe somebody knows of an plugin that will let VSS do perforce-like changelists? I know its a long shot, but we are stuck with VSS.
You say you're stuck with VSS -- would switching to Team Foundation Server be an option? It's basically the successor to VSS, and, if you're under direction to remain a "Microsoft shop", it may still satisy your requirements. Team Foundation Server supports changelists (changesets -- whichever term you prefer). Summary:
Source control Team Foundation Server
provides a source control repository,
called Team Foundation Version Control
(TFVC). Unlike Microsoft's previous
source control offering, Visual
SourceSafe (VSS), which relied on a
file-based storage mechanism, Team
Foundation source control stores all
code, as well as a record of all
changes and current check-outs in an
SQL Server database. It supports
features such as multiple simultaneous
check-outs, conflict resolution,
shelving and unshelving (shelving is a
way to save a set of pending changes
without committing them to source
control, while still making them
available to other users), branching
and merging, and the ability to set
security levels on any level of a
source tree, alongside the most
visible features of document
versioning, locking, rollback, and
atomic commits. The source control
mechanism integrates with Team
System's work items as well; when a
check-in (termed "changeset") occurs,
a developer can choose to have his
code associated with one or more
specific work items, to indicate that
the check-in works towards solving
specific issues. TFS administrators
can enforce check-in policies that
require Code Analysis requirements to
have passed, as well as to enforce the
association of check-ins with work
items, or update the state of
associated work items (like flagging a
bug as "fixed" when checking in code
that has the bug fixed). Individual
versions of files can be assigned
labels, and all files with the same
label forms a release group. Unlike
VSS, TFS source control repository
does not support linking to an item
from multiple places in the source
folder structure, nor does it allow an
item to be "pinned" (allow different
references to the same file from
different directories to point to
different versions in a way that
cannot be further edited).
TFVC supports branching at entire
source code level as well as
individual files and directory levels
as well, with each branch being
maintained individually. Multiple
branches can be merged together, with
the built in conflict resolution
algorithm merging the changes between
two branches of the same file where it
can automatically reconcile the
differences or flagging them for
manual inspection if it cannot. Merge
can be performed at "changeset" level
as well, instead of the branch level.
A successful merge is automatically
checked out in the source control
TFVC is not limited to source code
only, but using the Windows SharePoint
Services infrastructure it is built
on, it provides a version-controlled
library for other documents in the
project as well, including project
plans, requirements and feature
analysis documents among others. All
documents in the source controlled
repository can be linked with any work
item, and access to them can be
controlled by defining access
I do not believe VSS supports this type of functionality. You should probably come up with a business case to management that describes your issues with VSS, and how switching to something else would reduce development risk and improve productivity.
There are numerous free/open source SCMs, as well as some commercial products (like Perforce) that are reasonably priced.
Good luck - I was in a similar situation at one point.