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

22

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?

Matt
fonte
Parece quase como se você já estivesse usando o SVN como um DVCS (de qualquer maneira com relação à ramificação). Tenho certeza de que você pode fazer quase tudo que o Mercurial pode fazer com o SVN (e vice-versa); a questão é: qual é mais fácil de usar e mais conveniente para o seu cenário de desenvolvimento específico? Eu acho que você precisa experimentar Mercurial para um pouco para ver por si mesmo se vale a pena de ele ou não
Cameron
Eu sou um fã do Mercurial e ele claramente oferece um superconjunto dos recursos do SVN, mas, dito isso, esses recursos extras são realmente úteis apenas para uma pequena minoria de projetos. Você provavelmente não precisa, isso não mudará sua vida, mas você estaria recebendo mais recursos e não perdendo nada, então por que não?
jiggy
Você já viu o Hg Init ? É um tutorial do Mercurial escrito por Joel Spolsky. Começa com um capítulo para usuários do Subversion, mas espera que você não saiba nada sobre o DVCS.
Barry Brown,

Respostas:

11

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.

Karl Bielefeldt
fonte
2
+1! Além disso, se você fizer uma tentativa justa e completa de mercurial, tenho certeza de que não vai querer voltar.
Pete
1
"Você precisa se perguntar o que faria com quantas ramificações quiser e que sejam compartilhadas com quem você quiser, e apenas elas" ... "duas pessoas trabalhando em lados opostos de uma interface? Elas precisam compartilhar código entre si. outros regularmente, mas ainda não é estável o suficiente para compartilhar com todos. Eles podem criar um ramo para compartilhar entre si e depois fundi-lo novamente no repositório central quando estiver pronto. " Agora temos tudo isso com subversão.
26611 Matt
@ Matt, então você tem sorte, pois sua empresa é mais uma exceção do que uma regra. A maioria das empresas possui regras muito estritas sobre a criação de filiais no recurso limitado do servidor central, para que as pessoas nem pensem em criá-las por motivos temporários.
Karl Bielefeldt
3
Penso que esta resposta está faltando o fato de que o pôster original já está obrigando o SVN a funcionar de uma maneira muito mais próxima do fluxo de trabalho do DVCS do que a maioria dos usuários do SVN consideraria viável. Em essência, eles já têm a mentalidade do DVCS, portanto, nenhuma mudança fundamental no pensamento é necessária.
Mark Booth
Bom ponto @ Mark. Em uma equipe tão pequena, muitas das convenções normais para equipes maiores acontecem pela janela. Ainda acho que vale a pena por motivos de velocidade.
Karl Bielefeldt
1

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 :-).

dfjacobs
fonte
Queremos ter tempo para mudar? Não, especialmente quando mudamos para svn apenas nos últimos 2 anos. Obrigado por seus comentários.
Matt
1

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.

Mark Booth
fonte
1
O SVN não cria conflito no caso que você mencionou. Aparece apenas quando os dois alteram as mesmas linhas. Geralmente, mesclar é um problema mais com renomear / mover arquivos ou adicionar / excluir no svn porque ele não lida bem com as alterações no diretório. A mesclagem do SVN oferece mais opções do que aquelas 2, normalmente eu uso o "use deles e depois o meu", pois geralmente você deseja manter os dois conjuntos de alterações, e não os exclui!
Gbjbaanb
@gbjbaanb - Não foi o que encontrei, e foi por isso que qualifiquei minha experiência no SVN at least the version I've used. Meu entendimento é que a última versão do svn não entender sobre ancestrais comuns, mas eu não tenho nenhuma experiência dessa e eu suspeito que há muitos servidores lá fora, que executam versões mais antigas do svn que têm os mesmos problemas.
Mark Booth
Aliás, eu amo o fato de que, com hg(e quase certamente git, mas ainda não tentei), você pode pegar um arquivo com três classes, dividi-lo em três arquivos com uma classe cada, e depois mesclar as alterações entre um ramo com o arquivo 'combinado' e uma ramificação com arquivos separados, de forma que as alterações nas classes individuais sejam aplicadas aos arquivos corretos. Pura magia. * 8 ')
Mark Booth
1
gbjbaanb está correto; O SVN não teria conflito no cenário que você descreve. É muito fácil demonstrar isso para si mesmo.
Jeremy
@Jeremy @gbjaanb - A seção editada funciona melhor para você? Eu não vou discutir com você sobre como as svnmesclagens devem funcionar, tenho minha própria experiência com ela na svnlinha de comando e no SVNKit no Eclipse, onde simplesmente puxar atualizações pode resultar em 'conflitos' que devem ser resolvidos manualmente com recortar e colar (Não posso dizer com facilidade 'Quero essas duas alterações, nessa ordem).
Mark Booth
0

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.

SK-logic
fonte