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.
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 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.
I have very small and quick question.
Is it neceseary for all the developers that are participating in writing a shared project through TFS, to have that project placed on the same path on each of their machines?
So for example if I have a project "TEST", and I place it in C:/Projects/, does everybody who will be mapping this project from TFS have to place it under the same path, or they can put it in different paths as long as the subfolders of the TEST project are then the same as they are at Source Control of TFS? So in our example, if someone will map that project in C:\Documents\Users\MyUser\VS2010Projects\, will it project some problem with check ins, and getting latest version(by others)?
My small project team has starnge issues lately, and I never thought it can be a problem, but I'm starting to think so and I would appriciate some response from someone who has some expierience in that field.
Lucas
If you have set up your source control paths & your solutions properly this shouldn't be an issue. Let's say that you have a project1 that uses a lib named core. If you set this as follows users can map wherever they want in their local PCs in the content under $/.../Program1:
$/../Project1
/SharedSources
/Lib_branch
Lib.csproj
/Sources
/Project1A
Project1A.csproj
/Project1B
Project1B.csproj
Project1.sln
If you are set as follows:
$/../Lib
Lib.csproj
$/../Project1
/Project1A
Project1A.csproj
/Project1B
Project1B.csproj
Project1.sln
things are more challenging, since - in order for the solution to work in each workstation - both$/../Lib & $/../Project1 have to be mapped in the same level.
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
Let's say I have my TFS team project setup the way I want it, and all the code between my machine and the team project is in sync (i.e. if I do a get latest it says everything is up to date).
What I would like to do is test whether or not I can pull the project back down to my local machine from TFS source control have everything work properly. By work properly, I mean I'm able to build all the projects, run the web sites, etc.
I thought what I could do is just blow away the code on my local machine and then do a get latest. But TFS seems to think that my local machine and TFS are still in sync (this is a bit different from the way Visual Source Safe worked).
In a nutshell, I'm just trying to test whether or not if another developer were to pull this team project down to their machine, that I know the project is setup correctly with all the necessary dependencies, etc. such that the other developer could build and run the project. But since I only have one machine to test this with currently, I need to do this test on the same machine.
The only way I've found to do it is to use "Get specific version" and force it to overwrite existing files, but it seems like if I delete the stuff off my hard drive, it should know when I do a get latest that "hey, the files aren't there anymore, I need to pull them down".
Any ideas on how I can do this? Thanks.
Not withstanding the answer above highlighting the merits of having an automated build process and continuous integration...
The easiest way to validate what you've checked-in is to create a new workspace with the same folder mappings, albeit to a different location on your hard-drive. You can then 'Get Latest' into this new workspace and confirm that everything builds locally, this should prove that:
The correct versions of existing files are in source control
All the required files have actually been added to source control
Alternatively if you'd rather not check-in your changes until you've validated your pending changes, then your best bet is to 'Shelve' all your changes (ticking the box to undo your pending changes), and then 'Unshelve' that shelveset into a new Workspace and do your testing against that instance of the codebase... or even ask a colleague to pull down your shelveset and do the validation (typically this called a 'Buddy Build').
TFS is a little different that VSS in that local workspaces are maintained so that every file doesn't have to be compared with every GET. In addition to removing the code from your development machine, you should also delete your local workspace. Check out "Working with Version Control Workspaces" on MSDN:
http://msdn.microsoft.com/en-us/library/ms181383.aspx
Really, though, the best way to make sure that your code can be pulled down and built easily is to create an automated build in TFS for continuous integration. That way you know immediately if you have done something that would make the solution un-buildable.
Check out the overviews of Team Foundation Build on MSDN:
http://msdn.microsoft.com/en-us/library/ms181710.aspx
The answers above are good. Except it will not completely test you entire scenario. If you have references outside of your solution (such as dll in the GAC, or dll from an SDK installed on your machine), creating a new workspace or deleting and getting latest code won't found those problems.
The only way to make sure is to pull down the code on another computer. If you don't have another computer handy, you can use a Virtual machine.
Do Get Specific Version and specify the latest. This will force TFS to download everything, ignoring the current synchronisation status.
TFS uses your workspace to know what is synched between the server and local.
I don't think there is an option to make Get Latest to behave like you want (Get Specific Version and specifying Latest Version and Overwrite).