This question is asking, "Am I doing something wrong," or "Is this a failure in VS2010 and TFS?"
Whenever I open Visual Studio 2010, I habitually do a "GetLatest" from TFS, and often have it overwrite my local files whether they are updated or not just to be safe. I want to make sure that any code I publish has the latest updates from other team members. Then we all check in our changes as soon as possible in order to stay in sync, as the entire team uses this practice.
What we are finding is that when NEW code is checked in (e.g. a new aspx with code-behind) doing a GetLatest will NOT grab the new files. All we get are updates to files that already exist in our local working directory. Are we doing something wrong? Is there a checkbox we need to tick somewhere to force VS 2010 to get files that are new rather than just update existing changes?
This is quite common and is the result of your local workspace getting out of sync. If it happens a lot you should delete the local TFS cache. That's in %profile%\local\Microsoft\teamfoundation*.
The best way to completely eradicate the issue is to upgrade to a newer version. This was resolved with Local Workspaces in 2012 and with Git in 2013. Its pretty strate forward to upgrade.
Related
I have a couple of ASP.NET Core based projects being developed using Visual Studio 2019.
I am having issues where my workspace and TFS server on Azure-DevOps are out of sync. My PC contains the most recent code and I want to push everything I have on the server. I don't really care about the status of the TFS server as it is wrong. I just want to force everything to get pushed to ensure my PC and TFS are syncing again.
How can I force the TFS on Azure-DevOps to take all my files? I don't even mind removing the project altogether from Azure-DevOps and push all files as if this is a new project.
According to your description, sounds like there is something wrong with your source control binding. Or maybe some files outside of Visual Studio do not detect by TFS server. Which cause your workspace and TFS server out of sync.
If you want TFS server detect changes done to files outside of Visual Studio, the simplest way is using local workspace.
Now anything else changes files outside Visual Studio, your workspace detects the changes automatically.
It also detects adds or deletes but you have to include them to your Pending Changes manually with the link under `Excluded Changes
If you are using server workspace, this is kind like when you are offline, you cannot work with your local files because they are read-only until you check them out. So highly recommend you switch to local workspace, you just need to make sure you open the files in VS from a path which the same as your TFS local worksapce. Then it will auto sync changes in Visual Studio and show in pending changes.
More detailed information on the pros and cons of local and server workspaces, please refer our official link.
Now in your situation, we suggest you fist back up all of your local codes/files first. Then delete your old workspace, create a new local workspace.
Get latest from your sever, then copy all your back up to your workspace folder. Then let windows file system auto detect the difference between them, replace files download from server with your back up local version.
Now your local workspace should contain the latest version of your code/file, Visual Studio will auto detect the changes and list them in pending changes, if something added in excluded list, manually promote them.
Finally you could just check in/push all pending changes to TFS server. Now everything back to the track again.
Hope this helps.
Me - Front End web developer with an ok working knowledge of writing VB.NET code but I have never built a .NET project from scratch using Visual Studio.
External developer - Experienced VB.NET developer but completely new to version control and TFS. Also extremely cheap and prone to infuriatingly poor programming practices. He does things that make you bang your head on the table.
Background
Our external developer has coded our site but over the last few years I have been tweaking aspects of pages and have managed to learn quite a bit of VB.NET along the way. He has never used source control and I don't think he's ever had to work with another developer before.
Up until now he has maintained a local copy of the website. He makes changes to this local copy and when he wants us to test it he uploads the relevant files to our dev server. I have no experience of Visual Studio projects/solutions so if I have made tweaks to things I have edited the aspx/asxh/config files in my preferred editor and then uploaded them to the dev server. If everything works correctly I ask him to download them from the server so he can update his local copy.
I have been maintaining a local git repository of the website for the last 2 years. If he makes a change I check it in.
Obviously this is a nightmare to work with so we have now insisted that he starts using version control. I recommended GIT but he has decided to use TFS.
He has now put his solution and all the files into TFS. I have installed Visual Studio 2015 and successfully connected to TFS. I have mapped the files from source control to my own workspace but I am now at a loss as to what to do next.
Questions
As soon as I open the .sln file he has uploaded it says I have checked out the file and made changes. When I check the diff it seems to be because I am using a newer version of Visual Studio than he is. Does the .sln file need to be in version control? Or are we suppose to maintain our own versions of the .sln file and simply check in everything else?
If I try and build the project it fails because the web.config is set up for his machine and not mine. How can we maintain 3 versions of the web.config file? One for my local, one for his, and one for our dev/live environments?
I am not convinced he will have added the project to TFS correctly because he's never used it before. This is basically the blind leading the blind.
Question 1:
You need to put the .sln file in version control. Before check out the .sln file, please do a "get latest" step, which will make sure both of you are working on the latest version. When you try to check your local version in the server, and he had uploaded his local version in the server. You may have to solve conflicts before the check in.
Question 2:
You should build your project and published the website on the server. The build agent will only maintain one version of the web.config file. If he has built the project with his web.config. And you want to build the project again with your web.config, the build agent will delete the previous web.config and pull down your version. Then build the project with your's web.config.
Moreover, if both of you are not similar with TFS. Suggest you taking a look at below MSDN link which related to source control and build.
Use Team Foundation Version Control
TFS Vnext Build
I'm using both TFS 2008 and 2010, and I thought that when you check in a file that is unchanged, TFS should automatically determine that there were no changes, and undo the change instead of creating a new changeset for it.
To test this, I am simply checking out any single file in my solution (e.g. web.config). I then (without making any changes) check it back in immediately. I view the history of the file and see there's a new changeset for it. When I compare that file to the previous version, it says "The files are identical".
I thought it wasn't supposed to create a new changeset since the file wasn't changed. I thought this is the way it is supposed to work, and I also thought this is the way it used to work for me. Am I mistaken? Does anyone have an ideas on how I can fix this?
It will if you are using local workspaces but not for server workspaces. Local workspaces were introduced in TFS 2012 with VS 2012 and are not comparable with previous versions.
I have note used 2010 let alone 2008 in a few years, however if I remember correctly you are explicitly saying that you want to check out the entire solution and then check in. In a server workspce, to improve performance on potentially large codebases it does not do those checks.
I have determined what was causing my issue. My organization recently enabled the Local Security Policy setting "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" on all computers. Apparently, VS/TFS 2008 and 2010 don't exactly handle this setting too well, and the check in/comparison of files was one place where it caused a conflict.
By design, VS 2008 and VS 2010 should only commit files that have indeed changed. If a file is pending but has not been actually modified, it should undo the checkout when you tell it to check the file in. But, when the FIPS setting is enabled, it seems to commit the file no matter what.
To resolve the issue, you need to disable the FIPS setting and also restart Visual Studio.
The setup:
My team has chosen the migration method of a TFS 2010 to 2013 upgrade: take DB backups of existing instances (using the TFSBackup tool), copy to new servers, restore to new SQL instances (with TFSRestore tool) and install TFS on new app/build tiers with the 'Upgrade' option.
Further context:
I have VS 2010, 2012 and 2013 installed side-by-side on my workstation. I typically don't operate more than one flavor at the same time. And, thus far, I use the same private workspace/mappings in all of them. And depending on what new instance of TFS 2013 upgrade I'm pointing to, the workspace is associated with the correct server value.
What the...?:
The current dress rehearsal went relatively smooth. Post-upgrade, we've encountered no issues with opening/manipulating projects, checking-in files, running team builds, etc. Projects act, as before, like they are bound to source control. However, upon inspecting the *.sln files, the "SccTeamFoundationServer" value is still set to:
http://<oldServer>:8080/tfs/DefaultCollection
...And yet, it continues to operate as if that didn't matter. In fact, looking in the "Change Source Control" dialog, the bindings look quite correct, pointing to the newer instance...
http://<newServer>:8080/tfs/DefaultCollection
Question:
This is a rather curious state the solution files are in now. Can they continue this way if they stay within TFS? Or would it behoove us to have project owners change their project bindings accordingly? Keep in mind, we're talking nearly 1000 project solutions.
And, of course, if one merely unbinds and rebinds to source control, they're going to get the wrong server value unless they first update the proper SccTeamFoundationServer value in the *.sln file by hand.
It seems that when I use a tool (such as winmerge) to update my codebase... my Visual Studio Team System (VSTS) integration with Team Foundation Server (TFS) doesn't seem to pick it up.
How do I know which files to check out and check back in? Is there something I am missing? Is this a feature that isn't part of VSTS & TFS?
First, this is probably because the files have not yet been checked out. If you do that first before running your update, TFS will see those changes.
Second, you can use TFS Power Tools (available from MS) to review local repository for changes that are not recognized. If there are found differences, power toys resets the status of the file so Pending Changes window sees the change. this does not require you to check-out the files, it will do that for you if there are differences.
Pretty nifty.
Power Tools for 2008 is here: http://www.microsoft.com/en-us/download/details.aspx?id=15836
and you are looking for the "Online" command:
"Online Command - Use the online command to create pending edits on writable files that do not have pending edits."
I assume you are applying changes across an entire project, outside of VS.
You will have to check-out the complete project first, then apply the changes and check back in. Unmodified files will not be actually checked-in, AFAIK.
Your question sound like as if you have not installed the Team Foundation Server Client.
If you have installed the Visual Studio Team System edition you are able to connect with the Team Foundation Server. But to have the integration working you need to install the Team Foundation Server Client as well.
After having done this your Visual Studio should inform you in case of file changes and then automatically check out the files.