TFS Powershell cmdlets default to -noprompt

The title kinda says it all.  But as usual, there’s a backstory to tell and some ramifications to warn you about.

First, let’s look back at the legacy tf.exe command line.  In the effort to be both user friendly and flexible, its behavior has actually become quite complicated.  As of TFS 2008, the logic appears to be evaluated in this order of precedence:

  1. If the /prompt flag is present for this command, always use Prompt mode, otherwise
  2. If the /noprompt flag is present for this command, always use Noprompt mode, otherwise
  3. If the tf.exe process’ stdout stream is redirected, use Noprompt mode (unless the environment variable TFS_IGNORESTDOUTREDIRECT is set), otherwise
  4. If executing in script mode with a @command file, use Noprompt mode (unless the most recent invocation of the setnoprompt command was “setnoprompt false”), otherwise
  5. Default to Prompt mode

Yikes.  I’d actually forgotten just how many variables there were until I started running tests for this blog post.  Suffice to say, the Powershell cmdlets approach things in a much simpler way:

  1. If the –prompt switch is present for this cmdlet, always use Prompt mode, otherwise
  2. Default to Noprompt mode

Simple enough.  I know a lot of power users will rejoice at this, having long since resigned themselves to /i muscle memory lest random WinForms interrupt their console workflow.  However, there are ramifications to this behavior that you should be aware of.  “Prompt mode” means more than simply popping up dialogs.  First of all, there are some UI features that are still not accessible in Prompt mode without additional parameters, such as tf diff /configure.  More importantly, leaving Prompt mode turns off a number of safeguards:

  • Undo will permanently discard your local changes.  (I think TFS should use the Recycle Bin, but that’s another show…)
  • Shelve /delete will permanently delete shelvesets.  (The server used to keep them around until a cleanup job ran, but again that’s the way things work now.)
  • Destroy, well, destroys.

These aren’t the only examples; you get the idea.  None of this behavior is new to TFS in general, but with the default settings of the Powershell tool, it’s a lot easier to shoot yourself in the foot.  Even good old Checkin is likely to surprise you the first time you see it simply go without any further interaction.  [a “no blank comments” checkin policy might help here, nudge nudge] 

So have fun, just be careful.  If you’re using the power tools then you are ready to be a power user, right? :)

Leave a Reply