Visual Studio 2017, 1 workspace per TFVC project or multiple TFVC projects within 1 workspace?
I am a bit confused about the concept of workspace and working folders. I see in the Source Control Explorer I can setup multiple workspaces on my machine. My understanding of workspace is basically a folder that contains all of my projects (even unrelated ones). For example, C:\Projects
I currently have a single workspace that is called the name of my computer which points to a directory called C:\Projects that has several projects in it that are each their own project on visual studio online. For example: DESKTOP-43DDV90P has a working folder for each project inside of it.
WORKSPACE: DESKTOP-43DDV90P
Source Control Folder: $/Project1, Local Folder C:\Projects\Project1
Source Control Folder: $/Project2, Local Folder C:\Projects\Project2
I would like to know if this is a correct assumption OR if I should be creating a workspace per project like the following:
WORKSPACE: PROJECT1-WS
Source Control Folder: $/Project1, Local Folder C:\Projects\Project1
WORKSPACE: PROJECT2-WS
Source Control Folder: $/Project2, Local Folder C:\Projects\Project2
When I finish setting everything up with a new ASP.NET Core web application under source control my directory structure looks like the following:
C:\Projects\Project 1
this contains:
Project1 (folder vs creates for solution)
BuildProcessTemplates (folder from vs online)
C:\Projects\Project 1\Project1
this folder contains:
Project1 vs solution file
Project1 (folder that finally takes you to the project1 site files)
A TFS workspace is basically an account between your computer and the TFS server. It contains a set of ServerPath -> Local Path mappings, and some settings about how the workspace is maintained (e.g. permissions, file timestamp behavior, etc).
Often when working on a project you'll end up creating branches. This is when workspace mappings become relevant. If you don't have branches, then you'll usually just want to map the entire codebase - i.e. you want all of the sources. But when you do have branches, often you'll want only one branch at a time. For example, if I have this:
You can see how each branch contains the same set of files. If I'm developing something in the FeatureX branch, eventually I will merge it into the Master branch.
This is when your question becomes most relevant: do I have a workspace that contains both of these, or do I have separate workspaces for each branch? This is a matter of preference. I prefer to have separate workspaces, because it avoids the case where I've made changes in multiple branches and only want to check in changes to one of them. For example:
I might not notice in a larger project that I have modified files from two different branches. TFS does allow this, but usually when I'm working in one branch I don't want to affect another one. Another issue that can occur is that TFS sometimes has issues when merging changes if one of the included changesets spans multiple branches. For example, say I check in the pictured change; then I create a new branch (Feature2); then I merge the changeset into Feature2. What should happen? Does it take the copy that I checked into Master or into FeatureX? You can make this work, but the point is that you can also fall into some weird situations. With multiple workspaces, I would only ever see changes for the branch pertaining to that workspace:
