TFVC: Team Project is not identified when workspace is mapped at Team Project Collection root

[eogas]

When working with TFVC, I usually map my workspace at the root of the entire Team Project Collection, then selectively bring in the Team Projects that I'm working in. It looks like the extension doesn't currently support this workflow. Even if I specifically open the child directory where the root of a Team Project is mapped, the extension cannot identify the Team Project name. If I map my workspace one level deeper, at the root of a Team Project instead, everything works as expected.

I don't know if it makes a difference, but this is with an on-prem instance of TFS 2015 with Update 3.

[jeffyoung]

Hi @eogas, thanks for trying out the extension!

Yeah, you've run into a case where we had to decide what to do when we can't get the team project out of the workspace. We felt that most folks would map at least a single folder into their workspace that included the team project so we could parse it from there (and that's what you've seen when you map it one level deeper). If more than one team project is mapped into the workspace, I believe we default to the first we find. However, there's also the case where you can map $/ but that doesn't provide us with the team project name we need (and I believe this is the situation you're in).

In this case, perhaps we should provide a way for you to indicate (perhaps through a setting?) which team project to use. In this case, you would be able to set up a workspace setting for each of your sub-folders that would tell us which team project to use. As you opened each folder (you'd have to open the individual folder for that to work) we'd use that team project. For the root folder where you mapped $/, you'd just have to pick one.

BTW, can you describe how this error manifests itself?

[eogas]

However, there's also the case where you can map $/ but that doesn't provide us with the team project name we need (and I believe this is the situation you're in).

This is correct, I generally just map $/ rather than specific team projects.

As you opened each folder (you'd have to open the individual folder for that to work) we'd use that team project.

Yes, this is the behavior that I expected. So as an example, if I map $/ to c:\dev, and I have a Team Project at $/MyCoolTeamProject subsequently mapped to c:\dev\MyCoolTeamProject, I would expect that opening c:\dev\MyCoolTeamProject in vscode would be enough information for the extension to figure out what Team Project I'm in automatically.

There isn't any error displayed in the editor, it just doesn't recognize the directory as being version controlled. With debug logging turned on, I can see that the extension just isn't resolving the Team Project name. I have lines like this:

2017-04-13T18:56:59.439Z - debug:  [13672] Found a TFVC repository for url: 'http://mytfsserver:8080/tfs/mycoolcollection' and team project: ''.
2017-04-13T18:56:59.448Z - debug:  [13672] Parsing values from repositoryInfo as string url
2017-04-13T18:56:59.448Z - debug:  [13672] TFVC Creating Tfvc object with localPath='undefined'

2017-04-13T18:56:59.760Z - debug:  [13672] Getting team project...  Url: 'http://mytfsserver:8080/tfs/', collection name: 'MyCoolCollection', and project: ''
2017-04-13T18:56:59.865Z - debug:  [13672] Found a team project for url: 'http://mytfsserver:8080/tfs/', collection name: 'MyCoolCollection', and project id: 'undefined'

[MindGirl]

I have the same issue. I mapped the team collection and cloaked all team projects, that I am not interested in. The extension shows the first project as current team project, even if I work in a different one. Modified files outside the workspace root of VS code are displayed as changes.

tf workfold shows the mapped file system path beside the server path, as seen in the following (redacted) output:

=======================================================================================================================
Workspace : WorkspaceName (username)
Collection: http://example.com:8080/tfs/DefaultCollection
 $/: C:\Source
 (cloaked) $/TeamProject1:
 $/TeamProject1/Main: C:\Source\TeamProject1\Main
 (cloaked) $/TeamProject2:
 (cloaked) $/TeamProject3/Development:
 (cloaked) $/TeamProject3/Release:
 $/TeamProject3/Release/Main: C:\Source\TeamProject3\Release\Main
 (cloaked) $/TeamProject4/Development:
 (cloaked) $/TeamProject4/Release:
...

Can you determine the team project by comparing the workspace root (in Visual Studio Code) with the paths shown in the output of tf workfold?

(I am using tf.exe from the path C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundatio n\Team Explorer with TFS 2017.1)

Forgot to mention that I am using Local Workspaces with TFS on-prem.

[jeffyoung]

Thanks @eogas. Interesting idea @MindGirl...

Maybe we really need a combination of the two? If we can't find the team project via workfold, we could try the top-level folder in the opened VS Code workspace. Since you can still map $/TeamProject1 to a folder other than /TeamProject1, if we took the feature this far, we could then check some sort of user-provided setting.

[jeffyoung]

Closing this as a duplicate of #179 (the more active issue).