Team Foundation Server and the Future

Team Foundation Server in

Lorenzo Barbieri @ UGIblogs! — Wed, 22 Feb 2006 17:57:02 GMT

Want to influence the next version of TFS? Now is the time!

Buck Hodges — Wed, 22 Feb 2006 18:37:52 GMT

Brian Harry has a new post requesting your input for the next version of TFS.&nbsp; The team has just...

Team Foundation Server and the Future

Rob Caron — Wed, 22 Feb 2006 19:03:17 GMT

As Team Foundation Server packs its bags and prepares to head out the door, we&rsquo;re turning up the...

re: Team Foundation Server and the Future

Keith Hill — Wed, 22 Feb 2006 21:32:21 GMT

Value proposition: Fit & Finish. That is, polish the rough (or missing) edges. There's a lot to like about TFS: robustness, performance especially over the WAN, awesome concurrent development support, etc. However we all realize what happens with V1.0 products - many useful features don't make the cut.

Features: better offline support for developers who use laptops. TFPT is nice but using an unsupported utility is a bit dodgy. I would also like to see Rollback support added. Merge support while unshelving would also be nice to have in the product. A graphical view of branches/changesets is something the internal ClearCase users have brought up as a "missing" feature. I have to admit the graphical view is really useful for quickly internalizing branching structure. The command line also either needs to support piping better in order to interop with other CLI utils OR even better would be to provider MSH (Monad) support for TFS. Metadata support for version controlled items ala Subversion's Property feature would be useful. It would also be useful to have continous integration support built into Team Build. I would also like to see the SharePoint Project portals embrace something like Wikis for editing project documents. I really like the simplicity of HTML for project docs where Word is just too complex (I hate fighting its formatting).

Timeframe: I would say that if Orcas ships late this year or by Q1 2007 then I would like to see a TFS update ship with it. I wouldn't want to wait too much longer for an update that plugs a few of the missing holes in TFVC. If you have big enhancements in mind that wouldn't fit the Orcas timeframe I would suggest a parallel development effort with one team working on adding some of the missing features for later this year and the other team working on the big enhancements for further down the road.

The Future of Team System

Visual Studio Team System (VSTS) Blog — Thu, 23 Feb 2006 00:01:44 GMT

With strategic products it is extemly important to look into the planning and direction for the future......

VSTS Links - 2/23/2006

Team System News — Thu, 23 Feb 2006 18:15:07 GMT

John Lawrence posts their Team Foundation Dogfood Statistics for February.

It's Rob Caron time:
...

Team Foundation Server vNext

notgartner.com: Mitch Denny's Blog — Mon, 27 Feb 2006 04:51:59 GMT

re: Team Foundation Server and the Future

bharry — Mon, 27 Feb 2006 16:30:12 GMT

Sorry it took me a few days Keith. Thanks a lot for the great feedback on both the feature set and the timeframe.

Brian

re: Team Foundation Server and the Future

Chris Kinsman — Thu, 02 Mar 2006 01:49:08 GMT

My thoughts: http://www.vergentsoftware.com/blogs/ckinsman/PermaLink.aspx?guid=ff719f1e-4d7a-4ac8-bb72-fa77fd2c4d4d

The end is really just the beginning - TFS to release in a few weeks

My VSTS Blog — Thu, 02 Mar 2006 08:12:49 GMT

Well the end is in sight with Rob Caron announcing that they will officially launch Team Foundation Server...

TFS vNext

MrDave's (David Yack) Blog! — Fri, 03 Mar 2006 22:18:06 GMT

As the RTM of Team System gets closer and closer Brian Harry posted about Team System and the Future.&nbsp;...

re: Team Foundation Server and the Future

Jerry Nixon — Wed, 08 Mar 2006 21:32:21 GMT

Please be able to Delete WorkItems.
(this is especially relevant with build error work items)

Please add a free text field to a WorkItem called Version.
(this is mostly relevant for ad hoc submissions not using the VS tool)

Please enable simple submission of WorkItem from external sources (for bugs).
(so many security issues today)

Please allow for a WorkItem to be assigned to no-one.
(especially valuable for anonymous bug submission)

Please give WorkItems a comment area that is seperate from the description.
(extremely valuable to not "polute" the initial description)

Please give bug type WorkItems the available status of "Resolved" out-of-the-box.

Please allow the status of WorkItems to be changed many at a time.
(select many and select them as resolved or deleted or whatever, not one at a time)

Thank you in advance for taking suggestions.

re: Team Foundation Server and the Future

bharry — Thu, 09 Mar 2006 16:47:05 GMT

Thank you very much for your feedback Jerry. I have a couple of comments on some of your points...

A few of your requests are for additional fields. We will certainly take that feedback for our default bug forms but I want to make sure you are aware that one of the key features of the system is that you can customize that to your hearts content. You can add, remove or modify fields. There's a tool at: http://www.imaginets.com/Default.aspx?tabid=133 that can help make this easier.

>> Please allow for a WorkItem to be assigned to no-one.
(especially valuable for anonymous bug submission)

The way we handle this internally is we have a special value we call "Active" that we assign all bugs to that are assigned to no one. Also all new bugs are, by default, assigned to Active unless you change it.

>> Please give WorkItems a comment area that is seperate from the description.
(extremely valuable to not "polute" the initial description)

I hear this fairly often (which tells me we haven't done a good job making it clear) but we have this today. In the default MSF Agile bug form there are two data entry fields: Description and History. Description is intended to be a relatively static description of the problem, repro steps, etc. History is a conversation oriented, append-only log of everyone's contribution to understanding and fixing the bug.

>> Please allow the status of WorkItems to be changed many at a time.
(select many and select them as resolved or deleted or whatever, not one at a time)

Another one I hear with some frequency. The way we tell people to do this today is to open the work items in Excel and do your bulk editing there - it's a good tool for it. However, I get this often enough to believe that this is not satisfying to everyone and that some ability to do this in the IDE is desired.

re: Team Foundation Server and the Future

Michael Ruminer — Thu, 16 Mar 2006 02:03:13 GMT

The Future of Team Foundation Server...

re: Team Foundation Server and the Future

mezcaholic — Thu, 16 Mar 2006 19:49:49 GMT

We are evaluating TFS here and I have been gathering some feedback from our Devs. Here are a few things that THEY would like to see addressed:

lack of recursive diff in the GUI

no support for sharing items between projects (Note: no, branch does not do the same thing)

TF does not deal well at all with changes made outside the system. This will be a major problem when updating third party code/libraries in the system.

The "Add to Source Control" dialog shows files that are already in source control. This makes adding a few additional files in a large directory a pain. SourceSafe does this right.

Recursive diffs from the command line take a VERY long time.

Useability and Performance are the key I believe. I really like what TFS has to offer but it needs more gloss. The UI needs to be at LEAST as functional as VSS and a lot of your competition out there is FREE like subversion and cvs et al. So you need to offer functionality/performance equivelant to those products.

An extension for explorer would be nice.

Over all a great product but the details need to be worked out. I think the focus has been from a PM/Dev Manager perspective. Now I think it needs to be looked at it from the developer/configuration manager perspective.

re: Team Foundation Server and the Future

Brian Harry — Fri, 17 Mar 2006 00:27:22 GMT

That's great feedback Michael, thank you.

Brian

re: Team Foundation Server and the Future

Ray Johnson — Wed, 05 Apr 2006 03:11:32 GMT

Features
1) You really should have editors for edit WIT items & workflow. All other bug DBs have something that make that easier. It's going to make adoption much harder if customization is so difficult.

2) The integration with MS Project is a joke. Unless I'm missing something really big there is no way to enter bug dependancy information in VSTS and have it sync with MS project. If a developer finds a dependancy the best place to enter that is in the Bug DB integrated with Studio! You also can't import data from multiple VSTS projects into the same MS project (what developer only works on one project?). The biggest reason to use MS Project (in my mind) is to use it's powerfull abilities for managing dependancies and resource constraints. Hell, I wrote a more powerfull linking between MS Project and ClearQuest with about 2 pages of VBA script. Which is why I find the current level of integration a bit of a joke.

3) Allow for more field types. Where is the bool type? Why can't I add more "path" types (I only get area and interation and can't add a new one)? A "picture" type would be nice as well so you don't have to open an editor to view a screenshot describing some bug.

4) The WIT "Link" type doesn't seem complete to me. I want to know what type of link something is. Does this bug DEPEND ON another bug. Is it a DUPLICATE or perhaps a SEE ALSO type of link? What about PARENT bugs that encapsulate a groups of tasks related to what is still a smallish feature.

5) A web interface. I know there are 3rd party solutions already available - but man isn't VSTS expensive enough already not to be complete?

Timeframe
Shorter is better.

re: Team Foundation Server and the Future

MJones — Mon, 23 Oct 2006 17:08:18 GMT

1) Requirment Traceability. We currently use Requisite Pro to do this, but would prefer to see it in one unified solution.

2) Automated GUI test tool. You have one for the web, but we would like to see one for Winforms. We currently use Robot (another Rational Rose product), but again... we want a single unified solution.

3) Full 64-bit Single server deployment

4) A single managment console that handles VSTS, Sharepoint, SQL Server, Reporting Server, etc.

We would like to see this in next release if possible.

Matt

re: Team Foundation Server and the Future

bharry — Mon, 23 Oct 2006 20:33:44 GMT

Thanks for the feedback. There are some really good ideas here. Some of them are already on our list. I'll add those that aren't.

Brian

re: Team Foundation Server and the Future

MJones — Mon, 30 Oct 2006 16:32:10 GMT

A few more feature requests:

1) Ability to use Source Control without an associated TFS project.

2) The ability to remove projects from Source Control. This means fully delete the project and all associated files from the database.

re: Team Foundation Server and the Future

bharry — Thu, 02 Nov 2006 14:54:54 GMT

What is your goal in using source control without a TFS Team Project? Said another way, what harm is there in creating a Team Project? What are you trying to avoid?

Brian

re: Team Foundation Server and the Future

MJones — Thu, 02 Nov 2006 15:55:05 GMT

There are situations where a version control system is desired without the need of a Sharepoint site. We don't like generating unused clutter on our systems.

re: Team Foundation Server and the Future

robvolk — Tue, 28 Nov 2006 22:53:16 GMT

I second the request to open files from TFS without requiring a project file. A lot of times a "solution" is more of a problem, at best it's nothing but overhead.

For instance, we have shared database code that exists in several app projects, but also needs to be available to DBAs for maintenance purposes. They deal with individual procs, not entire projects, and it's annoying to have to branch or merge code just to access it differently. They also need access through SQL Server Management Studio, and right now that program won't open anything without a solution or project file in the source tree.

Working with individual files was a very easy and natural feature in SourceSafe, I don't know why it was left out of TFS.

On that note, I'd echo the explorer shell support, please look at the Tortoise CVS and SVN tools and just copy them blindly. There's no reason TFS should prevent you from working in this fashion. I also concur about sharing/linking files between projects.

Thanks.

re: Team Foundation Server and the Future

bharry — Sun, 03 Dec 2006 19:48:54 GMT

Rob, I'm not sure I completely understand your feedback. In VS today, you can open files without having a solution file. You can do this from the Source Control Explorer.

Now that said, you may be referring to the fact that if you use File -> Open to open a file, you can't do version control operation, get auto checkout, etc unless that file is in a Project. In VS parlance, these are referred to as "Miscellaneous files". I couldn't agree more that this is annoying (assuming this is what you are saying). We plan to fix that in a future version - I'm checking on what release that is slated for now.

If you are referring to something else, then I'm afraid I missed what you are saying and could use your clarification (perhaps with a scenario).

Thanks for the vote for Windows Explorer integration. That's something we've considered but just haven't gotten around to yet.

Brian

re: Team Foundation Server and the Future

robvolk — Thu, 14 Dec 2006 19:53:04 GMT

Brian-

You nailed it, thanks. My major issue was with the way SQL Management Studio works, it may not be a TFS problem but more how SSMS interfaces with it. I'm finding Data Dude has a similar problem, it has to create its own solution instead of working with an existing one, or just the files in the tree.

Generally, any access to TFS source control without requiring a project or solution is a plus. I admit I've got to play with it more, I'm probably missing some basics that might solve the issue for me.

Thanks again.

Another vote for explorer shell integration!

Matt — Wed, 14 Mar 2007 19:08:10 GMT

I'd really like to see explorer shell integration added. Also, it would be nice if there were an easier way to indicate which editor to use for specific file types.

re: Team Foundation Server and the Future

bharry — Thu, 15 Mar 2007 15:44:59 GMT

Thanks for the feedback. When you say "easier way to indicate which editor to use for specific file types", I assume that's general Visual Studio feedback and not just TFS feedback?

Brian

re: Team Foundation Server and the Future

Mark — Wed, 28 Mar 2007 19:58:55 GMT

After using the amazing tool that is TortoiseSVN, I really miss it with TFS. I have made some very primitive batch scripts that allow me to do most operations by right clicking, but TFS needs proper Explorer shell integration.

In general, I work with files in Explorer. I mean I am looking at the files I want to manipulate, why should I have to goto a separate tool, navigate to the same files, then perform the operation? It really creates a clunky workflow. With TortioseSVN, I always got a warm-fuzzy feeling. With TFS, I get more of a cold-prickly feeling.

re: Team Foundation Server and the Future

bharry — Wed, 28 Mar 2007 20:16:39 GMT

I agree that would be a really great feature. We've got it on our list of things to get to. I'll bump it up a couple of notches on the priority list.

Brian

We are in the future, where is it?

Ross Hedges — Wed, 30 Apr 2008 13:37:00 GMT

The bane of TFS for me is no Windows explorer integration.

How do I and my developers see files not added and how do I and they add them?

Oh yes ... I have to ensure 'Source Control Explorer' has the focus (otherwise the 'Add to Source Control' item is not present), open the 'File' menu, cascade the 'Source Control' item, click the 'Add To Source Control' item, click the 'Add Files...' button in the 'Add to Source Control' dialogue box (after checking the Exclude list), and look ... it's the standard old 'Open' dialogue box, no indication of which files are already in TFS, opened for edit, or not added. I just have to remember!