Task: A fresh fetch of TFS branch source takes 12+ hours to download due to latency on the VPN (everyone working from home). A in office local fetch takes 7 minutes to a SSD drive.
If we manually ZIP the files via an office VM and upload to home, an unzip, this can happen in less than 30m. We use an on premise TFS 2019 server.
Problem: Visual Studio shows "not downloaded" and requires a fresh fetch. I want to be able to tell TFS manually that the server and local copy is in SYNC... I did some research and came up empty.
I looked at the "reconcile" tf option but that just then wants to download the files.
So does anyone know a magic way to keep Visual Studio happy to show
Latest" Yes ?
03-Nov NB: My context was TFVC
TFS - Sync server to local manually
You could create a new folder to connect the repo, and we do not have to wait until the clone is completed (it will take you a long time), you can choose to cancel:
Then delete the files in the new folder.
Next, copy the latest repo folder from your office VM, then add files to the new folder.
Close your Visual Studio and re-open it, make any change in the projects, then we could sync it to the repo.
Related
I am trying to connect MadCap Flare with our TFS repository.
I have the whole project check in the TFS Server, but when I try to import the project from the "Source Control Explorer" in MadCap Flare
I get this error:
Local workspace detected - MadCap Flare only supports server
workspaces. Please contact your system administrator to help resolve
the issue.
After that, I created a server workspace through Visual Studio but I still get same error.
Try moving the project on your local disk to another folder temporarily. Then import the project via Flare to a new empty folder on your computer.
The change you need to make is actually in Visual Studio. In the workspace settings under advanced there is a setting that allows for local or server workspace. You want to make sure you are using server and public.
This relates to question,
TFS checkin error - could not find file
"When checking in my project I get the error:
Could not find file 'C\blah blah blah'.
I have a feeling this might be a file from an old project I deleted.
I have tried deleting my TFS connection and workspaces.
The Solution was:
This will happen when TFS has some changes staged that no longer exist on the file system. For instance, if you add some files in Visual Studio (which adds them to the changes list), delete them directly from the file system, then attempt to check in the changes, it will complain that it could not find the file(s).
To remove these changes from the list, you can open Source Control Explorer (View > Other Windows > Source Control Explorer) and either Delete the nonexistent files or right-click on the offending files and Undo Pending Changes.
You can also undo these specific changes from the Pending Changes panel in Team Explorer.
Follow up Question:
So my question is,
how do I conduct the equivalent of this in the TFS Server? It continuously happens multiple times on our team.
This works on a person's desktop, but whats the equivalent commandline in the TFS server, and can I incorporate this in my build steps?
You delete files from TFS in the wrong way. the TFS server doesn't know your local file system, if you deleted a file from your local folder the file still exists on TFS.
This is the reason for the issues and errors. if a developer wants to delete a file and he deleted the file from the local folder and then got the error Could not find file and to solve it he does "Undo pending changes" so the file still exists on TFS and when another developer see the file in his system he also deleted it locally and he also will get the error in the check-in.
So, if a developer wants to delete a file from TFS he needs to right-click on the file and "Delete" and "check-in". if he already deleted it locally he can do the "delete nonexistent files" and "check-in". now each developer when he does "Get latest" not will get the file.
You can also delete files with a tf.exe command line in the delete command:
tf delete [/lock:(none|checkin|checkout)] [/recursive] [/login:username,[password]] itemspec
During the build, you can add a command line/Power Shell task and run the tf.exe.
You can undo another person's changes from the commandline using:
tf vc undo /workspace:workspacename;owner $/project/path/to/file
You can get this information by calling:
tf vc status $/project/path/to/file /user:*
This allows you to remove pending changes from the server, though it won't cause the files to be reverted on the workstation of the developer in question.
Both commands offer a /recursive option to undo multiple files under a specific path at once.
If you're using Visual Studio 2015 or earlier, then you can use the TFS Power Tools to add a "Find by status" option to the Visual Studio Source Control Explorer. This has unfortunately not made it into Visual Studio 2017 and there are no TFS Power Tools for Visual Studio 2017.
The TFS Sidekicks offer a Status Sidekick screen, which allows you to query all files currently checked out for edit in server workspaces and allow you to undo them centrally.
Preventing the issue altogether
To prevent the issue altogether you have a few options. You can switch to Local workspaces, instead of server workspaces. Those auto-detect local changes and don't register changes on the TFS server itself. Read more about local workspaces.
You can perform the deletes from the tf vc command line instead of using other tools to delete files and folders, for example:
tf vc delete $/project/path/to/file
The delete command also has a /recursive option. Using this command will not only update your local folder, but will also update the server workspace.
Here is the use-case. There is a very large file in the TFS branch, let's say it is 50GB. When I try to get this specific file with a command line similar to this:
tf get $/Branch/very-large-file.dat
The operation fails because the required time for the download is larger than the time a VPN would stay connected and of-course TFS is behind a VPN. This is why I have download the file manually using a different approach. Problem is that once the file is in place in my local directory and I check which files need to be updated with the following command:
tf get $/Branch/ /recursive /preview
I see that the very-large-file.dat will be downloaded from TFS. And if I go again with:
tf get $/Branch/very-large-file.dat
This will just create the partial file in the directory and start downloading the file from scratch.
Is there a way to update the local version table on the server, so that TFS knows that I have the file locally without having to download it?
In TFS 2012 lcoal workspaces were added, in which case TFS will recognize the file and will compare it to the server version. In 2010 and earlier, the server will keep a list of files on your workspace stored on the server at all times, which will say that you didn't download the file. The server workspace is also cached on your client. I don't know of a way to tell TFS from the commandline or another simple way the file is up to date.
As a workaround you could 'cloak' the large file to tell TFS you don't want to download it at all.
I am trying to modify my project so that on build it queries for the current TFS changeset for the local directory and uses that to form the build number (using http://florent.clairambault.fr/insert-svn-version-and-build-number-in-your-c-assemblyinfo-file as a reference).
Since we currently are not using team build or any continuous integration for this particular project at this time I plan to use:
tf history . /r /noprompt /stopafter:1 /version:W
However, when I test this command out using the visual studio command prompt in my project's directly (where I work from TFS) it claims:
There is no working folder mapping for xxxxxxxx
The folder is shown as mapped in my workspaces in Visual Studio's Source Control Explorer (shows as the local path), and when I edit my workspace.
Why is the command line utility claiming there is no working folder when it is?
You will see this error message if you are using Visual Studio 2012 (and the corresponding Team Explorer 2012 client) and you are using tf.exe from Team Explorer 2010.
TFS 2010 clients store their local workspace cache in a different location on-disk than TFS 2012 clients. Thus, if you are to create a workspace with a TFS 2012 client, the TFS 2010 client cannot see that workspace data until it has connected to the server and populated its own local client cache.
It sounds like you're okay with using the TFS 2012 version of tf.exe, so I would make sure that your PATH contains an entry to that one first, and this should resolve your problem.
If you really wanted interoperability between the two versions, you would need to make sure to connect to your TFS server from both clients in order to make sure the workspace cache was complete for both. However make sure that you are using only server workspaces in this case, as TFS 2010 cannot connect to a TFS 2012 local workspace.
I just signed up for Team Foundation Services Cloud Service since I've failed to implement TFS on my server and local machine. I want to change the source provider from the previous TFS system I abandoned to the new cloud one. It still refers to the old one. I've gone through all the options available, including running a program off of CodePlex that will remove source control bindings. For some reason, it refuses to allow me to unmap my source control from the old server and bind it to the new TFS cloud service. Why?
EDIT: I noticed there are some invisible .SUO files in my project directories. Is this where TFS 2012 stores it's settings? I deleted these files and somehow I was able to map my source to the new server. There were work spaces that appeared when I ran TFS from the command line that didn't appear in the in VS.
I tried everything including uninstalling TFS server locally and removing all traces of the old server connection info on my system and I still couldn't get it to switch to another server. It was like a pit bull that wouldn't let go. I had the taught that Microsoft wanted to make their TFS look less cluttered by hiding its ugly plumbing in invisible folders like Git and Mercurial. Sure enough, there were SUO files hidden in my directory and subfolders. I recursively deleted all them and was able to connect to the new server.
The following command should recursively remove all hidden SUO files from your solution folder:
del /S /A:H *.suo