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).
Related
I'm doing some tests with TFS prior to moving all of our source there.
Right now, I've created a very simple solution and I've set two workspaces, one local and one in the server.
With both workspaces on the last version, I've made some changes in the server workspace and checked them in. Then, I've made some other changes in the local workspace and I've tried to check them in too. Of course, there is a conflict, but I only get the option to keep the local changes or take the version from the server. I would expect to see an option to merge the different changes.
I'm pretty sure I've seen the option to merge before, in some other tests I did some time ago...
Any solutions? Am I doing something wrong?
UPDATE:
I've clicked in the "Annotate" button and it tells me it can't be done because the file TestApp.cpp is a binary file (Error TF206000). Maybe I should add that I've moved the files from git via git-tf. However, the file on my computer seems fine, ANSI-coded, with CRLF line endings, and no strange looking characters in notepad++, or any other editor I've opened it in...
UPDATE 2:
Answering MartW's comment: The file on the server looks the same as on my PC. Well, there seems to be some encoding issue, since the accents are not shown properly. Also, it doesn't let me annotate the file on the server through the browser, with this error: "Valid values are between 0 and 65535, inclusive. Parameter name: codepage".
I've checked through the versions, and I can annotate the first one where the file appears. All the rest give the same error.
Whether merging or not is available for a particular file type is dependant on the file extension, and controllable via the TFS Source Collection settings.
In TFS 2013, this can be accessed from within Visual Studio and selecting Team => Team Project Collection Settings => Source Control. You'll see a list of various file types and associated extensions, along with whether file merging is enabled for those types. CPP files are under the C++ section and should say Enabled - perhaps this is Disabled in your setup?
OK, I think I found it. Apparently, TFS has decided that all my files are binary files. By going to the Source Code Explorer, selecting the file, opening the context menu and selecting Advanced|Properties, I've been able to change the encoding (actually, if I tell it to auto-detect it, it does it just fine) and now I can merge...
Now, I have to find how to change the encoding of all the files (well, just text files) at once.
Somehow my project got its source control bindings mixed up, and I'm trying to bind the local files to the correct place on the server. I am trying first to unbind the project, but when I then try to set up the binding anew and "Add Solution to Source Control", I get, "A project PDAClient.csdproj that you are attempting to add to source control cannot be added because the item AppSettings.cs is already under source control at the selected location"
It apparently only chose AppSettings.cs as the problem file to complain about because it is the first one in alphabetical order. I surmise this because I temporarily removed it from the project, tried again, and it complained about the next file in alpha order in the same way.
To try to outfox TFS, I renamed "MSSCCPRJ.SCC" to "MSSCCPRJ.SCCHide" and also renamed "PDAClient.vssscc" to "PDAClient.vsssccHide" but it simply created a fresh "PDAClient.vssscc"
(PDAClient is the name of the solution and the project)
If I try from VS 2003 File > Source Control > Change Source Control, I see this:
If I then select Bind for the solution, and then the eponymous project, I see:
If I hit "Browse" or the ellipsis button in the Server Binding column, it just "flashes" but opens no dialog for me to make the connection.
So the solution's binding is "invalid" but the project's binding is supposedly valid...
If I then select "OK" I get this:
...which looks promising ("Yes! Fix the bindings!") but selecting the "Fix" button simply takes me back to the Change Source Control dialog without having done anything. So I finally, reluctantly, select the other option, to "continue with the existing bindings" and see:
Okay...it tells me I have to check in a project for that to work, and I try to proceed, but see:
Note that it is trying to connect me to Handheld/Development/Development/HHS, but that's not what I want and need. DEV is a different branch; this is the Release branch. You can see that in the screamshot above in the solutions Path property (set to C:\Project\sscs\Handheld\Release (etc.)) not ...Development...(etc.) I compared the two using the built-in tool and saw that, indeed, the Server version was from the Dev branch (not the desired Release branch) and took the local version. But then I got:
As I then saw that some of the project's files were checked out, I was hoping against hope that perhaps it was now going to work. I tested it by making a change to a method name, but ended up seeing this, "An error or user cancellation occurred during checkout. Some files may not have been checked out. (File was not checked out.)" and then that was followed up with, "Could not perform refactoring because some of affected files could not be made writeable."...and so my change was backed out for me automatically.
Obviously, this isn't going to work, because I do need to make changes to this project.
Flailing about with what's left to me on the File > Source Control menu, I selected "Add Project From Source Control..." to see what it might offer. It first gives me a dialog where I connect to a TFS; I did. I navigated to the right spot on the server, and this looks good and ready to go:
Selecting OK invokes a dialog that tells me, "The local folder you chose to store your solution contains one or more solution files that have the same name as those in the source control server folder." with Overwrite, Cancel, and Help buttons.
I select Overwrite. I am then presented with a dialog:
I select PDAClient.sln (HHS was the former name of the solution/project)
However, when I subsequently select the Open button, I get, "The folder 'C:\Project\sscs\Handheld\Releases\6-4-0\HHS' cannot be used for the solution or project because it is already in use to store part of another solution or project."
I have no choice but to select "OK" which negates the whole process.
As a final head-first, possible-collar-bone-breaking feat of Any-Port-in-a-Stormism Syndrome, I select File > Source Control > Team Foundation Server MSSCCI Provider. This invokes the Kafka-esque Windows 2010 Shell inside of VS 2003 inside of XP Mode. According to what I see there, my setup is correct: The Server's copies of the Release project are bound to the local files Release folders:
But \Releases\HHS is grayed out, indicating there is no connection between the server folders and the local folders. And note that most (not all, but most) of the files in the Releases setup are actually stored locally in the Development folders! There are some key files that are bound correctly:
All the (dozens of) unseen files (only the first and last are seen in the last two screenshots) are tied to Development, too.
Although I don't have a "bind" type of context menu item for \Releases\HHS, there is a "map local"; although it is already ostensibly mapped correctly, I try it out, but get "The local folder could not be set to C:\Project\sscs\Handheld\Releases\6-4-0\HHS because it is already the local folder for another server folder."
So I go up to \Development\HHS, which does have a "valid" binding; note, again, that it is bound to the wrong local path (Releases instead of Dev).
So for it I first select the contextual "Remove Mapping" menu item. This affords me the opportunity to "Edit or remove a workspace mapping." I change the local folder from Releases to Dev. It looks good; Dev is now bound to Dev, and the binding is still seen as valid; this time it really is (I hope, anyway).
I now turn my attention back to Releases, but the context item "map local" is no longer there...and, although it shows the right connection between Server location and local, it is still grayed out...???
Note: The "Pending Changes" list of files is identical with both \Development\HHS and \Releases\HHS highlighted: the same three files in both cases are shown as being in the local Releases folder, and all the others in the local Dev folder.
Back in VS 2003 (out of the VS 2010 Shell running the TFS MSSCCI Provider), I go to "Change Source Control" and see that both the solution and the project have a Status of "Valid" now...when I select "OK" though, it tells me many of the files do not match and to either contact the administrator or perhaps a Get All will solve it. I tentatively look into a Select All, but see that it still says my project is bound to Development. ARGHHHH!!!!
Can anybody make sense out of this madness? How can I get the Release server folders pointed to the Release local folders, and Dev Server folders to the Dev local folders, without any bleedover and mismatching?
UPDATE
I looked in Source Control Explorer (TFS MSSCCI) again this morning, and my Dev\HHS had again gone back to being set to the wrong local path (Releases) and is connected (I guess that's what the glyph of the facing-each-other vertical arrows to the left of the folder indicates).
As to Releases\HHS, it was not connected (no glyph), but I was able to right click and map to a new folder I set up.
Here's what I see now (after changing the mapping of DEV from the local Releases folder back to the local DEV folder AGAIN!).
Properties for Dev HHS:
Properties for Release HHS:
I don't know if this makes sense to you, but it looks fishy to me.
UPDATE 2
The madness continues unabated today. My solution claims to have two pending checkins:
When I select "Check In," I get a confirmation dialog; I continue with the "Check In" button there. Then I get the "Check In - Source Files" dialog. I select the "Check In" button there, too. But then I see, "Files not checked out"
If I repeat the operations above, the last message is:
No Changess to Check In
All of the changes where either unmodified files or locks. The changes have been undone by the server."
???
IMO, I would have saved a lot of time by just zipping up files when I wanted to save the latest changes, rather than use this irksome beast; I spend more time fiddling with "productivity" tools than just using a more straightforward approach. Give me zip files and a good diff util over this cauldron of dashed hopes and clever-clever dirty tricks!
UPDATE 3
And if I close the project and re-open it, I see the following three times in a row:
So who in blue blazes told you to find such a server?!?!
Then I get:
And finally this again:
Argggggghhhhhhhhhhhhhhhhh!!!!!!!!!!!!!!!!!!!
UPDATE 4
Even though the path for the solution and project are right (Releases), this is what the files in the project show:
The branches tab, as shown in Update, show Dev going down to Release; I don't know if that's right or not, because Release was a branch of Dev,
or...???
Anyway, I see the above from File > Source Control > Team Foundation Properties
HOWEVER, when I choose File > Source Control > Team Foundation Server MSSCCI Provider, the binding seems to be correct - the HHS Dev project has Dev as its local folder location, and the HHS Release project has the Release folders as its local location.
I don't know who is more confused: me, anybody who happens to read this, or TFS/MSSCCI itself. This kind of thing is, ironically, a real productivity killer.
Had to change my computername and domain. Now I can't access team foundation. I tried this statement to fix it.
tf workspaces /updateComputerName:MyOldComputerName /s:"http://MyServer/MyCollection"
It didn't work. I get the following error "Key not valid for use in specified state."
Not sure what to do now.
It sounds like you may have a problem that will prevent remapping the workspace. However, it's possible that the command isn't quite correctly formed, so try checking the collection URL (I'd expect it to include MyServer:8080), and in versions of TFS 2010 onwards the documentation refers to /collection: rather than /s:
If that fails, then one approach to rescue things is to create a new workspace and delete the old one. You can transfer any edited files you had checked out to the new workspace as follows:
Rename your old source code folder, so you keep a backup
Create a new workspace that maps the (old) source code folder location, and Get the latest version of the code.
If you think you deleted or added files, use a folder-diff utility to find them, and manually re-do those changes.
Now check out everything (right click on the root folder and check it out)
Copy your backed up source code over your workspace folder
Undo checkout on everything. Visual Studio will ask if you want to discard your changes. Carefully choose the "No to all" option. This means it will only discard locks on unchanged files.
You will now have all changed files listed in your pending changes.
Once you're absolutely sure this has all worked, you can delete your backup of the source.
(You can achieve a similar thing by unplugging your network cable to force Visual Studio to go offline, moving your old source code back in place of your new workspace folder, then plug the net cable back in and using File > Source Control > Go Online. This should diff your code to the server and work out what changed. I don't trust this as much as the above approach though)
Once you have the code in your new workspace, you can use the tf command to delete the old workspace to clean everything up.
Just started up Visual Studio 2012 and opened my solution which is in source control with Team Foundation Server 2012 Express and encountered this, any ideas? Can't get latest, can't check in, everything appears checked out :( Basically my workspace is unusable right now.
TF400018: The local version table for the local workspace MY-PC;My
User could not be opened. The workspace version table contains an
unknown schema version.
There is only one post I could find on the net, and the answers are pretty vague.
I had the same issue, and I just fixed it on mine.
If you don't mind re-map all your projects, you can try follow:
Click the box in "Workspace".
Click on "Workspaces".
Delete the workspace profile you're currently using
Re-connect to TFS open "Source Control"
Be aware that you may lose all your TFS mappings, you may need to re-map all your projects from TFS. Backup your changes that not checked in yet.
cycle6 is correct, but it isn't clear that you will not lose your pending check-in list if you follow some additional steps.
Click the box labelled "Workspace".
Click on "Workspaces".
Delete the corrupt workspace profile, accepting the warning.
Re-connect to TFS and open "Source Control Explorer"
Create a new workspace
One by one, map your projects to the same folder as before
You will be presented with a list of conflicts, where you have matching writable files in the folder already.
Choose "Keep local copy" for each file you had checked out before, and "Take Server Version" for any files changed by other members of the team that you didn't have the latest version for. This might take a while depending on the length of the list, but it is worth comparing versions for any file you are unsure of.
You will be left with your solution and all pending items marked as checked out, with your work preserved.
I did the following steps and it solved the issue:
deleted the hidden folder named $tfs and then
in the Visual Studio, Solution Explorer: Right click on the solution node > the Source Control > Get Specific version > latest version
If you already have multiple instances of Visual Studio open.
Close all of them . [in some cases you need to log out from windows & log back in OR restart ]
Rename the $tf folder with any other name (eg. $tft)
Start Visual Studio, to see your issue fixed. :)
Hope this helps.
Sometimes this happens when you are running out of disk space.
Try to see if you have very low space, eg. < 10 MB.
If that so, try to clean up your windows Temp folder. See if that solve this issue
It's a misleading message to an extent.
What has happened is that the internal data structures of the workspace have become corrupt.
The ends up as the code (in the tf command, Visual Studio, et al.) to load those data structures failing to load from the relevant files, which becomes an error about a schema version problem.
In the case that I experienced, this was because the machine hosting the workspace ran out of disc space while doing operations upon the workspace of various kinds (check-outs, check-ins, adding pending changes — it was actually a bunch of workspaces being used by TFS 2017 build agents and multiple active builds).
This corrupted parts of the data that are held in the files under the hidden $tf subdirectory (it always being a local workspace on a TFS 2017 build agent), because source control wasn't able to rewrite/extend these files.
Other answers here discuss partly retaining some of the files, based upon more specific knowledge of what has not been corrupted (such as preserving the internal files storing pending changes if one wasn't creating any pending changes), but the basic idea is that one needs to reset all of the stuff in $tf to a sane state of some kind.
In my case, I had the disadvantage of multiple potential causes and no consistent knowledge of which parts of $tf were corrupted, but I conversely had some advantages:
It being a TFS build, arranged to build from the build agent's s (source) directory into its a (artifact staging) and b (binaries) directories, there were not masses of non-source-controlled object and other files in the workspace (which is the s directory) that would have ended up as pending additions.
There were not any pending changes (to actual source files) worthwhile to preserve. I could afford to lose all information about source files, and indeed all current locally-stored information about the workspace, and simply run the build again with a fresh sane and largely unpopulated workspace. I did not even need to restore source files and directories for the whole workspace, as the first task in any TFS ("vNext") build is a "Get Sources" task that uses (variously) tf vc scorch, tf vc undo, and tf vc get to check out the right source version.
So simply, in Developer PowerShell (Visual Studio being installed on the build machine):
Remove-Item -Recurse -Force 'X:\Agents\07\_work\1138\s'
tf vc get 'X:\Agents\07\_work\1138\s'
(Note that one can always get at the tf command in some way on a TFS build machine. Every build agent has a local helper copy of tf.exe and its ancillary DLLs in its VSTS "OM" subdirectory.)
I possibly could have omitted the tf vc get step, but having had trouble with "Get Sources" in the past I do not trust it to robustly cope with arbitrary manual external alterations, such as no s directory when the build isn't configured to outright delete that entire directory itself (as it can be but was not here).
For the same reason, Microsoft's own "agent maintenance" (another way to clean things up) is quite dodgy, and ends up leaking workspaces on the TFS server (which I have raised a bug with Microsoft about).
There is simple workaround. Remove local mapping to folder where is the sources (Advanced -> Remove Mapping, or just rename or delete mapped folder. After that you will be able to connect to tfs. Download the project again.
If you already have multiple tfs instances of Visual Studio open.
1.) Open File -> Source Control -> Manage Workspaces
2.) Delete all tfs map
3.) Then select folder maps
For the same issue in eclipse: Find the folder $tf and delete it.
You will find the $tf folder in the workspace directory. If not then search for the $tf folder.
Once you have found it, delete it.
In my case, none of the other answers helped - the problem was occurring on a machine that didn't have Visual Studio and no matter how I tried to get rid of the bad workspace data it never worked. After working with procmon a bit, I discovered another critical folder that might be the source of this error: C:\Users\All Users\Microsoft Team Foundation Local Workspaces\ (it might also be under C:\ProgramData (on my system, 'All Users' is a symlink to that folder, but not sure if this is typical.) In this folder there are sub-folders named like guids that contain some other folders, one per workspace it appears. In my case, some of the data in these folders was old and some was corrupt. Once I deleted the bad workspace folders, all my problems disappeared. You might also want to delete the Cache folder as identified in the comments of this post, but that didn't help me (didn't seem to hurt though, either.)
Alternatively, you could just backup your current workspace to a different location, re-create your workspace, and copy the files back that you had made changed to. VS should detect the newest files and automatically check out these files allowing you to check in the newer versions that you copied back from your backup.
What worked for me is, delete the local folder(s), restart your machine, then map the projects again. Any pending changes you have just save them somewhere else temporarily.
I mistakenly wiped out my workspace mapping to my local folder. No my solutions all say they are not downloaded, but the code is still there of course. I've got worked checked out. How do I make this right, or even can I?
Have you tried to remap your workspace like described here?
Before you do anything, back up your code - copy it to a folder outside of your mapped workspace folders. That way, if anything goes wrong, you won't lose your code.
The worst case scenario if you do this is then:
Fix your mappings and Force get all the code (so you lose your changes)
Copy your backup files back over the source code
Get locks on your changed files (Either: a) Check out everything, then undo check out, but say "no all" to the question about throwing away changes. This will leave you with locks only on files that have changed) or b) Go Offline (unplug your net cable, run VS, and it'll go offline) then go online (plug in net cable, File > Source Control > Go Online) and TFS should auto discover your chnaged files)