Em suma, quais são as vantagens de git e mercurial sobre subversão?

votos
7

Alguém pode me dizer o que o hype é sobre Git e Mercurial sobre Subversion?

Publicado 19/05/2009 em 22:52
fonte usuário
Em outras línguas...                            


9 respostas

votos
6

Tanto quanto Git vai, eu acho que há muito poucos, o maior dos quais (na minha opinião) é ramificação avançada do Git e apoio fusão. Git torna muito, muito fácil de ramo, e sua capacidade de mesclar em mudanças é muito, muito melhor do que a de SVN do. Ferramentas como gitktambém torná-lo muito, muito fácil de visualizar as relações entre os ramos em um repositório Git.

Existem inúmeros outros benefícios. Eu acho que Git tem melhores ferramentas e um melhor conjunto de ferramentas, e o fato de que ele não requer um repositório central, e um "check-out" repo é bom quando você está trabalhando em pequenos projectos por si mesmo. Eu acho que a fusão e ramificação é o maior benefício, no entanto.

(Um monte de que vai para Mercurial, bem, embora eu nunca gostei ênfase de Mercurial em clones locais para "ramificação", eu prefiro muito mais método de manter todos os ramos da mesma repo do Git.)

Respondeu 19/05/2009 em 23:01
fonte usuário

votos
5

A comparação pro-git para vários sistemas de controle de origem pode ser encontrada em http://whygitisbetterthanx.com/ . O que eu mais gosto sobre git é:

  • É mais rápido.
  • Não duplicar código-fonte como SVN faz no subdiretório .svn.
  • Ele permite cometer desligada em seguida, empurrando.
Respondeu 19/05/2009 em 22:57
fonte usuário

votos
4

Digamos que você tenha um projeto pessoal, você iria colocá-lo sob controle de versão? (Espero que você disser que sim).

Se assim for, então, não é sim algo simples? Git não exigem que você configurar um servidor ou qualquer coisa assim. O seu directório de trabalho é o seu repositório.

Quer experimentar uma nova ideia maluca? Apenas ramificar e experimentar com ele nesse ramo. Se for bem sucedido, volte para o seu ramo principal e mesclagem. Se a sua idéia não funcionou muito bem, apenas voltar para o ramo principal e excluir esse ramo crazy_idea.

Quer trabalhar em um crazy_idea mas também continuar a desenvolver o branch master normalmente? Novamente, não há problema, você pode alternar entre os ramos, e só se fundem crazy_idea depois que amadureceu o suficiente.

Mesmo se você estiver em uma equipe, cada desenvolvedor (ou um pequeno grupo de desenvolvedores) pode trabalhar em alguma idéia em um ramo experimental antes de fundir-lo com o resto do código.

Suponho que faz open source ainda mais fácil. Você não precisa dar permissões de acesso a ninguém. Se alguém tem implementado uma grande característica, ele pode pedir-lhe para puxar a partir dele. Se você gosta do que vê, você pode fundi-lo.

Aqui está uma surpresa: git é muito mais simples do que svn.

Mesmo. Eu sempre ouvi falar de controle de versão, mas nunca o fez. O tempo que eu tentei colocar meu código sob um servidor svn local, foi um pesadelo; Eu realmente odiava.

Agora, eu coloquei tudo sob git.

Respondeu 19/05/2009 em 23:59
fonte usuário

votos
4

Git e Mercurial são distribuídos , SVN não é.

Vantagem ou não? Você decide...

Respondeu 19/05/2009 em 22:57
fonte usuário

votos
3

Para mim uma coisa importante: SVN realmente não suportam tags:

  1. Tags não são simbólicos. Eles são caminhos em repo (cópias vaca)
  2. Em SVN um arquivo pertence a uma tag (porque tag é uma cópia do arquivo). Em outros sistemas e na intuição humana: tag pertence a um arquivo. É relação oposto.
  3. Por isso, é difícil listar algo como: "todas as tags dos arquivos tem". Esta informação não é apenas armazenados diretamente no repositório SVN.
Respondeu 19/05/2009 em 22:59
fonte usuário

votos
3

Esta não é tanto que um lado que "melhor" do que o outro, é que GIT, Mercurial, et al permitem que você trabalhe de maneira diferente do Subversion ou CVS. Subversion e CVS oferecem apenas uma estrutura de repositório centralizado, enquanto os outros são "distribuídos". A abordagem distribuída torna mais fácil a colaboração ad hoc entre os desenvolvedores, e também pode afetar a forma como você gerenciar grupos de mudanças em seu próprio computador.

Qual o método se encaixa melhor para você é algo que você ou sua organização terá de decidir.

Respondeu 19/05/2009 em 22:58
fonte usuário

votos
2

Você tem a mesma gama de "diferenças" entre Git e SVN do que entre Git e CleaCase
(veja meu post sobre os " conceitos fundamentais VCS ")

  • SVN: lineares centrais VCS, onde ramo e etiqueta são o mesmo (um ponto em uma história linear).
  • Git: DAG ( Directed acíclico Graph ) distribuídos VCS, onde cada caminho do gráfico é um ramo, e cada espaço de trabalho é o repositório completo.

Desde Git se contenta-oriented, que irá reunir muito mais eficiente do que Subversion por:

  • encontrar muito rapidamente dentro de seu gráfico que precisam ser mesclados
  • aplicar o emplastro à direita
Respondeu 19/05/2009 em 23:05
fonte usuário

votos
1

Eles conceitualmente organizar revisões como changesets que permitem ramificar / fundir o seu código muito facilmente. Mesclando uma filial no SVN é uma experiência extremamente dolorosa.

Respondeu 20/05/2009 em 00:08
fonte usuário

votos
1

Para mim, svn está funcionando bem. Para 1 - 10 desenvolvedores, com base na experiência.

É claro que a versão 'real' mentiras - na Nuvem no host redundante (espero algum lugar que cuida de seus dados e uptime). Parece que a leitura sobre git é que é mais complicado, maior e mais capaz. Então se você quer um fluxo de trabalho 'svn centralizada', (ver a http://whygitisbetterthanx.com/ local) com menos maneiras de fazer as coisas, etc, então use svn.

Eu costumava CVS até que fosse óbvio onde toda a diversão era. Eu acho que em poucos anos, se eu mudar novamente, será para git? Mas realmente - se você está gastando tempo com seu sistema de controle de versão em qualquer dia diferente do dia em que você configurá-lo, então você está fazendo algo errado.

Respondeu 19/05/2009 em 23:52
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more