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.
Related
I have shelved my changes in TFS which will be checked in few days time. Now i want to work on different TFS card which belongs to same file. How can i work on the same file when its changes are not checked in yet ?
How can i work on the same file when its changes are not checked in yet ?
You should use Branch. You can create a new branch based on file are not checked in, then you work on different TFS card with previous branch, after that, you can check out the new branch to work on the same file when its changes are not checked in.
Shelvesets are per-user and differently stored in the source control - it is not possible to merge shelvesets, there's no history etc. The only action possible is unshelving; you cannot even merge files while doing so. So, we only use it as a temporary storage for things that are not finished yet and thus cannot be checked into a branch.
So, you should use branches. Maybe a Main branch and different development branches for features & bug fix.
Hope this helps.
Our projects have configuration files that are checked into source control, essentially as a template, that the developers check out and modify with their local config changes, which shouldn't be checked back in.
Policies are already in place to prevent these local changes from being checked in by accident, but it's still very obnoxious to always have dozens of config files in the Pending Changes view of Team Explorer that I just always have to exclude.
.tfignore only seems to ignore Add operations, not Edits. After some searching I found that some people had success with cloaking the files/folders, but that hasn't worked for me.
The files can't be removed from source control - they exist there for a reason - however I'd really like to not have to see them as pending changes every time I go to check in my work.
Is this even possible?
No, it's not possible.
There isn't a way to ignore detecting the file changes which already been in source control, unless all the developers cloak the configuration files/folders with the workspace mapping, but that seems not available for you case.
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.
I work in Visual Studio on C# project.
I edit some files it that project simultaneously. After some work is done i want to divide all changes to "groups" of changes and commit each group changes to separate commit. Its okay when it comes to files - i include one files, exclude others and all is fine.
But problem appears when some changes are in the single common text file. I'd like to split them to different check-ins by TFS itslf, but as far as i know it is not possible.
So tell me please, is there any way to split changes to distinguish them due development process? For example when i start editing common file i press something button or issue a command. Later, when i have to add changes regarding to another check-in to that file, before these changes are really done, i press another button (another command) and since this moment changes are recording as needed to be commited to another check-in.
I hope you understand what i mean. Sorry for my bad English.
If you are going to make a quick change to a file that has work in progress, you should shelve the changes and revert to the source control version (uncheck the "preserve pending changes" box). Then you can make the changes and check in the file. After that, unshelve your changes (your work in progress) from earlier, VS will merge the changes with your checking and you can carry on.
Since it sounds like you have already made the changes and the file contains code you are ready to check in and code you don't, one thing you can do is to shelve the changes now (but do "preserve pending changes"). Then you can delete any code that aren't ready and check in the file. After check in, you can unshelve your changes.
You might want to consider using branches to isolate your long-running changes; although that has its own set of problems.
You could create another workspace on your computer, and use each workspace for a different task. That way, you can work simultaneously on different tasks on the same file without affecting each-other. When you check-in from one workspace, do a "get latest" on the other workspace and merge the changes there before you check-in the other work.
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.