When interacting with TFS from the command line, the tf status command has an undocumented flag named /nodetect. What is it for? What does it do?
My best guess is that it prevents it from trying to be smart about detecting changed files, but I can't seem to verify any change in behaviour when running the command with that flag.
Please check the feedback at website below:
https://github.com/MicrosoftDocs/vsts-docs/issues/292
Steve has mentioned "I've added this to our documentation backlog and
we'll get it updated."
It only looks at files that have been explicitly check out or have been registered as a pending change. It won't look at the stored hashes to detect changed or missing or added files. It's useful for local workspaces, in server workspaces it doesn't add any behavior, as with server workspaces you need to always be explicit about your changes through the checkout/add/move commands.
Related
How do I tell TFS that pending file delete and add is actually a rename ?
For example, I deleted
201505132029594_InitialCreate.cs and tool created
201509141933543_InitialCreate.cs
I'd like to tell TFS that this was a file rename+edit.
Ideally, from command line, something like
tf rename /someswitch 201505132029594_InitialCreate.cs 201509141933543_InitialCreate.cs
Apparently, this functionality exists in the UI (see "To fix the results of an operating system rename"):
https://msdn.microsoft.com/en-us/library/ms181398(v=vs.110).aspx#fix_os_rename
Unfortunately I can't find it (nor can other people apparently)
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/3c909ee5-f6fa-4415-b31c-4822fc30405c/fix-the-outcome-after-you-rename-an-item-in-your-operating-system?forum=tfsversioncontrol
You can rename using the TFS API. In your case, you only need to let TFS know what happened and do not need to change anything on disk. Thus, use the Workspace.PendRename method and specify false for updatedisk.
When checking in files into TFS I sometimes get an 'automatically resolved' message:
No files checked in due to conflicting changes. These conflicting
changes have been automatically resolved. Please try the check-in
again.
I know I can turn off automatic resolution, but I don't mind this being on. However sometimes I want to know exactly what it did to resolve these issues.
Is there a way to get a list of these differences so I can check them before clicking check-in again?
Thanks.
The easiest way I've found to accomplish this is to look at the Output Window, select "Source Control - Team Foundation", and scan the list for all files that were automatically resolved. Then for each file you can view history on the file in question, and look at the recent changes.
Those files are still checked out. If you compare your local version to the server version you should see the diff.
I've got a VS/TFS2010 project in which we use a generated file. Here's how it works:
There's a pre-build event that creates the file (foo.cs)
The file is included in the project.
The file is NEVER added to TFS version control.
It works great, except... People have an unfortunate habit of accidentally checking in the file. This, of course, breaks the system.
Are there any good ways to prevent this from happening? Can I at least set up some kind of watch mechanism to alert me if it does happen?
You'll need to install the Team Foundation Server Power Tools, which will include the "Forbidden Patterns" check-in policy. This will allow you to prohibit a file from being checked in based on regular expression applied to the server path.
This will allow you to simply add the full server path of the file you wish to ensure does not get added. For example:
^\$/TeamProject/Folder/foo\.cs$
I was researching this exact issue today and found this, which may be of some help: How to ignore files/directories in TFS for avoiding them to go to central source repository?
Not sure if 2010 has made this easier or not.
(Apologies, this should probably be a comment, but I don't think I have enough rep to comment.)
We have a rule in TFS that requires all checkins to be associated with a work item. We have an automated daily build process that uses tf.exe to check in the files. However, I did not find any way to associate files with a work item.
I heard of tfpt, and have it installed, however, I did not have any success using it to associate files with a changeset either.
Is there another way to do this?
Thanks!
I'm pretty sure tf.exe / tfpt.exe cannot do this except through their UI. If you need to use the -noprompt parameter for automation then you're likely out of luck.
Luckily, it's not hard to use the API directly. MSDN link. Basically just build up an array of WorkItemCheckinInfo[] and pass it along with your request.
Team Foundation Power Tools has a command for dealing with work items.
tfpt.exe help workitem
The title pretty much says it all.
I'm using a RFT, VS addin that allows me to edit a proprietary data file with a GUI. The problem is that this file doesn't show up in VS and when I start editing it via the GUI, VS doesn't check it out automatically (probably a bug of the VS addin). So, I've to check it out manually before editing it, otherwise the addin will crash when trying to save the file (because it is read-only), and sometimes will also corrupt the local working copy of this project.
Everything would be much easier if TFS didn't mark the file not checked out as read only.
Do you know if there is a way to instruct TFS to keep all the files as not read-only?
No. You can exclude it from source control, but that's probably not want you want.
I have the same issues with TFS. Our project has a few small SQL Server database files that we have chosen to put under source control. We handle the read only issue by adding these to the post build statement on the project build. I suppose we could have done this pre-build as well.
attrib $(TargetDir)*.mdf -r
attrib $(TargetDir)*.ldf -r
It has been a while, but - I think this link is actually the answer to that.
When you do a check out, what you are actually doing is saying “TFS, I
would like to edit the version of the file that I have already
downloaded, is that ok?” TFS then looks at that version, and tells you
if you can edit it or not (based on your security permissions at that
point in time and if anyone else has placed a lock on the file). If
you can edit the file, the TFS marks the file as read/write on your
local machine and allows you to proceed.
I.E: When I r.clicked the project and selected "Check out and edit", the r/o flag was automatically removed, and I could compile (with both pre/post events) and then "check in" again.
Well you can get latest to a samba share, which eats the readonly bit.