Alguém mexeu no meu check-out
Temos tido algumas experiências não muito divertidas com o controle de versão do TFS aqui na FórumAccess. Elas se devem basicamente ao fato de que antes usávamos o Visual SourceSafe (VSS). Não, não é um problema de migração. Aliás, se você tem um repositório no SourceSafe e pretende migrar para o TFS, fique tranqüilo: a conversão é possível e você mantém todo o histórico do VSS. Na verdade, a diferença é cultural. O problema deve-se ao fato que check-out no VSS e no TFS não significam a mesma coisa!
-
No VSS, podemos dizer que check-out significa “baixe a última versão disponível do arquivo, coloque uma trava no servidor para evitar outros check-outs desse arquivo e altere-o de somente-leitura para leitura-gravação no meu computador”. Ufa! Quanta coisa num comando só!
-
Já no TFS, check-out significa simplesmente “avise aos outros que estou editando este arquivo”. Viu que diferença?
O ponto de maior destaque aqui é que o TFS não faz um “Get Latest Version” no momento do check-out, em oposição ao modelo do VSS. Por conta disso tivemos algumas discussões acaloradas aqui na empresa. Alguns desenvolvedores chegaram a chamar a ferramenta de “burra”: “Oras”, disseram, “se estou fazendo check-out é porque quero editar o arquivo. Se quero editar o arquivo, é claro que quero a última versão!!!” Pode parecer óbvio assim, mas na verdade não é. Se você pensar uma segunda vez a respeito disso, vai ver que o TFS é mais inteligente do que alguns imaginam… ;-) Acompanhe meu raciocínio. Quando você baixa uma versão de um projeto do controle de versão, está na verdade pegando um conjunto de artefatos interligados e interdependentes. Todos os arquivos devem estar no mesmo estágio de desenvolvimento para que seja possível compilar sua solução. Assim, se você baixa um projeto inteiro e depois de dois dias faz check-out para alterar um dado arquivo, pode ser que esse mesmo arquivo tenha sido modificado por alguém nesse intervalo de dias. Se a ferramenta fizer um Get Latest Version, você irá receber um arquivo que não está no mesmo estágio de desenvolvimento que o restante na sua máquina. As alterações incluídas pelo outro desenvolvedor podem quebrar seu build. Por isso, faz sentido integrar suas alterações com as demais feitas pelo resto da equipe apenas quando elas estiverem prontas. Enquanto isso, você tem uma versão estável do código-fonte, mesmo que os outros estejam fazendo check-in de seus trabalhos.
-
Tags:
- DevOps
- Version Control
31/05/2006 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 2 mins.
