Aviso: Desde este post, encontrei o Mercurial e o amo muito melhor que o SVN. Portanto, este post está um pouco desatualizado com os comentários do Pro SVN e o anti-DVCS geral, mas o material anti-git ainda é relevante
Sou fã do SVN sobre o Git.
Por quê? Como o SVN era muito mais fácil para um único desenvolvedor ou equipe pequena, o git (especificamente o msysgit) me deixou com um gosto ruim na boca.
Quando eu estava internando em uma pequena loja, fui apresentado ao git no Windows. Percebi imediatamente a quantidade de trabalho necessário para fazê-lo funcionar com o Github. Primeiro, eu tive que gerar uma chave privada ssh, colar a chave pública no Github, abrir o concurso e abrir minha chave privada toda vez que eu quisesse pressionar, o que era extremamente irritante.
E nunca gostei muito de estar desmontando todo o repositório. Admito que nunca trabalhei com nada grande, mas teria medo de baixar o repositório do KDE no Git se todo o repositório e suas revisões estiverem no meu HD.
Depois, houve o processo confuso de fazer uma confirmação. TMK, eu tive que primeiro "preparar" todos os arquivos que eu queria confirmar (o que foi um saco quando você tinha muitos arquivos, demorei um pouco para encontrar o comando manual para preparar tudo), depois fiz o commit e depois fui para o diretório principal. repo (por que isso é uma operação separada ?!).
Você também tinha os dados de confirmação não (!) Muito úteis. Oh, olhe, isso é commit 14f74433245ae17aeea parte da árvore 2167a4934d0a4a7db0de e pai d7042abb4821d3faf600. Que diabos isso significa? Eu deveria ser capaz de descobrir as coisas rapidamente e não precisar consultar uma documentação estranha.
Falando em documentação, pelo menos quando eu a estava usando, parecia que tudo estava no formato de arquivo linux man, ou seja, confuso e inútil para mim. Eu raramente conseguia encontrar muita ajuda nos documentos e simplesmente recorria ao Google.
E com confirmações, a única coisa que eu não gostei foi a falta de números de versão. Agora eu sei que isso se deve ao design do git, mas qualquer software precisa de um número de versão. Ainda me lembro dos marcadores confirmados que apareceriam dizendo "Versão alterada para 1.8.6" ou algo semelhante, mas você ainda não conseguiu criar números. Para mim, ter a versão 1.8.6.5164 (a última parte é o número da revisão) me diz muito mais do que simplesmente 1.8.6 e uma nota dizendo que algo menor mudou, tente
Especificando o software, o programa base no Windows é o msysgit, que é uma interface terrível. Ele me trancou algumas vezes, tinha uma interface horrível e a integração CLI-GUI era, na melhor das hipóteses, duvidosa. Os viciados em linha de comando ao meu redor odiavam ainda mais a GUI.
Agora vamos ver o SVN. E já que estou no Windows e tenho uma conta do Google, especificamente o TortoiseSVN e o Google Code.
Primeiro, a integração completa do shell para fazer tudo no repositório (e para o pessoal do Linux, o RabbitVCS faz a mesma coisa), sem a necessidade de uma GUI principal. Obter um repositório é fácil como um checkout, não é necessário SSH (não me lembro se o Github exigia SSH para puxar) e nenhum repositório inteiro + todo o passado confirmado sentado no seu HD.
A confirmação é extremamente fácil, principalmente porque não é necessário SSH ou preparo. Você simplesmente verifica todos os arquivos que deseja usando a opção muito útil selecionar todos que, na minha versão do msysgit, não estava disponível, digita uma mensagem de confirmação e pressiona a confirmação. O Google Code solicita suas informações de login (que a maioria dos clientes armazena) e pronto. Simples, fácil e sem SSH
Números de versão? Com um código fácil, você pode adicionar um número de versão e um número de confirmação a todos os caixas, o que facilita muito as coisas. Você também obtém números de versão utilizáveis que realmente mostram uma alteração, por exemplo, 1.8.6.5165 é mais recente que 1.8.6.5164.
Documentação? Bem, é difícil dizer. A tartaruga está documentada, mas eu não me refiro à documentação oficial há tanto tempo que não posso julgar. Ler um guia de introdução simples foi o suficiente para mim.
Mesclar é outra coisa que não posso comparar. Eu tive que fazer isso uma vez no Git quando alguém cometeu uma alteração em um arquivo no qual eu estava trabalhando, mas nunca no SVN.
Qual eu recomendaria? Bem, em grandes equipes, o git tem suas vantagens, principalmente em seu ciclo de desenvolvimento não linear. Em outro projeto, vi 4 programadores começarem em ramificações separadas e depois mesclar todo o código de maneiras muito estranhas que de alguma forma se transformaram na ramificação principal final. O Github e o msysgit tinham uma ferramenta de visualização muito boa para todo o projeto que eu realmente gostei.
Para projetos de desenvolvedor único ou de equipe pequena, o SVN seria o melhor, pois a maioria dos recursos do Gits não é usada e você apenas obtém suas partes negativas. Simplicidade é uma coisa tão legal
