Partager via

Server workspaces vs. local workspaces

  • Article

TFS 2012 and VS 2012 feature a new kind of workspace called “local” workspaces. We continue to fully support the older kind of workspaces (from VS/TFS 2005 - 2010), but we now call these “server” workspaces. In the VS/TFS 2005 - 2010 documentation there is no mention of these workspaces ever being called “server workspaces” – because before the existence of local workspaces, there was no need to have a special name for them! They were just “workspaces.”

You might be asking, “What are the differences between local and server workspaces, and where do these two names come from?”

Offline support

If your workspace is a “local workspace,” several key data structures have been moved from the TFS server onto the TFS client. Thus the name “local” – the data structures are local to your machine instead of being hosted for you by the TFS server. Putting these data structures on your local machine gives VS 2012 the ability to perform a number of source control operations without ever calling the TFS server. These operations continue to work when your machine is disconnected from the TFS server.

  • Opening a source-controlled solution
  • Checking out a file for edit
  • Pending a new file or folder for add
  • Pending a delete on an existing file or folder
  • Pending a rename on an existing file or folder
  • Asking “what are the pending changes in this workspace?”
  • Undoing pending changes
  • Diffing your copy of a file with the version of the file your change is pended against

With a server workspace, all of these operations require a connection to the TFS server. And even with a local workspace, most other operations, such as using the Source Control Explorer, viewing the history of an item, checking in, shelving/unshelving, branching/merging, undeleting items, etc. still require you to have a connection to TFS. But the set of operations which are available offline is actually quite substantial, and frees you up to be able to get some done on an airplane or a train, for example, where a connection to your TFS server or the Team Foundation Service might not be available.

No read-only bit

When using server workspaces (the traditional kind of workspace), every file in the workspace’s working copy that is not checked out for edit/add has the +R bit set. If you want to edit the file, you have to check it out first. In Visual Studio, this is seamless, because typing in the editor automatically checks out the file. (You may experience a slight pause as you type the first character in the document.) The process of checking out the file removes the +R bit and enables you to save your changes to the file to disk.

With local workspaces, this restriction is relaxed. The +R bit is never set on items in your working copy (unless you set it manually!). When Visual Studio asks the TFS version control system “what are the pending changes in this workspace?”, we answer that question not by asking the server for the list of all items which have been checked out, but by scanning the working copy on disk and looking for items which the user has edited.

This means that with a local workspace, you can pull up a source-controlled file in your favorite non-Visual Studio editor, make a change, save the file, and then immediately see your pending edit on the item reflected in the Pending Changes Page of the Team Explorer. No explicit checkout is necessary.

Detected changes (or ‘candidate’ changes)

While edits in a local workspace can be pended implicitly just by editing the file, adds and deletes still must be explicitly pended. However, TFS version control’s workspace scanner also detects new files which are ‘candidates’ for addition, and missing files and folders which are candidates for deletion. The Team Explorer’s Pending Changes Page has a link which shows the number of detected adds and deletes, and provides a link to the Promote Candidate Changes dialog which can be used to pend ‘real’ adds or deletes on these items. This is called “promoting” the candidate adds and/or deletes – because they become real pending changes.

Detected candidate adds can also be ignored from this dialog so that they no longer show up. Your .tfignore file will be updated to include an exclusion which applies to the items you have ignored. If you do not have a .tfignore file, one will be added for you.

Invisible to VS 2010 and earlier

Because local workspaces use a local data store that only VS 2012 and later know how to read and write, local workspaces are invisible to VS 2005, 2008, and 2010 clients which might be installed on the same machine as your VS 2012 instance. If you want to share your workspace between VS 2012 and VS 2010 on the same machine, then local workspaces aren’t for you and you should convert your workspace back to a server workspace so that VS 2010 can see it.

No enforcement of PendChange permission or checkout locks

Because local workspaces allow users to pend and undo pending changes without ever calling the TFS server, these mechanisms for restricting when an item can be checked out are ineffective in local workspaces. Checkin locks still work just fine, but the act of taking or releasing a checkin lock requires a call up to the TFS server.

Converting to and from local workspaces

The “Edit Workspace” dialog can be used to change your workspace type from local to server, or vice versa. The setting is in a combo box marked “Location.” You will need to click the “Advanced >>” button at the bottom of the dialog in order to see the combo box. Once you have made your selection for workspace location (local or server), click OK to make the change effective.

Converting from a local workspace to a server workspace is a fairly quick operation. Going from server to local can take up to a few minutes to complete because backup copies of each file in your workspace are taken and saved off in a hidden folder. These backup copies are required to support offline undo and offline diff operations, neither of which would be possible without a backup copy to undo back to, or a backup copy to compare against.

Performance and scalability

As mentioned above, local workspaces keep a backup copy of each file in the workspace. These copies are compressed, but typically this means that a local workspace takes up about 50% more space on disk than an equivalent server workspace. If disk space is a concern for you, server workspaces may be more appropriate. These backup files are deleted when converting your workspace from local to server.

Local workspaces have scalability limitations due to their use of the local workspace scanner which checks for edited items. Local workspaces are recommended for most of our customers, because most workspaces fit into the “small” or “medium” category in our view – that is, they have fewer than 50,000 files and folders. If your workspace has more than 50,000 items, you may experience performance problems or TF400030 errors as operations exceed 45 seconds in duration. In this case, splitting your workspace up into multiple smaller workspaces (perhaps one workspace per branch), or switching to server workspaces is recommended.

Server workspaces are optimized for performance at large scale and can support workspaces with up to 10,000,000 items (provided your SQL Server hardware is sufficient).

Default workspace location

The default workspace location (local or server) for your Team Project Collection can be changed by launching the Team Explorer and going to the Settings page. Under “Team Project Collection,” select “Source Control.” On the “Workspace Settings” tab, you can change the default workspace type from local to server or vice versa.

Comments

  • Anonymous
    August 13, 2013
    For BI Projects (SSIS/SSRS/SSAS) I don't think local is a good option as we deal with unreadable XML files and that is a pain to merge! I'm now switching back to "Server" after experience a few issues! Non BI World will probably prefer local :) Take care Emil

  • Anonymous
    May 12, 2015
    When I switched my workspace to local, Visual Studio checked out and modified a bunch of .vspscc files, changing "SOURCE_CONTROL_SETTINGS_PROVIDER" to "PROVIDER" instead of "PROJECT". But if I check those changes in, won't that break things for the other developers on my team who are still using server workspaces?