Equipe de geeks (2: eu e o Luti). Instalamos o Visual Studio 2010 (beta, of course, que geek que se preza não trabalha em software estável), com o Team Foundation Server, e criamos nosso primeiro projeto. Depois de algum estudo do Azure, começamos a codificar. Criamos nossas primeiras classes.
"Editei o ContextoDados.cs. Tenta editar ele aí", diz o Luti. Nem sei de onde ele tirou a idéia de testar o TFS SCC (Source Code Control - o Controle de Código Fonte - do TFS, sucessor do Visual SourceSafe). Bem, fiz aquela cara de ai-meu-saco-tenho-mais-o-que-fazer-e-claro-que-vai-funcionar-tudo, e fui fazer o check-out. "Uai", sai sem querer a exclamação mineira, depois de 20+ anos aqui no DF. "Não é que checkautô?". O Luti faz aquela cara de toma-seu-mané. "Fiz check-in. Altera alguma coisa aê e faz check-in também", ele diz. Eu faço uma alteração e, na hora que tento fazer check-in, aparece uma tela de resolução de conflitos de edição. Auto-Merge, Merge Manually, Changed, Deleted, Next, Previous... Tudo pronto pra causar uma boa confusão. Uai de novo. Isso já não funcionava redondo no Visual SourceSafe?
O TFS SCC vem com duas modificações radicais nas suas configurações default, em relação ao SourceSafe:
- A primeira: check-outs múltiplos são permitidos por default. No VSS, o check-out múltiplo podia ser habilitado, mas o default era check-out simples: somente um desenvolvedor pode travar um dado arquivo para edição. Se outro desenvolvedor tentasse travar o mesmo arquivo (o check-out), ele receberia uma mensagem e não conseguiria editar o arquivo.
Esta até que não chega a ser tão problemática assim. Da primeira vez que houvesse um check-out múltiplo, apareceria a tela de resolução de conflitos de edição, e alguém falaria "Opa! O check-out múltiplo está habilitado". Aí é só desabilitá-lo e tudo ok.
- O problema sério é a segunda modificação. Quando um desenvolvedor faz um check-out, ele *não* recebe a última versão do arquivo armazenada no servidor!!! Isto significa que, se você tem uma versão antiga de um arquivo na sua máquina,e faz check-out deste arquivo, você vai editá-lo sem receber as modificações já feitas por outros desenvolvedores.
Ok, quando você fizer check-in, vão aparecer conflitos para todas estas modificações; mas somente pela quantidade de conflitos caso sua versão seja muito antiga, e pela proximidade do botão "Next", há um grande potencial para que modificações sejam perdidas. De fato, ao pesquisar sobre o assunto, encontrei relatos de equipes que, em apenas algumas semanas de trabalho, já estavam experimentando este tipo de problema.
As configurações default do Visual SourceSafe evitavam estes dois problemas. No VSS, o check-out múltiplo era desabilitado por default, ou seja, só um desenvolvedor pode trabalhar em um arquivo em um determinado momento. E quando você fazia o check-out, você rebebia a última versão do arquivo. Isto podia quebrar a sua compilação local, por o seu código não estar de acordo com as modificações mais recentes feitas no arquivo recebido durante o check-out. Mas isto obrigava você a manter o seu código atualizado. E evitava que seu check-in sobrescrevesse coisas que outros já tinham feito.
Se você, como eu, a torcida do Vascão e a maioria dos desenvolvedores prefere o esquema do VSS, basta abrir o projeto no Team Explorer, fazer duplo-clique no item Source Control, e no menu Team, selecionar a opção Team Projet Settings > Source Control. Em seguida, inverta a seleção de opções:
