Digamos que estou trabalhando em algum tipo de reestruturação extensiva. Para fazer essa reestruturação, eu preciso deixar alguns testes falhando por algum tempo. Eu sei que, quando terminar, os testes vão voltar a passar, mas eu preciso deixa-los quebrados por algum tempo enquanto eu termino. Eu não posso publicar o código para o repositório de código central porque isso atrapalharia os demais desenvolvedores. Faz sentido, entretanto, dividir qualquer reestruturação deste tipo em pequenos objetivos. Portanto, faz sentido fazer checkin de metas parciais. Porém, se o sistema é centralizado, eu não posso fazer isso para não atrapalhar meus colegas.

Enquanto estou fazendo essa reestruturação, pode ser que você precise de algumas modificações que eu fiz. É em horas como essas que o pessoal começa a compartilhar código pela rede, fazer merge manual e usar de uma imaginação incrível para contornar as limitações do sistema. Com controle distribuído, cada desenvolvedor tem um repositório pessoal que, em termos de recursos de versionamento, não deixa nada devendo em relação ao repositório central. Se você precisa das minhas alterações, você simplesmente as importa diretamente do meu repositório. Não precisamos passar pelo repositório central se não quisermos. Desse modo só nós dois precisamos lidar com aqueles testes falhando, e não a equipe toda.

Sobre interface gráficas, este não é um problema inerente à distribuição e pode ser resolvido. Na verdade, eu acredito que já venha sendo resolvido. Eu particularmente não tenho problemas para trabalhar na linha de comando, portanto nem cheguei a procurar esse tipo de front-end. Então não posso dizer com toda a certeza que este problema não existe, mas provavelmente já deve estar bem perto de terminar.

De qualquer modo, se a equipe é pouco capacitada, pode acreditar que a falta de interfaces gráficas é o menor dos problemas.

O controle de versão por patches (e aí não estou necessariamente falando de controle distribuído, como mostra o texto) evita que você precise lembrar quais as modificações que você já tem. Um bom exemplo é quando você está fazendo merges sucessivos, como no caso do branch de desenvolvimento do texto que precisa incorporar as modificações feitas no branch de conserto de bugs. Com controle de patches, você pode derivar uma base de código qualquer, fazer modificações locais e incorporar de tempos em tempos as modificações que sejam feitas no código original sem (tanta) dor de cabeça.

Bem, eu devo ter perdido alguma coisa…

Não há nada impedindo que os sistemas distribuídos de hoje em dia sejam usados de forma centralizada. A equipe pode muito bem escolher um local para chamar de central e oficial, mas elas não são obrigadas. A questão é que há limitações que os sistemas centralizados têm que os distribuídos não têm. Não manter histórico das alterações das cópias de trabalho locais e exigir acesso de rede para commitar são só duas delas…

P.S.: Bom saber sobre o Subversion. Há algum tempo eu tinha desistido dele, mas se ele pelo menos melhorou o suporte para merge na nova versão, acho que vale a pena dar uma olhada. E se ele verdadeiramente passou a controlar patches (revisões) ao invés de versões, já tem tudo para ser distribuído. Será que ele chega lá?

Vou ser sincero com você, ainda não conheço o GIT nem Darcs nem Mercurial. Porém o que você fala sobre merge no SVN se encaixa perfeitamente na versão 1.4. A recem lançada versão 1.5 vem com um suporte a merge que eu nunca tinha visto melhor.

Quanto a adoção desses sistemas centralizados no ambiente de produção das empresas pode ser justificado sim.

Empresas precisam ter um certo controle maior sobre o seu maior bem, que é o código fonte de seus produtos, e por isso a centralização ajuda a manter esse controle. Sei que eiste N maneiras melhor de deixar o fonte sobre controle, como testes atomatizados, equipes auto-gerenciaveis, mas infelizmente não é essa a rotina da maioria das empresas! Nem todos os programadores que tem por ai no mercado tem a mesma responsabilidade e competencia do autor do blog e da maioria de seus leitores. Por anos trabalhando em diversas empresas por ai é incrivel como alguns programadores fazem m*rd* por ai… Claro que esses programadores deveriam ser demitidos e ser contratados programadores melhores para seus lugares, mas mão de obra boa nem é barata e nem fácil de encontrar

O que costumo ver são as pessoas repetindo que o GIT é melhor em fazer merge, mas sem entender bem porque. O SVN faz o merge, mas é vc que tem que se organizar com ele. Precisa criar um sistema “a parte” (nos comentáios de commits) para lidar com isso.

Todos estes controlam modificações, ao invés de versões.

Todos estes tornam o merge muito mais fácil do que grande parte das alternativas centralizadas.

Hipocrisia do ambiente corporativo ?

Pensei que ia tocar no assunto Git, pelo jeito ficou pra um próximo post …