TFS + TFS MSSCCI Provider + Branch = Confusão!

Inúmeras vezes já mencionei o TFS MSSCCI Provider e os benefícios de obter integração com seu IDE preferido, sem ficar limitado ao VS 2005. Já publiquei até artigos a respeito. Porém, recentemente passamos por uma situação curiosa aqui na Fórum Access que gostaria de compartilhar com vocês. Imagine o seguinte cenário:

1. Um usuário tem uma solução VS.NET 2003 sob controle de versão no TFS, na pasta $/teamproject/trunk/src/solution;
2. Seu workspace está configurado da seguinte forma: $/teamproject -> c:projectsteamproject
3. Esse usuário cria um branch de $/teamproject/trunk/src em $/teamproject/branches/b1/src (usando o Team Explorer; ainda não é possível fazer isso através do MSSCCI provider);
4. A seguir, esse mesmo usuário abre o VS.NET 2003 e tenta abrir c:projectsteamprojectbranchesb1solutionsolution.sln
5. Tudo fica muito confuso. Ele não sabe mais se as alterações estão ocorrendo no branch ou no trunk. Isso acontece porque:
6. Quando o VS.NET 2003 tenta abria a solução, percebe que as configurações de integração com o TFS (“source control binding”) estão erradas. Isso porque originalmente a solução estava no diretório local c:projectsteamprojecttrunksrcsolution (que, devido à configuração do workspace, corresponde a $/teamproject/trunk/src/solution) e agora está em c:projectsteamprojectbranchesb1srcsolution (que, também devido à configuração do workspace, corresponde a $/teamproject/branches/b1/src/solution). Como os caminhos não estão mais consistentes, pede ao usuário que corrija;

7. O usuário abre a caixa de diálogo Change Source Control (no menu File

   Source Control) e o botão Browse (que permitiria indicar qual o diretório correto, efetivamente corrijindo o mapeamento do workspace) está desabilitado;

8. O usuário desvincula (“unbind”) e revincula (“bind”) a solução, na esperança de que isso forçaria a exibição de uma caixa de diálogo que permitiria indicar o diretório correto, corrigindo assim a configuração da solução. Porém, alguns instantes após clicar em Bind o Visual Studio indica que o binding é válido (não aparece nenhuma caixa de diálogo) - parece que o Visual Studio (na verdade, o provedor TFS MSSCCI) foi esperto o suficiente para corrigir sozinho o caminho do mapeamento, tomando por base o diretório onde se encontra a solução;
9. Finalmente, o usuário descobre que a solução ainda aponta para o trunk e não para o branch. Isso acontece porque o provedor TFS MSSCCI resolveu o problema com a seguinte lógica:
10. • Usuário abriu a solução a partir de c:projectsteamprojectbranchesb1solution;
      • As informações sobre o binding do controle de versão, contidas no arquivo .sln da solução, indicam que ela está ligada a $/teamproject/trunk/src/solution. (Era de se esperar, pois esse era o valor presente no arquivo no momento em que foi feito o branch);
      • O provedor TFS MSSCCI, ao invés de corrigir as informações de binding, baseando-se no diretório a partir do qual a solução foi aberta, cria um novo mapeamento no workspace, acreditando que o diretório da solução foi movido ao invés de perceber que é um branch. A Microsoft já identificou o comportamento mencionado acima como um bug e o time de produto já está trabalhando numa correção. Avisarei assim que souber de alguma novidade. Nesse meio-tempo, você deverá editar todos os arquivos .sln e .csproj/.vbproj no Bloco de Notas, corrigindo manualmente as informações de binding antes de abrir a solução no VS.NET 2003. IMPORTANTE Ainda que este artigo mencione o VS.NET 2003, o bug é do TFS MSSCCI Provider e, por isso, afeta outros produtos tais como VS.NET 2002 e Visual Basic 6.0.

---

Tags:
• DevOps

---

11/12/2006 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 3 mins.