I'm new to TFS so I'm trying to figure a couple of things out.
1) Are you allowed to reference the same code from multiple Team Projects?
2) How do you change the source control location for an existing team project?
The Server-Paths for each checked-in module has a format like $/TeamProject1/foo.cs.On the client-side, those files shall reside somewhere on the local HDD. The mapping between a $/TeamProject1/foo.cs & a local path C:/MyFiles/foo.cs is crafted by a TFS Workspace. Check here for an intro.To your questions:
1) Are you allowed to reference the same code from multiple Team Projects?On the server side: You can have branched, or simply commonly named source files, as in $/TeamProject1/foo.cs & $/TeamProject2/foo.cs, but those are surely different files.On the client side:Each locally mapped source control folder can only be correlated with one local path. In case you try to map both $/TeamProject1/foo.cs & $/TeamProject2/foo.cs into C:/MyFiles/foo.cs you 'll be denied the second time with something like that:In all, I think the answer to this question is a 'No'.2) How do you change the source control location for an existing team project?I suppose that you are trying to change the local mapping, for example from
$/TeamProject1 & C:\Folder\teamProject1 into
$/TeamProject1 & C:\AnotherFolder\TeamProject1
In order to do that navigate in VStudio to "File">"Source Control">"Workspaces.." then select your workspace & hit "Edit". There you can see the existing mappings and edit them.
Can you give an example of what you're trying to accomplish in question 1?
For question two, I'm assuming you're talking about where the code lives on a development desktop. For this, open visual studio and go to: File -> Source Control -> Workspaces. Then click Edit for your workspace. You can change the location here for each project you have mapped.
You can create a workspace that contains code from multiple team projects.
So, if I understand your first question correctly then yes you can do that. Technically the code will be in one Team Project but you can mix it into other Team Projects on your machine or build server using workspaces.
Are you familiar with workspaces yet?
Related
I started using TFS since VS2010. By that time I already created my own TFS server (myname.visualstudio.com). My problem is that I created a new project on the my TFS website (the one with the dashboards). Then when I go to VS2017, and connect to that new project, it asks me to map and get it as expected. Instead of just clicking "Map & Get" button, I instead clicked advanced so that I can configure everything.
On the workspace configuration dialog, I noticed that VS names it as "MYPCBLABLA_1". If I try to remove the "_1", VS says that "the workspace blablabla already exists on computer blablabla", and does not let me use my existing workspace name.
Why does it do so? Can I not use only 1 workspace? From what I understand of workspaces, it is the container of my projects, so different workspace, different set of projects. But what are they really?
Additional info:
I don't know if this helps but on the past, I used to format my PC many times, I'm not sure if that affects the mappings or workspace names when I use VS after reformatting.
Workspaces are maybe the least well-understood feature in TFVC. And you are right in saying they're a way to isolate different sets of files from a TFVC repository.
A lot of people configure a new workspace for a specific project or set of solutions, but let's look at some of the ways workspaces can be used in detail:
Hotfixes: you may need to create a hotfix for something happening now, but you have pending changes in your existing workspace. Instead of shelving these changes, performing a "Get Specific version" on the bugged version, you can also create a new workspace in which to solve this particular problem. After completing the fix you can then continue working with the other workspace without needing to do anything.
Experiments: you may want to do some major refactoring, restructure source control or some other highly impactful operation. Doing this in a new (temporary) workspace helps you prevent messing up your normal work area.
Reviewing other peoples changes: When performing a review on another person's changes, you may want to have a local copy so you can run, annotate and play with the other person's code. Instead of taking these changes into your own workspace, you can easily bring these into a temporary workspace, which you can safely delete afterwards.
Performing a merge, while you are working on other changes: It may be the case that you're working on a new feature an already have some changes merged back to another branch when a release needs to be shipped. In order to prepare this release, without picking up changes or overwriting work in progress in your current workspace, it's often easier to perform these kinds of release activities in a temporary workspace, that way you know that the work is always done on the exact version in source control.
Preventing accidental changes to important branches: By putting your production branch in a separate workspace, you can't accidentally combine changes from say Development and Main into a single check-in. Since Visual Studio often auto-selects all pending changes in the workspace, this may cause unintended changes to your master/main branch. I've written a Check-in policy to prevent these issues, but having separate workspaces is a much safer solution.
Working with multiple developers on the same workstation/server: in some organisations, developers use a remote desktop to a central beefy server to do changes. To ensure each developer has his own set of files, each developer gets his/her own workspace. An alternative is to make the workspace public, which allows multiple developers to use the same workspace folder. But this often leads to all kinds of unexpected issues.
Browsing an old version of the code: if you need to review/compare an older version to a new one, you can often get away with the folder diff view in Visual Studio, but if you need to do more thorough comparisons, you may want to have 2 copies of the same folder in your TFVC repo. Creating two workspaces will allow you to have two different versions of the same folder on your local disk.
Prepare a special version for merges or labels: You can merge and label the workspace version of a set of files. You can create a workspace and then use Get Specific Version to fetch specific versions of specific files, these can all come from different changeset versions. Once you're satisfied, you can perform the label or merge or branch action to store this specific workspace version configuration on the server.
As you can see, Workspaces allow you to do parallel development on one machine, isolate changes etc.
Be creative
As you can see, workspaces are a very powerful concept. Usable for a lot of operations. But you need to understand the concept thoroughly. Many developers don't understand exactly what workspaces are and how they work, they're missing out of some of the most powerful concepts of TFVC.
Consolidating and cleaning up
In your case you now have two workspaces. In order to consolidate these (if you want to), you can unmap the folders from your _1 folder and then map these same folders in your original workspace. You can also delete the _1 workspace from the TFS Server and then update the mappings of the original workspace.
Remember that workspaces are stored on your local machine, but that the TFS server also has a registry of who mapped which TFVC folders to which workstations. So simply deleting files from your local disk is not sufficient. You need to save these changes to the TFS server (this happens automatically after performing a get operation after changing the mappings).
To check which workspaces are registered to your workstation on the TFS server, use:
tf vc workspaces /computer:YOURWORKSTATIONNAME
Then delete old workspaces with
// DELETE the local workspace
tf vc workspace /delete:WORKSPACENAME
// DELETE the workspace registration on the TFS server
tf vc workspaces /remove:WORKSPACENAME
To prevent the creation of a new workspace by VS, I:
Create a local folder to which I’ll map the content of the remote repository;
In VS, connect to the remote repository;
In VS, open Source Control Explorer and navigate to the content I need; VS will show a “not mapped message”.
Click on that message and map locally.
This guarantees that no other workspace will be created, and the current one will be used.
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:
That’s depending on your situation, company policy etc… It’s hard to manage if there are too many mapping in a workspace, if not, a workspace is ok.
Some articles about optimize that can help you:
Using multiple workspaces with Visual Studio
Optimize your workspace
I have a solution containing a bunch of projects all under source control that is mapped to a local folder on a PC, but only for a specific windows user, say UserA.
Now if I log into Windows under a different user UserB I want to be able to use the same code with the same source control, without overwriting any local files (e.g. with the server version. There have been many local changes that haven't been checked in by UserA).
However when I open the solution file as UserB, I get an error saying:
The solution appears to be under source control, but its binding information cannot be found. Because it is not possible to recover this missing information automatically, the projects whose bindings are missing will be treated as not under source control
(this applies to all projects)
The next message box gives me a choice between Temporarily working out of source control or Permanently removing the bindings.
Any attempt to Map the Server folder to the local folder will result in an error stating it's already mapped. Also I said I want to use the existing local code while keeping it under source control (e.g. so UserB can check in the changes and any more changes he makes)
What is the correct way to do this?
If I have understood you correctly, you want to use two users coding in same machine with source control.
You just need to create a local mapping of the source files to a different workspace folder. More detail step for your reference:In TFS, how can I share source files in different location, in same machine, without sharing the full project
Now you have two copies of your soucre files but with different workspace in your dev machine . When "User B" want to use these files on your machine, he just need to select the new workspace to work on it.
However, if you want userB to use the local file mappinged by userA(e.g. with the server version. There have been many local changes that haven't been checked in by UserA) It's impossible and also run counter to the rules of TFS. You must check in the local changes made by userA first, then get the lastest version from server for userB.
To share a workspace on one computer between different users, you need to change the advanced permissions of the workspace from Private Workspace to Public Workspace.
This can only be done by the owner of the workspace, which is UserA in your scenario. See the question How do I choose advanced workspace options? for more information.
Hi,
Its not unusual to include images in a solutions. The problem is that these images is often edited out site Visual Studio in another program and TFS will not pick up the changes. So how do you handle this? Do you need to checkout the image before changing it? What If I have forgot to do that? How do I update TSF with my setup of the solution?
BestRegards
There are two different types of workspaces in TFS.
Server Workspaces
Local Workspaces - New in TFS 2012
Server Workspaces
Within Server Workspaces all files under source control are marked as read only. This means that if you wish to edit these files outside of Visual Studio, the workflow would be:
Check out images
Edit images
Check in images
If you try to edit the files before checking them out, the external program will try to save the edited file, see that it is readonly and then either not let you save, or ask you if you wish to overwrite. Either way TFS does not know you have changed the file.
Local Workspaces
Within Local Workspaces, files are not marked as read only. You can edit them in any program you want. Visual Studio will see that you have changed the file automatically and mark it as a Pending Change. You can then check this file in. The workflow would be:
Edit image in any program you like
Check in to TFS
This way of working is much more akin to Subversion and I think is what you are looking for.
In instance 1 of Visual Studio I want to open the latest version of my source. In instance 2 of VS I want to open a previous version. How can I do this?
I tried opening two instances of VS and just pulling it, but since they both point to the same directory "C:\Source\ProjectName", I end up just overwriting one or the other.
Try creating another workspace and map it to a different file directory. Then have your original workspace open in VS #1 and the new workspace open in VS #2
Is there a reason you don't you just either branch or make copy of the solution to a separate folder on disk? That's what I would do (in fact, branching in TFS is specifically what we do for these sorts of situations).
[edit]
I'm assuming that the Compare feature is not what you're looking for? If so, there are fairly simple ways to enhance the default functionality there, such as using DiffMerge.
If you actually want to have two versions of the file open in two different VS instances, you will have to create an additional workspace that points to the same repository and use "get specific version" on the file you want.
Then you can have one instance of VS open with the latest version and the other instance open with the specific version.
You can learn how to create a new workspace here if you don't already know.