I have a tfs on visualstudio.com and I access it from my home and work by using same live.com login. These two computers are named the same (even the full paths to the solution folder are the same) and thus the workspaces got named the same. Now, when I try to do get-latest, it never gets me anything whether I am at home or at work because it probably thinks it already has all latest files in it. Assuming my hypothesis is right, is there a way to make these look distinct to the tfs ? The only way to get-latest for me is to get-specific and mark the second tick, but it also overrides my web.config file (which is not exactly the same since the connection strings are a bit different) which is excluded from the project for obvious reasons (to not be locked/changed since each user needs it different for their own sql server connection string)
Workspaces are uniquely identified by workspace name and username. However TFS only sends a list of "local" workspaces to each machine that you use based on its name. If you have two machines with the same name then they both workspaces will be listed as local to that machine and Visual Studio will get confused and your workspaces will be corrupted. To solve this issue you need to rename one of your computers.
You can work around it without renaming the computers by creating two workspaces with names like "home" and "work". You will however need to make really sure that you only use one in each location as crossover will give you the same problem as above.
Related
I'm switching to a new machine and would like to keep my TF files as they are. Thus I simply copied the entire folder to the new machine's (same as the previous one - C:\TF), mapped it to the TF server's root, and attempted to open a solution from the file explorer, hoping that it would bind more or less automatically.
I then ran into issues similar to others that have been described elsewhere, such as here and here. VS/TF insist that the binding on the solution and all projects is "invalid".
Unbinding and re-binding does not work, the binding reappears but remains invalid.
Recreating the workspace does not work.
There is nothing funny about the solution file's content.
The relative paths are correct - if I remove the bindings and try to add the files to source control, it overwrites the already existing files in the source control explorer (the item previously appearing as a grayed-out "Not Downloaded" becomes white with an "add" pending change).
Tried mapping the workspace to a "fake" network drive that pointed to the new machine's hard drive (just in case TF was mixing up the identical paths), still the same.
Deleting Team Foundation's AppData settings doesn't work.
When I perform a get on the solution folder, though, the binding becomes healthy all of a sudden. In the end I performed the get, deleted all the new files and put the ones from the old machine in their place. VS/TF apparently had no issues with the binding then. It's a rather inconvenient way of achieving that end, though.
I'm forced to conclude that TF doesn't want me to bind my own, local files to source control without first performing a get in that workspace, even if the file paths match what is on the server. Question: why is that? Am I doing something conceptually wrong? Doing it the wrong way? Is this behavior an idiot-proof feature of the tool, or just a limitation?
You're doing it wrong :/. | it's a feature, not a bug.
The workspace is registered on the VSTS/TFS server as well as in the local workspace cache. After moving the folders over to a new machine (and to the same folder location), you need to tell VSTS/TFS the new computer name these files now reside on.
You have to run tf vc workspaces /updateComputerName:oldComputerName workspacename to update the workspace registration on the server.
But I'm afraid you need to do this before overwriting the workspace with a new mapping.
Now I think the only option is to use the Unbind option, save all, then open the source control menu again and rebind all the projects in the solution. Or edit the solution files manually (there's a tool for it as well).
I have two VS2013 sessions opened, each with a solution that is version controlled by the same visualstudio.com TFS repository.
In one project I wanted to check in some files, but Check In will always want to check in changed files from all my other VS projects.
Is there a way to make Check In work only on the current project?
It's very confusing when checking in project A also checks in project B when I am not ready or certain about the state of project B.
Check ins are based on your workspace, not the solution or project you are working on, which means a check in will always detect changes made in any of the folders that have been mapped from source control, regardless of which instance of Visual Studio they were made in (since it looks at the physical disk to determine what changed).
You can be more specific about your workspace mappings and/or use multiple workspaces if you wish to have a smaller scope for your check ins, though this brings with it usability complexity as you now need to ensure source control explorer and pending changes are referring to the correct workspace.
If instead of checking in with no scope (defaults to workspace wide) you can right click on the scope you want.
If you right click on the solution and select check in, Visual Studio will filter the checkin for you. It will be scoped to only files in that solution.
Whenever this happens to me, if I have made changes in the VS instance i do not want to check in, then navigate back to the one i want to check in, I am presented with an alert box that says something like "the files have changed, would you like to update them?" If this is true for you, you could just say no.
Alternatively, if the each VS instance is touching code in different branches, then you may choose to "exclude" (in team explorer) these other-branchly files.
I am trying to merge one project into another using TFS' MSSCCI Provider in XP Mode. These are "legacy" (in the sense that a Pterodactyl is a legacy avian) projects built and maintained in Visual Studio 2003.
I get a few conflicts about the local file being writable, but based on what I could glean from a bing search, I can just go ahead with the overwriting in most cases.
However, I have a special case: a file that, based on its name, is a TFS "housekeeping" file, namely mssccprj.scc:
I don't want to hose up my TFS connections and so am wary of overwriting this file. Should I or not? And if not, what is my option for saying, "never mind, this isn't really a conflict"? It seems as if I either "resolve the conflict" or the merge will fail.
UPDATE
I have the same issue/question with a file named "vssver.scc"
How can I have the same user on multiple virtual machines be able to share the same workspace folder? Should each user create a "public workspace" or should we change our practice?
A bit of background :
when we worked with VSS and VB6 / ASP each user would map to a personal share (w:) which would map to \server\username\ . Every machine mapped w:\ to the user, so that when the user moved from one virtual machine to another they would find the state of checked in / out to be consistent. (at worst they'd get a message from VSS saying you checked this out on xxx and now you're checking in on yyy... -> and they'd just click ok)
Now we're moving to TFS and we're finding that workspaces are specific to each machine (check out on machine A, and find that machine B is unable to edit)
I was looking at Public Workspaces, though that seems to be designed to resolve a different task I thought it might cover the issue... So I was wondering if this was a safe practice and if anyone has actually tried it, or if we'd be heading for a major trainwreck.
Thanks!
My analysis: Trainwreck.
Each user/machine should have their own local (ie: non-network) path for the workspace.
I started work a lone developer last year and I found VSS is no longer a good option for source control so I decided to use TFS 2010 instead.
I have had to learn everything from a book - of which there are few.
I am currently creating a new build and in my workspaces I see a have 4. I want to delete one of them and rename another.
However I do not know what the consequences of doing this are. If I delete a workspace, will that remove the associated files under source control? How do I check which files these are? What happens if I change a status from active to cloaked?
As you can see, I am a beginner in all this.
Workspaces are only a mapping from SourceSontrol folders onto your local file system. Also workspace contains information about versions of the files you have locally, so when you hit 'Get Latest Version' only recent changes are sent from server to you, not the whole files. Information on what files are checked out is stored in workspace too, so if you have pending changes in the workspace and delete it then there'll be a bit of a challenge to check these changes in. Renaming of the workspace will not break anything as far as I know.
Article An introduction to TFS Workspaces may be interesting to you.
Like the others have said, the workspace only says what local files you have checked out, and the status, etc. Workspaces are pretty granulal (i.e. per user and per machine) so you could have mutliple workspaces with the same username in the same project. E.g. if you have a copy of Visual Studio at work and one at home, you could have different files checked out and you wouldn't run into any conflicts like you would have in VSS or something based on VSS Like like VSSConnect.
We've had a couple of people leave out project and have had to go in and remove their workspaces after the fact. This hasn't been a big deal in terms of any code losses but if you don't have access to the machine anymore you will have to use the TFS tools.
Try TFS Sidekicks, it provides a nice GUI to manage all the nitty-gritty back-end stuff in TFS