Eu tento entender os benefícios do sistema de controle de versão distribuído (DVCS).

Achei a reeducação do Subversion e este artigo de Martin Fowler muito úteis.

Mercurial e outros DVCS promovem uma nova maneira de trabalhar com códigos com conjuntos de alterações e confirmações locais. Impede a fusão do inferno e outros problemas de colaboração

Não somos afetados por isso, pois pratico a integração contínua e trabalhar sozinho em um ramo privado não é uma opção, a menos que esteja experimentando. Usamos uma ramificação para todas as versões principais, nas quais corrigimos bugs mesclados no tronco.

Mercurial permite que você tenha tenentes

Entendo que isso pode ser útil para projetos muito grandes como o Linux, mas não vejo o valor em equipes pequenas e altamente colaborativas (5 a 7 pessoas).

O Mercurial é mais rápido, ocupa menos espaço em disco e a cópia local completa permite operações mais rápidas de registros e diferenças.

Também não estou preocupado com isso, pois não notei problemas de velocidade ou espaço com o SVN, mesmo em projetos muito grandes em que estou trabalhando.

Estou buscando suas experiências pessoais e / ou opiniões de ex-geeks do SVN. Especialmente em relação ao conceito de conjuntos de alterações e ao aumento geral do desempenho que você mediu.

ATUALIZAÇÃO (12 de janeiro) : Agora estou convencido de que vale a pena tentar.

ATUALIZAÇÃO (12 de junho) : Eu beijei o Mercurial e gostei. O sabor de sua cereja local compromete-se. Eu beijei Mercurial apenas para tentar. Espero que meu servidor SVN não se importe. Parecia tão errado. Parecia tão certo. Não significa que estou apaixonado esta noite .

ATUALIZAÇÃO FINAL (29 de julho) : Tive o privilégio de revisar o próximo livro de Eric Sink , chamado Controle de Versão por Exemplo . Ele terminou de me convencer. Eu vou para o Mercurial.

Nota: Consulte "EDITAR" para obter a resposta da pergunta atual

Antes de tudo, leia Reeducação Subversion de Joel Spolsky. Acho que a maioria das suas perguntas será respondida lá.

Outra recomendação, a palestra de Linus Torvalds no Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Este outro também pode responder à maioria das suas perguntas, e é bastante divertido.

Aliás, algo que eu acho bastante engraçado: até Brian Fitzpatrick e Ben Collins-Sussman, dois dos criadores originais do subversion, disseram em uma conversa no Google "desculpe por isso", referindo-se ao fato de o subversion ser inferior ao mercurial (e aos DVCSs em geral).

Agora, na IMO e em geral, a dinâmica da equipe se desenvolve de maneira mais natural com qualquer DVCS, e um benefício notável é que você pode se comprometer offline porque isso implica o seguinte:

• Você não depende de um servidor e de uma conexão, o que significa tempos mais rápidos.
• Não ser escravo de lugares onde você pode obter acesso à Internet (ou VPN) apenas para poder se comprometer.
• Todo mundo tem um backup de tudo (arquivos, histórico), não apenas do servidor. Ou seja, qualquer pessoa pode se tornar o servidor .
• Você pode confirmar compulsivamente se precisar, sem mexer no código de outras pessoas . As confirmações são locais. Você não pisa nos pés um do outro ao cometer. Você não quebra as construções ou os ambientes de outros apenas comprometendo-se.
• Pessoas sem "acesso de confirmação" podem confirmar (porque confirmar em um DVCS não implica o upload de código), diminuindo a barreira para contribuições, você pode decidir realizar as alterações ou não como integrador.
• Pode reforçar a comunicação natural, já que um DVCS torna isso essencial ... na subversão, o que você tem são corridas de cometer, que forçam a comunicação, mas obstruindo o seu trabalho.
• Os colaboradores podem se unir e gerenciar sua própria fusão, o que significa menos trabalho para os integradores no final.
• Os colaboradores podem ter seus próprios ramos sem afetar os outros (mas, se necessário, compartilhá-los).

Sobre seus pontos:

• A fusão do inferno não existe no DVCSland; não precisa ser tratado. Veja o próximo ponto .
• Nos DVCSs, todos representam um "ramo", o que significa que há mesclagens sempre que alterações são realizadas. Ramos nomeados são outra coisa.
• Você pode continuar usando a integração contínua, se quiser. No entanto, não é necessário IMHO, por que adicionar complexidade ?, apenas mantenha seus testes como parte de sua cultura / política.
• Mercurial é mais rápido em algumas coisas, git é mais rápido em outras coisas. Não depende realmente de DVCSs em geral, mas de suas implementações particulares AFAIK.
• Todo mundo sempre terá o projeto completo, não apenas você. A coisa distribuída tem a ver com o que você pode confirmar / atualizar localmente, compartilhar / retirar de fora do computador é chamado de empurrar / puxar.
• Novamente, leia Reeducação do Subversion. Os DVCSs são mais fáceis e mais naturais, mas são diferentes, não tente pensar que cvs / svn === é a base de todas as versões.

Eu estava contribuindo com alguma documentação para o projeto Joomla para ajudar a pregar uma migração para DVCSs, e aqui fiz alguns diagramas para ilustrar centralizado versus distribuído.

Centralizado

Distribuído na prática geral

Distribuído ao máximo

Você vê no diagrama que ainda existe um "repositório centralizado", e este é um dos argumentos favoritos dos fãs de versão centralizada: "você ainda está sendo centralizado" e não, pois não, pois o repositório "centralizado" é apenas um repositório que você todos concordam (por exemplo, um repo oficial do github), mas isso pode mudar a qualquer momento que você precisar.

Agora, este é o fluxo de trabalho típico para projetos de código aberto (por exemplo, um projeto com colaboração massiva) usando DVCSs:

O Bitbucket.org é um equivalente do github para mercurial, saiba que eles têm repositórios privados ilimitados com espaço ilimitado, se sua equipe for menor que cinco, você poderá usá-lo gratuitamente.

A melhor maneira de convencer-se de usar um DVCS é experimentar um DVCS, todo desenvolvedor experiente de DVCS que usou svn / cvs lhe dirá que vale a pena e que eles não sabem como sobreviveram o tempo todo sem ele.

EDIT : Para responder a sua segunda edição, posso apenas reiterar que, com um DVCS, você tem um fluxo de trabalho diferente, aconselho a não procurar motivos para não experimentá-lo devido às práticas recomendadas , parece que quando as pessoas argumentam que o OOP não é necessário porque eles podem contornar padrões complexos de design com o que sempre fazem com o paradigma XYZ; você pode se beneficiar de qualquer maneira.

Experimente, você verá como trabalhar em "uma filial particular" é realmente uma opção melhor. Uma razão pela qual posso dizer por que o último é verdadeiro é porque você perde o medo de se comprometer , permitindo que você se comprometa a qualquer momento que achar melhor e trabalhe de maneira mais natural.

Em relação à "fusão do inferno", você diz "a menos que estejamos experimentando", eu digo "mesmo se você estiver experimentando + mantendo + trabalhando na v2.0 renovada ao mesmo tempo ". Como eu disse antes, a fusão do inferno não existe, porque:

• Sempre que você confirma, gera uma ramificação sem nome e sempre que suas alterações atendem às alterações de outras pessoas, ocorre uma mesclagem natural.
• Como os DVCSs coletam mais metadados para cada confirmação, ocorrem menos conflitos durante a mesclagem ... então você pode chamá-lo de "mesclagem inteligente".
• Quando você se depara com conflitos de mesclagem, é isso que você pode usar:

Além disso, o tamanho do projeto não importa; quando mudei para o subversion, eu já estava vendo os benefícios enquanto trabalhava sozinho, tudo parecia certo. Os conjuntos de alterações (não exatamente uma revisão, mas um conjunto específico de alterações para arquivos específicos que você inclui uma confirmação, isolados do estado da base de código) permitem visualizar exatamente o que você quis dizer com o que estava fazendo em um grupo específico de arquivos, nem toda a base de código.

Em relação ao modo como os conjuntos de mudanças funcionam e ao aumento de desempenho. Tentarei ilustrá-lo com um exemplo que gostaria de dar: o projeto mootools alterna do svn ilustrado em seu gráfico de rede no github .

Antes

Depois de

O que você está vendo é que os desenvolvedores conseguem se concentrar em seu próprio trabalho enquanto comprometem, sem medo de quebrar o código de outros, eles se preocupam em quebrar o código de outros depois de pressionar / puxar (DVCSs: primeiro confirme, depois empurre / puxe e atualize ), mas como a fusão é mais inteligente aqui, elas geralmente nunca acontecem ... mesmo quando há um conflito de mesclagem (o que é raro), você gasta apenas 5 minutos ou menos para corrigi-lo.

Minha recomendação para você é procurar alguém que saiba como usar o mercurial / git e dizer-lhe para explicar isso a você. Ao passar cerca de meia hora com alguns amigos na linha de comando enquanto utilizava o mercurial com nossas áreas de trabalho e contas de bitbucket, mostrando-lhes como se fundir, até fabricando conflitos para eles para ver como consertar em um período ridículo de tempo, consegui mostrar eles o verdadeiro poder de um DVCS.

Finalmente, eu recomendo que você use mercurial + bitbucket em vez do git + github se você trabalha com o pessoal do Windows. O Mercurial também é um pouco mais simples, mas o git é mais poderoso para o gerenciamento de repositórios mais complexo (por exemplo, git rebase ).

Algumas leituras adicionais recomendadas:

• Sistemas de controle de revisão distribuídos: Git vs. Mercurial vs. SVN
• Git vs. Mercurial: por favor, relaxe
• Controle de Versão Distribuído e Git [Parte 1] e Controle de Versão Distribuído e Git [Parte 2]
• Git / Mercurial vs. Subversion: Luta!
• DVCS vs Subversion smackdown, rodada 3
• Por que eu gosto mais do Mercurial do que do Git ( parte 1 , parte 2 )
• Contribuindo com o Git: reduzindo os atritos da colaboração de código aberto com o Git VCS
• "Como os DVCSs funcionaram para você até agora?" - publique no Joomla! Lista de discussão do Framework Development solicitando feedback após a adoção experimental de mercurial e git para o Joomla! Projeto Plataforma
• Ramificação DVCS (com Mercurial) - Uma introdução detalhada e orientada a exemplo para a aparência de ramificação em um DVCS, que é possivelmente o recurso mais importante nesses sistemas

O que você está dizendo é, entre outras coisas, que se você permanecer essencialmente em uma ramificação única, não precisará de controle de versão distribuído.

Isso é verdade, mas não é uma restrição desnecessariamente forte à sua maneira de trabalhar e que não se adapta bem a vários locais em vários fusos horários? Onde o servidor central do subversion deve estar localizado e todos devem voltar para casa se, por algum motivo, esse servidor estiver inoperante?

DVCSes são para Subversion, o que Bittorrent é para ftp

(tecnicamente, não legalmente). Talvez se você pensar bem, talvez entenda por que é um grande salto à frente?

Para mim, nossa mudança para o git resultou imediatamente em

• Nossos backups são mais fáceis de fazer (apenas "git remote update" e pronto)
• Mais fácil cometer pequenos passos ao trabalhar sem acesso ao repositório central. Você apenas trabalha e sincroniza quando volta à rede que hospeda o repositório central.
• Hudson constrói mais rapidamente. Muito, muito mais rápido para usar git pull do que atualizar.

Então, considere por que o bittorrent é melhor que o ftp e reconsidere sua posição :)

Nota: Foi mencionado que há casos de uso em que o ftp é mais rápido e do que o bittorrent. Isso é verdade da mesma maneira que o arquivo de backup que seu editor favorito mantém é mais rápido do que um sistema de controle de versão.

O recurso matador dos sistemas de controle de versão distribuído é a parte distribuída. Você não faz check-out de uma "cópia de trabalho" do repositório, clona uma cópia inteira do repositório. Isso é enorme, pois oferece benefícios poderosos:

• Você pode aproveitar os benefícios do controle de versão, mesmo quando você não tem acesso à Internet, como ... Infelizmente, este é usado em excesso e exagerado, porque o DVCS é incrível - simplesmente não é um forte ponto de venda, já que muitos nós nos encontramos codificando sem acesso à internet com a mesma frequência que começa a chover sapos.

• O verdadeiro motivo de ter um repositório local é matador é que você tem controle total sobre o seu histórico de consolidação antes de ser enviado ao repositório principal .

Já corrigiu um bug e acabou com algo como:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

E assim por diante. Um histórico como esse é confuso - havia realmente apenas uma correção, mas agora a implementação está espalhada entre muitos commits que contêm artefatos indesejados, como a adição e remoção de instruções de depuração. Com um sistema como o SVN, a alternativa é não confirmar (!!!) até que tudo esteja funcionando para manter o histórico limpo. Mesmo assim, os erros passam e a Lei de Murphy está esperando para brutalizá-lo quando quantidades significativas de trabalho não são protegidas pelo controle de versão.

Ter um clone local do repositório, que você possui , corrige isso, pois você pode reescrever o histórico rolando continuamente as confirmações "fix it" e "oops" na confirmação "bug fix". No final do dia, uma confirmação limpa é enviada ao repositório principal que se parece com:

r321 Fixed annoying bug.

Qual é o caminho que deve ser.

A capacidade de reescrever a história é ainda mais poderosa quando combinada com o modelo de ramificação. Um desenvolvedor pode fazer um trabalho totalmente isolado dentro de uma ramificação e, quando chegar a hora de colocar essa ramificação no tronco, você terá todo tipo de opções interessantes:

• Faça uma mesclagem simples de baunilha . Traz tudo em verrugas e tudo.

• Faça uma rebase . Permite que você classifique o histórico de ramificações, reorganize a ordem de confirmações, jogue confirmações, junte confirmações e reescreva mensagens de confirmação - até mesmo edite as confirmações ou adicione novas! Um sistema de controle de versão distribuído oferece suporte profundo à revisão de código.

Depois que aprendi como os repositórios locais me permitiram editar minha história em prol da sanidade de meus colegas programadores e do meu futuro eu, desliguei o SVN para sempre. Meu cliente do Subversion é agora git svn.

Permitir que desenvolvedores e gerentes exerçam controle editorial sobre o histórico de confirmação resulta em um melhor histórico do projeto e ter um histórico limpo para trabalhar realmente ajuda minha produtividade como programador. Se toda essa conversa sobre "reescrever o histórico" o assusta, não se preocupe, pois é para isso que servem os repositórios central, público ou mestre. A história pode (e deve!) Ser reescrita até o ponto em que alguém a coloca em uma ramificação em um repositório de onde outras pessoas estão retirando. Nesse ponto, a história deve ser tratada como se estivesse gravada em uma tábua de pedra.

A resposta dos dukofgamings é provavelmente a melhor possível, mas quero abordar isso de uma direção diferente.

Vamos supor que o que você diz é absolutamente verdadeiro e que, ao aplicar boas práticas, você pode evitar os problemas que o DVCS foi projetado para corrigir. Isso significa que um DVCS não ofereceria nenhuma vantagem? As pessoas fedem a seguir as melhores práticas. As pessoas vão estragar tudo. Então, por que você evitaria o software projetado para corrigir um conjunto de problemas, optando por confiar nas pessoas para fazer algo que você pode prever com antecedência que elas não farão?

Sim, dói quando você precisa mesclar grandes commits no subversion. Mas essa também é uma ótima experiência de aprendizado, fazendo todo o possível para evitar a fusão de conflitos. Em outras palavras, você aprende a fazer check-in com frequência . A integração antecipada é uma coisa muito boa para qualquer projeto co-localizado. Enquanto todo mundo estiver fazendo isso, usar o subversion não deve ser um grande problema.

O Git, por exemplo, foi projetado para trabalho distribuído e incentiva as pessoas a trabalhar em seus próprios projetos e a criar garfos próprios para uma (eventual) fusão posteriormente. Foi não especificamente concebidos para integração contínua em um "pequeno e altamente colaborativos equipas" que é o que o OP está pedindo. É o contrário, pense nisso. Você não terá utilidade para seus recursos distribuídos sofisticados, se tudo o que você está fazendo é sentar na mesma sala trabalhando juntos no mesmo código.

Portanto, para uma equipe co-localizada e usando IC, realmente não acho que importe muito se você usa um sistema distribuído ou não. Tudo se resume a uma questão de gosto e experiência.

Porque você deve desafiar continuamente seu próprio conhecimento. Você gosta de subversão, e eu posso entender porque o usei por muitos anos e fiquei muito feliz com isso, mas isso não significa que ainda é a ferramenta que melhor lhe convier.

Acredito que quando comecei a usá-lo, era a melhor escolha na época. Mas outras ferramentas surgem com o tempo e agora eu prefiro o git, mesmo para meus próprios projetos de tempo livre.

E o subversion tem algumas falhas. Por exemplo, se você renomear um diretório no disco, ele não será renomeado no repositório. A movimentação de arquivos não é suportada, tornando um arquivo mover uma operação de copiar / excluir, dificultando a mesclagem de alterações quando os arquivos foram movidos / renomeados. E o rastreamento de mesclagem não é realmente incorporado ao sistema, mas implementado na forma de uma solução alternativa.

O Git resolve esses problemas (incluindo detectar automaticamente se um arquivo foi movido, você nem precisa dizer que isso é um fato).

Por outro lado, o git não permite ramificar em níveis de diretório individuais como o subversion.

Portanto, minha resposta é: você deve investigar alternativas, verificar se elas atendem melhor às suas necessidades do que as que você conhece e depois decidir.

No que diz respeito ao desempenho, o Git ou qualquer outro DVCS tem uma grande vantagem sobre o SVN quando você precisa alternar de uma ramificação para outra ou pular de uma revisão para outra. Como tudo é armazenado localmente, as coisas são muito mais rápidas do que para o SVN.

Só isso poderia me fazer mudar!

Em vez disso, apoiando-se na ideia de que "ao aplicar as práticas recomendadas não é necessário um DVCS", por que não considerar que o fluxo de trabalho SVN é um fluxo de trabalho, com um conjunto de práticas recomendadas, e o fluxo de trabalho GIT / Hg é um fluxo de trabalho diferente, com um conjunto diferente de melhores práticas.

git bisect (e todas as implicações no seu repositório principal)

No Git, um princípio muito importante é que você pode encontrar erros usando git bisect. Para fazer isso, você pega a última versão que você sabia que funcionava, e a primeira que você falhou, e realiza (com a ajuda do Git) uma pesquisa binária para descobrir qual commit causou o erro. Para fazer isso, todo o seu histórico de revisões deve estar relativamente livre de outros erros que possam interferir na sua pesquisa de erros (acredite ou não, isso realmente funciona muito bem na prática, e os desenvolvedores de kernel do Linux fazem isso o tempo todo).

Para alcançar a git bisectcapacidade, você desenvolve um novo recurso em sua própria ramificação de recursos , o refaz e limpa o histórico (para que você não tenha nenhuma revisão que não funcione no seu histórico - apenas algumas alterações que você faz parcialmente para corrigir o problema) e, quando o recurso estiver pronto, você o mesclará no ramo principal com o histórico de trabalho.

Além disso, para fazer isso funcionar, você precisa ter disciplina sobre qual versão do ramo principal da qual você inicia o ramo de recursos. Você não pode simplesmente iniciar a partir do estado atual da masterramificação porque isso pode ter erros não relacionados - portanto, o conselho na comunidade do kernel é começar o trabalho a partir da versão estável mais recente do kernel (para grandes recursos) ou iniciar o trabalho do último candidato a lançamento marcado.

Você também pode fazer backup do seu progresso intermediário, empurrando a ramificação do recurso para um servidor enquanto isso, e pode empurrar a ramificação do recurso para um servidor para compartilhá-lo com outra pessoa e obter feedback antes que o recurso seja concluído, antes de precisar transforme o código em um recurso permanente da base de código com o qual todos * no seu projeto precisam lidar.

A página do manual gitworkflows é uma boa introdução aos fluxos de trabalho para os quais o Git foi projetado. Também Por que Git é Melhor que X aborda os fluxos de git.

Projetos grandes e distribuídos

Por que precisamos de tenentes em uma equipe altamente colaboradora com boas práticas e bons hábitos de design?

Porque em projetos como o Linux, há tantas pessoas envolvidas que são tão geograficamente distribuídas que é difícil colaborar tanto quanto uma pequena equipe que compartilha uma sala de conferência. (Suspeito que, para o desenvolvimento de um produto grande como o Microsoft Windows que, mesmo que todas as pessoas estejam localizadas no mesmo prédio, a equipe seja grande demais para manter o nível de colaboração que faz um VCS centralizado funcionar sem substitutos.)

Por que não usá-los em conjunto? No meu projeto atual, somos forçados a usar o CVS. No entanto, também mantemos repositórios git locais para desenvolver o recurso. Este é o melhor dos dois mundos, porque você pode tentar várias soluções e manter versões do que está trabalhando, em sua própria máquina. Isso permite reverter para versões anteriores do seu recurso ou tentar várias abordagens sem entrar em problemas quando você estraga seu código. Ter um repositório central oferece os benefícios de ter um repositório centralizado.

Não tenho experiência pessoal com o DVCS, mas, pelo que recordo das respostas aqui e de alguns documentos vinculados, a diferença mais fundamental entre o DVCS e o CVCS é o modelo de trabalho usado

DVCS

O modelo de trabalho do DVCS é que você está desenvolvendo isolado . Você está desenvolvendo seu novo recurso / correção de bug isoladamente de todas as outras alterações até o momento em que decide liberá-lo para o restante da equipe. Até esse momento, você poderá fazer os check-ins que desejar, porque ninguém mais se incomodará com isso.

CVCS

O modelo de trabalho do CVCS (em particular o Subversion) é que você está desenvolvendo um trabalho colaborativo . Você está desenvolvendo seu novo recurso / correção de bug em colaboração direta com todos os outros membros da equipe e todas as alterações estão imediatamente disponíveis para todos.

Outras diferenças

Outras diferenças entre svne git/ hg, como revisões versus conjuntos de alterações, são incidentais. É muito bem possível criar um DVCS baseado em revisões (como o Subversion os possui) ou um CVCS baseado em conjuntos de alterações (como o Git / Mercurial os possui).

Não vou recomendar nenhuma ferramenta específica, porque depende principalmente do modelo de trabalho com o qual você (e sua equipe) se sente mais confortável.
Pessoalmente, não tenho problemas em trabalhar com um CVCS.

• Não tenho medo de fazer check-in, pois não tenho problemas para entrar em um estado incompleto, mas compilável.
• Quando experimentei o merge-hell, foi em situações em que teria ocorrido em ambos svne git/ hg. Por exemplo, o V2 ​​de algum software estava sendo mantido por uma equipe diferente, usando um VCS diferente, enquanto desenvolvíamos o V3. Ocasionalmente, as correções de bugs precisavam ser importadas do V2 VCS ​​para o V3 VCS, o que basicamente significava fazer um check-in muito grande no V3 VCS (com todas as correções de bugs em um único conjunto de alterações). Sei que não era o ideal, mas foi uma decisão de gerenciamento usar diferentes sistemas VCS.