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.
Related
Recently I have intalled VisualSVN and TortoiseSVN extensions in my Visual Studio 2015. I have successfully configured Repository and now it is working fine.
I have also configured svn:needs-lock property to my pages. Now, I need to know who is modifying or using the particular file and which is supposed to be committed.
The problem is that there may be multiple developers might be modifying multiple files and Now, I need a list of files which is exclusively checked out by developers. Just like a Pending Changes Explorer in Visual Studio for whole repository. So, where can I get a list of files which are being used same as Visual Source Safe Control?
If you need any information just ask me in comment I will add it.
Thanks!!
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.
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.
We've recently upgraded to Visual Studio 2013 and we're having some issues with the new way publishing is handled. Previously, (in VS 2010) every user had their own local publishing settings, but in VS 2013 it's changed to the idea of shared publish settings. This is causing problems with our environment because every developer has a different local dev environment (paths, connection strings, email addresses to send things to). I realize this is not the optimal way to have things set up, but that's the reality of our situation right now.
We use config transforms to handle the various web.config changes for different developers, so just running through VS doesn't work for us because it doesn't run the transforms. This also causes a problem with the VS 2013 publish settings because the last build config used is stored in the shared publish settings. In order to keep all our settings different, it looks like we're going to need to have a different publish setting for each developer now as well (such as "Local - Erik", "Local - OtherDev"). This is just going further down a path I'd like to get out of eventually.
So my question boils down to: Is it possible to somehow disable the shared profile settings? I thought of just not including them in version control, but then Visual Studio complains that the files are missing on other developers' systems.
Thanks for the help!
You can do this by excluding the profile from the project after you create it. The publish wizard looks for any profile on disk, but newly created ones are added to the project by default. If you then exclude the .pubxml file from the project and remove it from source control, it shouldn't bother you again.
I've searched MSDN and this site (as well as a pile of web searches) and not found anything obvious ... I do see a similar question here about using an existing source control folder -- and the note that TFS apparently stores some project settings there (and thus needs one whether you use it or not).
We're using a non-TFS source control tool -- and I don't want newcomers "accidentally" storing source versions in TFS. So, I'd like to disable the creation of a TFS 2010 source control "tree" when I create a new Team Project in VS 2010.
There may be other solutions to this problem, though, and I'm open to suggestion. For example, if TFS really does need to store some internal data -- how about a way to simply prevent any source code checkins (that is, let TFS use the source control project as needed, but prevent users from adding files)?
TFS has extensive permissions settings.
You should be able restrict check in / access to source tree by permission.