Somos geeks do Subversion e queremos conhecer os benefícios do Mercurial [fechado]

Depois de ler que sou um nerd do Subversion, por que devo considerar ou não o Mercurial, o Git ou qualquer outro DVCS .

Eu tenho uma pergunta de acompanhamento relacionada. Li essa pergunta e li os links e vídeos recomendados e vejo os benefícios, mas não vejo a mudança geral de mentalidade das pessoas.

Nossa equipe é formada por 8 a 10 desenvolvedores que trabalham em uma grande base de código composta por 60 projetos. Usamos o Subversion e temos um tronco principal. Quando um desenvolvedor inicia um novo caso do Fogbugz, ele cria um ramo svn, faz o trabalho no ramo e, quando termina, volta ao tronco. Ocasionalmente, eles podem permanecer no ramo por um longo período de tempo e mesclar o tronco ao ramo para captar as alterações.

Quando assisti Linus falar sobre pessoas criando um ramo e nunca mais fazê-lo, não somos nós. Criamos provavelmente de 50 a 100 agências por semana sem problemas. O maior desafio é a fusão, mas também ficamos muito bons nisso. Eu costumo mesclar por fogbugz case & checkin do que por toda a raiz do ramo.

Nunca trabalhamos remotamente e nunca fazemos ramos fora dos ramos. Se você é o único que trabalha nessa seção da base de código, a mesclagem no tronco ocorre sem problemas. Se alguém tiver modificado a mesma seção de código, a mesclagem poderá ficar confusa e você poderá precisar fazer alguma cirurgia. Conflitos são conflitos, não vejo como qualquer sistema poderia acertar a maior parte do tempo, a menos que fosse inteligente o suficiente para entender o código.

Depois de criar uma ramificação, a verificação a seguir dos arquivos com mais de 60k + leva algum tempo, mas isso seria um problema em qualquer sistema de controle de origem que usaríamos.

Existe algum benefício de qualquer DVCS que não estamos vendo que seria de grande ajuda para nós?

Para reformular sua pergunta: "Se planejamos usar apenas o DVCS de maneira centralizada, que benefícios ele tem?" Quando você pergunta dessa maneira, não faz. Um ramo por tarefa é extremamente comum no VCS. Se você pensar bem, ter uma cópia de trabalho local do código-fonte na máquina de um desenvolvedor que muda independentemente do tronco por um dia é uma ramificação, mesmo que ninguém chame isso. A única diferença entre isso e seu fluxo de trabalho é que você também está dando um nome permanente a essas ramificações no servidor central. Não é esse o tipo de ramificação que Linus e outros estão falando.

Entender o DVCS requer uma mudança fundamental no pensamento. Você precisa se perguntar o que faria com quantos ramos quiser e que sejam compartilhados com quem quiser e somente com eles. Isso inclui ramos que são vistos apenas por você.

As possibilidades são infinitas. Para apenas um exemplo, que tal duas pessoas trabalhando em lados opostos de uma interface? Eles precisam compartilhar código regularmente, mas ainda não é estável o suficiente para compartilhar com todos. Eles podem criar uma ramificação para compartilhar entre si e depois mesclá-la de volta ao repositório central quando estiver pronta.

A capacidade de realizar commits locais intermediários vale a pena por si só. Isso é algo que você só precisa experimentar por si mesmo.

A velocidade obtida com o repo local também vale a pena por si só. Sim, o clone inicial será inevitavelmente lento em qualquer VCS para um repositório de arquivos de 60k, mas quando você tiver isso, verificar uma nova ramificação é uma ordem de magnitude mais rápida com um DVCS.

Para o seu caso particular, não há benefício em mudar para um DVCS. Você está satisfeito com seu sistema existente, ele faz tudo o que você precisa, então por que mudar? O SVN ainda é um projeto de código aberto ativo e possui integrações melhores e mais maduras com todos os principais IDEs e ferramentas de desenvolvimento do que hg ou git. Dado o tamanho da sua equipe e o número de projetos, você realmente deseja dedicar algum tempo para converter em uma nova ferramenta quando a existente estiver funcionando perfeitamente?

Se você possui desenvolvedores que simplesmente não podem funcionar sem um DVCS, aponte-os para os gateways svn para hg ou git. Deixe bem claro para eles que seus checkins no repositório svn devem estar em conformidade com os procedimentos e processos que o restante do time usa. Outra vantagem dessa abordagem é que os verdadeiros fanáticos do DVCS que já usam os gateways sem avisar que agora podem sair do armário :-).

Parece-me que você já está usando um fluxo de trabalho muito semelhante ao tipo de fluxo de trabalho que muitas pessoas adotam depois que começam a usar um DVCS.

Do seu ponto de vista, um DVCS terá as seguintes vantagens significativas sobre o SVN:

• Depois de clonar seu (s) repositório (s), muitas operações podem ser realizadas localmente.
  • Observar o log do repositório não precisa tocar no servidor svn, portanto, pode ser incrivelmente rápido.
  • Da mesma forma, a alternância de ramificações não requer acesso ao servidor, nem clones locais.
• Porque ramos são caminhos divergentes apenas através da história, seu repositório não está confuso com todos os ramos ninguém tem todo o criado (apenas realmente tem libertação filiais no SVN, mas o branchesdiretório ainda tem muitos subdiretórios que não são mais relevantes).
  • No git, depois que uma ramificação é mesclada novamente e a ref excluída, você talvez nunca saiba que ela estava lá.
  • No Mercurial, você tem a opção de nomear um ramo (nesse caso, ele é codificado em cada conjunto de alterações em perpetuidade) ou apenas criar um ramo sem nome (topológico), que se fundirá silenciosamente no histórico quando mergevoltar a ser default( trunk)
• No SVN, os ramos dos ramos são muito obscuros para serem úteis. Em gite hgeles são apenas par para o curso.
• Os DVCS entendem que o desenvolvimento de software é um DAG , ou seja, quando você mescla, acaba com um conjunto de alterações com vários pais. O SVN (pelo menos a versão que usei) realmente não entende isso.

Nesse último ponto, você diz

Conflitos são conflitos, não vejo como qualquer sistema poderia acertar na maioria das vezes, a menos que fosse inteligente o suficiente para entender o código.

Ao hgpassar do uso exclusivo para o uso svnsozinho gitsvn, foi minha experiência que as mesclagens são muito mais simples e sem problemas hge gitsvndo que são svn. As mesclagens com svn(pelo menos a versão que usamos) produzem significativamente mais conflitos que precisam ser resolvidos manualmente.

Um dos motivos pelos quais as mesclagens são mais difíceis no SVN é que ele oferece apenas duas opções para cada linha diferente,

• o texto do ramo em que você está mesclando
• o texto da ramificação na qual você está mesclando

enquanto mesclagens de um DVCS normalmente oferecem uma terceira opção, que é

• o texto do ancestral comum dos dois ramos que você está mesclando

Não subestime o quão benéfico isso é, pois ele fornece um contexto muito melhor para as alterações do que uma comparação simples de duas vias.

Em suma, eu sugiro que você tente. Com ferramentas como gitsvne hgsubversion, você pode até experimentá-las com seus repositórios SVN atuais .

^{Observe que criar o clone em primeiro lugar é um PItA real, mas depois que você faz isso, você obtém a maior parte do poder de um DVCS com o CVCS existente.}

Há uma mudança importante que eu notei após essa transição: troco de ramificações com muito mais frequência e comprometo-me com mais frequência do que jamais poderia pagar com o Subversion. Por exemplo, existem várias ramificações de funcionalidade minúsculas, organizadas em uma sequência, e eu posso passar meses adicionando bits a cada uma delas, reorganizando-as facilmente em seqüência em um tronco em constante mudança. Reorganizar a ordem na qual as ramificações da funcionalidade são mescladas é trivial.

Mas, de fato, eu realmente não me afastei do Subversion. Estou apenas usando o git como meu cliente svn local.