TFS Conflict Type: Writable File - A writable file by same name exists locally

The Visual Studio 2010 conflict resolution dialog supports multi-select.

If you select the first conflict, hold down Shift then select the last conflict, the "Overwrite Local File or Folder" resolution will be applied to all the selected conflicts.

You can also use the command-line tool tf resolve /auto:OverwriteLocal to resolve the conflicts.

You can do it for whole folder, multiple folders or entire project where conflict files exist.

You need to right click on that specific file/folder, go to Advanced, Select "Get Specific Version..."

Grant's answer is great for how to resolve multiple conflicts.

As for why you have those conflicts, generally speaking, your TFS client has detected that a file exists locally that is not managed by TFS, but you are trying to perform a get operation that would overwrite that file.

If you're following a normal development workflow (and not going and editing files outside of your editor), the most common source of writable conflicts is from shelvesets. If you were to pend an add on a file, then you were to undo that add (either explicitly or because you shelved the change and deselected the preserve pending changes button), the file is not deleted. (This is to prevent data loss - it's not uncommon that you would want to create a file but not have it checked in to source control.)

Now if you (or someone else) were to check in that shelveset (either through creating a build from that shelveset, or from gated check-in, or because your code reviewer checked in your shelveset directly), then when you do a get latest, your TFS client will detect that the file still exists locally and thus, you'll have a writable conflict.

This may not be particularly obvious in the case of gated check-in. How gated check-in actually works is when you try to check in your changes, your check-in is actually converted to a shelveset. The TFS build agent will then try to build your shelveset, and if the build succeeds, it will then check-in that shelveset on your behalf. If the build fails, the shelveset remains and you can unshelve to fix the build errors.

For this reason, it's important to run the build notification application when you're using gated check-in, which will allow you to "reconcile" your changes once they're submitted. Reconciling your check-in will simply do a get of the check-in that was submitted by the build server, but it will avoid conflicts since it understands the context of the changes that are on your local disk. (It will compare the contents on your local disk to the contents on the server.) If you do not choose to reconcile, you will, unfortunately, have writable conflicts on files that were added.

(Note that this scenario will not produce a conflict in the next version of TFS - if there are no content differences, TFS will not produce a conflict.)