This is not a duplicate of an existing and answered question, like this one.
It is well known that VS pending files list shows all checked-out files, some of them might have no edits at all. And the recommended solution to remove those files without an edit is to run a TFS Power Tools command, as answered here.
However, this doesn't apply to the files that were changed (by a mistake, or on a purpose), but the change was manually reverted. In other words, if the content of two files is binary (or literally) the same, the "Undo Unchanged" command might still think the file has changed and does not remove it from the list.
Is there any way to force TFS PT to perform content-based comparison for pending files vs. latest server version?
Use local workspaces instead of server workspaces (on VS/TFS 2012 or later). With local workspaces, the only things that show up in the "Pending Changes" window are actual modified files.
Related
I'm currently going through checking in changes I have made to my code. There are well over 100 files which have been changed, and I am repetitively getting this error for various files.
Could not find file '[File Path]'.
While I can understand the reasoning for the error, and I know on how I can fix it, how would I display all files which are throwing this type of error when checking in? Consider it to resolving merge conflicts, you would be given a list of files which require attention, you can easily see multiple and deal with them. Unfortunately while checking in changes, it only displays on error at a time.
The current process I am going through is Check In > Error Thrown > Fix Error and repeat. It would be so much more faster to be able to see all affected files and deal with them unlike the way I am currently doing.
I am using TFS 2015 on Visual Studio 2017 Enterprise.
Thanks in advance.
There isn't a good solution (at least not one I'm aware of) to the problem you are facing. Typically in these situations, I recommend to people to backup your changes to another folder and undo your changes in your working copy. From there copy back in the files you care about and if you renamed or delete files, make sure you do it through Visual Studio in either the solution explorer (provided your solution is correctly connected to version control) or in the source control explorer.
Another option is to try and reconcile the changes in source control explorer. You can use the tf command line tool to get a list of pending changes. Running tf status at the root of your workspace will give you a list of pending changes. You can then compare the output with what you have locally in the file explorer. Any files that need to be renamed or deleted should be done in the source control explorer.
As a side note, when using TFVC you should always do all of your rename and deletes through source control explorer to avoid this issue. Also, try to limit the number of changes you make between commits. Having over 100 files changed in one commit will quickly get you into a situation like you are in. Smaller, incremental commits are always preferred over large sweeping changes.
We are using Visual Studio 2013 with Team Foundation Server 2012. We are using local workspaces. We are just moving from another source control program (StarTeam) to TFS.
One of the big things we are missing from StarTeam is the ability to customize our view, and specifically a view of all the local non-current files. Our projects are enormous with multiple directories and sub-directories. If one or more files within a directory is out of date the primary folder in TFS still shows Yes under Latest. This makes some of our users think they are up-to-date when they are not. In StarTeam we could show all descendants and filter to our hearts' content - based on status, size, location, locked or not, who last changed it, who created it, the check-in comments, dates, times, etc., etc.
The closest thing we've found in TFS is to right-click on the main branch and select Compare. This almost does what we want, but it has very limited ability to filter and it takes forever.
I tried the Diff All Files extension but that brings up a separate compare window for each different file with the actual differences highlighted.
I have Beyond Compare set up as the compare/merge tool in Visual Studio but that works only for files, not folders/branches.
Is there any native functionality that can do this? Or an extension? Or a way to set the external compare tool to compare folders as well as files? Or a way to get the primary folder to show No under Latest if any files in that folder have changed? We have a lot of frustrated users and for some reason they're all coming to me.
Thanks in advance.
I can suggest you an external tool:
Diff All Files for VS2013
"Quickly compare changes to all files in a TFS shelveset, changeset, or with pending changes."
Seems what you need.
We have multiple developers on our team. This works for everyone except one developer, but we cannot seem to find the reason it does not work for this individual. We all have VS premium+, TFS 2012 power tools installed.
We have a branch. We get latest version from branch. Go to windows explorer and delete all files in folder "sdk" (there exist no subdirectories in sdk/). Then we copy into it a bunch of files. (This effectively leaves some files as new files, updated files, identical files or removed files when compared with what was deleted.)
When we go to pending changes, these changes show up under "Excluded Changes - Add(s) 51, Deletes(3)".
Except for one developer. His system does not recognize these changes. What might cause this to not work for him?
If it helps troubleshoot, he is also the only developer that if he were to delete these files via power tools delete option in windows explorer, his .dll files get locked. This does not happen for anyone else either.
This is what we've checked so far:
EDIT: Solution Found - Thank you all for the responses! It was indeed the local vs server workspace option. Setting his workspace to local solved these and a few other issue he was apparently having.
Make sure that the developer is using a "Local Workspace" as opposed to the "Server Workspace".
This is a concept which was introduced in TFS 2012 which helps developers to work offline as opposed to server workspace in earlier versions which did not allow that. TFS 2012 changes up the workspace options. Server workspaces are still available, and work exactly has they have in previous versions. However, TFS 2012 now contains a new type of workspace, called a Local workspace. Again, this is an oversimplification, but in a Local workspace, all the files are read/write, not read-only. The meta-data about the files is stored in a hidden folder in the root of the workspace, which allows edits, renames and deletes to be done locally without any communication to the server.
This improves the offline story with TFS significantly, as you no longer encounter issues with editing read-only files. It also makes it easier to work with other tools (such as Notepad) to edit code files. Making a change to a code file using Notepad will still mark that file as edited, which will be picked up by TFS the next time you connect.
LINK
This only ever happens when a user tampers with a local view of source control (be it a local workspace, or not). If all you ever did was get latest from TFS this would never occur, instead, the local view of what is in TFS would always be properly managed.
Also sounds like a bad merge, e.g. getting latest (where the files no longer exist) then copying in old content (introducing untracked files.) One thing you might try doing to correct the issue is doing a forced fetch from TFS after deleting the local workspace contents BEFORE attempting a merge. This will ensure that the local workspace is up to date an accurate with what the TFS server believes is truth, if it still occurs after merging in content then the problem is almost certainly within the merge process the user is going through (i.e. PEBKAC, or a knowledge gap about what they are doing.)
If you unshelve old content (pre-deletion) into the local workspace (where the deletions have already been performed, according to the SCC, and thus locally because of a sync/get-latest) then the unshelved files will effectively become untracked and it's up to the user to clean up the mess. This is identical to a user having copied loose files into their workspace that TFS never had any knowledge of. TFS isn't going to prune untracked files for you, I believe some other source control tools might do this as a configurable default, TFS does not.
That this is only happening to one developer in the team suggests that the other developers, one at a time, should sit with this developer and drive using "their process" to see if it still occurs for them. More often than not this comes down to a bad process a user has adopted, and putting a different person in the chair can help highlight why it has been occurring and help end it. A disciplined build/source manager and/or developer should not experience this problem.
Very interested in knowing what the problem turns out to be.
I've got a file managed by Visual Sourcesafe 2005 which I have edited. I'd like to check in the file exactly as-is on my box, but VSS always merges it with the file in the repository, breaking my code.
I don't know what I expected to happen...
Is there any way to check the file in without merge shy of deleting the existing file from the repo and adding my copy back in?
I've looked for command line options to no avail.
You could just do "Undo check out" for all files, keeping their local versions on your machine; then again check out this files without getting latest versions from Visual SourceSafe; then check in all of them. In this case history is preserved. You just overwrite latest versions of files without any merge. Seems for me it's what you wanted.
I had the same problem and sorted it out in that way.
I'm putting this answer here, but still really hoping that a better one comes up.
I figured that I can go into the VSS GUI and rename the file to ".old", then add my local file into the repo. It's extremely hacky, but allows me to keep the file history.
Such issue might happen when the file was checked out by multple people and there was a newer version checked in by others after your checkout. (See Four scenarios that merge may be performed #2 of the article for more details.)
I don't see a option in SourceSafe CheckIn command to control that either. If you don't want merge happen, you may exclusively check out the file before editing.
There are some files in my team's solution that almost never need to be checked in. Each one of us has a slightly different version of these files (ex: configuration files pointing to our individual development database or slightly modified app.config). Therefore, these files are permanently present in the pending changes view.
Is it possible to hide these pending changes so we never check them in by mistake?
Here How can I always block checkin of a specific file in TFS are some options named. To not see your changes, you should follow the workspace approach.