Uma das consequências mais interessantes é que não é mais necessário utilizar uma ferramenta integrada ao sistema de controle de versões para que as coisas funcionem bem. Devido ao sistema de arquivos ser o ponto de controle, é possível usar até mesmo o Notepad (ou qualquer outra ferramenta similar), que o TFS funcionará da maneira esperada. A cópia local se torna a principal e o Team Foundation Server sincroniza as mudanças da maneira apropriada.
Note que, para aqueles que preferem um fluxo de trabalho no estilo de sistema de controle de versões distribuído (ex.: git) será necessário aguardar pelo TFS 12.
A seção final do do guia trata das opções para gerenciamento de recursos compartilhados. Com o Visal SourceSafe, recursos compartilhados eram fáceis de lidar. Era possível simplesmente criar vínculos entre diretórios de forma que "$\projects-a\bin\commons" e "$\commons" fossem o mesmo diretório. E, caso necessário, um único comando poderia quebrar este relacionamento.
O TFS não possui essa capacidade, então, ao invés disso, é preciso escolher uma das seguintes opções:
Duplicar os arquivos compartilhados em cada branch. Isto fornece isolamento à custa do espaço em disco desperdiçado;
Manter um diretório compartilhado separado fora dos branches. Este diretório é referênciado no projeto através de paths sugeridos, uma técnica muito suscetível a erros e que funciona apenas para assemblies do .Net;
Usar mapeamento de workspaces para fazer o diretório compartilhado parecer estar dentro de cada branch no disco local. Esta opção é mais versátil do que a de paths sugeridos, mas requer que todos os desenvolvedores configurem os mesmos mapeamentos.