TF output not conducive to efficient use from scripting

Our builds are heavily scripted. TF seems to output extraneous information which causes us to have to do unnecessary string parsing. For instance, in over SCM tools usually there is a very easy way to get just the items in a directory that are under version control. But in TFVC, if the best I can do is this:

tf dir C:\proj\somedir

but then I get this output to deal with:
--------------
$/Proj/somedir
foo.cs
bar.cs
baz.cs

3 item(s)
--------------
So I have to lop off one line from the beginning and 2 lines from the end. And sometimes it is 3 lines from the end because of an occasional extra blank line after "# item(s)". What a PITA! How about providing an equivalent of "tf ls" that just outputs the item names and nothing more. Or perhaps just a /quiet option. This make life much easier for those who need to script TF commands.

Another issue is errors. They tend to span multiple lines making it harder to grep them out of a log file.

What would be really cool is a set of MSH cmdlets for TF version control. I've been using MSH for a while now and I like that shell a lot.

Answer this question

TF output not conducive to efficient use from scripting

Francois Tanguay
Are you able to just use the .NET object model instead of the commands I was under the impression that the object model was supposed to expose the same functionality as the other commands and that all tf.exe did was to call that object model.

--Oren
Marius Bancila
Doh! You've caught me. This is my form of WSYP - We Share Your Pain. Or from my point of view, the team can share my pain. :-) It's a cute video if you haven't seen it:

http://www.microsoft.com/uk/technet/itsshowtime/sessionh.aspx videoid=9999
Xinwei Hong - MSFT
Unfortunately I'm the only one on my team that has moved over to the Microsoft Shell (MSH). So I had to create the tfgrep functionality in both MSH and KornShell. Since KornShell isn't capable of making direct .NET calls, I'd have to write some C# console apps to wrap the .NET object model to my liking. I haven't looked at the object model but I imagine this wouldn't be terribly difficult. It just seems a shame to have to recreate the TF CLI.
azzurrapoint
At the risk of beating a dead horse, the tf dir /recursive output *really* sucks for scripting e.g.:

! tf dir /recursive
$/Foo/Main/Src/COM:
$stuff
automation.c
variantutils.c

$/Foo/Main/Src/COM/stuff:
ClassTemplate.c

4 item(s)

Here's what it needs to be in order to be easily scriptable (probably would want to display this way with a -terse or -quiet option):

$/Foo/Main/Src/COM/automatic.c
$/Foo/Main/Src/COM/variantutils.c
$/Foo/Main/Src/COM/stuff/ClassTemplate.c

The use case is that we typically have handy scripts like a grep script (mine's called tfgrep.msh) that walks all checked in files and greps for a string. This is very handy but kind of a pain to write using the current "verbose" output of the TF commands. BTW I was using tf properties to see if the file was binary in order to skip the file but that really slowed the script down. It might be nice if "tf dir" had a way to include/exclude certain encoding types. There now, I think I can let this go until at least the first beta of TFVC V2. :-)
Angela Bodnar
Makes me glad we just use blogs and forums. ;-)

Buck
Brian MCSD
Yes, I think you've mentioned this before. :-)

I'm sure we'll look at adding another option in v2.

James Manning has started experimenting with MSH support for TF version control.
http://blogs.msdn.com/jmanning

Buck
TF output not conducive to efficient use from scripting

Answer this question