Comparação entre centralizadas ou distribuídas Versão Control Systems [fechado]

Question

Quais são os vantagens e desvantagens com o uso de centralizada contra distribuído Sistemas de Controle de Versão (DVCS)? Você tem algum problema em DVCS e como você proteger contra esses problemas? Mantenha o agnóstico ferramenta de discussão e flamejante para o mínimo.

Para aqueles que querem saber o que estão disponíveis ferramentas DVCS, aqui está uma lista dos melhores DVCSs livre / de fonte aberta conhecido:

• Git , (escrito em C) usado pelo Linux Kernel e ruby ??on Rails .
• Mercurial , (escrito em Python) usado por Mozilla e OpenJDK .
• Bazaar , (escrito em Python) usado por desenvolvedores do Ubuntu .
• Darcs , (escrito em Haskell).

Answer 1

A partir minha resposta a uma pergunta href="https://stackoverflow.com/questions/77485/what-are-the-relative-strengths-and-weaknesses-of-git-mercurial-and-bazaar"> diferente :

sistemas de controle de versão distribuído (DVCSs) resolver problemas diferentes do que Centralizada VCSs. Comparando-se como comparar martelos e chaves de fenda.

centralizado VCS sistemas são concebido com a intenção de que existe Uma Fonte isso é verdade Bem-aventurados, e portanto, bom. Todos os desenvolvedores trabalham (Caixa) a partir dessa fonte, e em seguida adicionar (commit) suas alterações, que, em seguida, tornar-se semelhante Bendito. O único diferença real entre CVS, Subversion, ClearCase, Perforce, VisualSourceSafe e todos os outros CVCSes está no fluxo de trabalho, desempenho e integração que cada ofertas de produtos.

Sistemas distribuídos VCS são concebido com a intenção de que um repositório é tão bom quanto qualquer outro, e que funde a partir de um repositório para outra são apenas uma outra forma de comunicação. Qualquer valor semântico como ao qual repositório deve ser confiável é imposta de fora por processo, não pelo próprio software.

A escolha real entre o uso de um tipo ou a outra é organizacional - se seu projeto ou organização desejos controlo centralizado, em seguida, uma é uma SCVD non-starter. Se seus desenvolvedores são Espera-se que trabalhar todo o país / mundo, sem seguro de banda larga ligações a um centro repositório, então DVCS é provavelmente a sua salvação. Se você precisa tanto, você está fsck'd.

Answer 2

Para aqueles que pensam que sistemas distribuídos não permitem autoritário cópias Por favor, note que há uma abundância de lugares onde distribuídos sistemas têm cópias autoritário, o exemplo perfeito é provavelmente árvore do kernel do Linus. lotes certeza pessoas têm suas próprias árvores, mas quase todos eles fluem em direção a árvore de Linus'.

Dito isso que eu uso para pensar que de SCM distribuídos eram úteis apenas para muitos desenvolvedores fazendo coisas diferentes, mas recentemente decidiu que qualquer coisa um repositório centralizado pode fazer uma distribuição pode fazer melhor.

Por exemplo, digamos que você é um desenvolvedor de solo trabalhando em seu próprio pessoal projeto. Um repositório centralizado pode ser uma escolha óbvia, mas considere este cenário. Você está longe de acesso à rede (em um avião, em um parque, etc) e quero trabalhar em seu projeto. Você tem o seu local de copiar de modo que você pode fazer o trabalho bem, mas você realmente quer se comprometer, porque você tem característica um acabado e quiser passar para outro, ou você encontrou um bug para correção ou o que quer. A questão é que com um repo centralizada você acaba quer esmagou todas as alterações em conjunto e comprometendo-los em um conjunto de alterações não-lógico ou você dividi-los manualmente mais tarde.

Com um distribuídos repo você vai em negócios como de costume, cometer, seguir em frente, quando você tem acesso à rede novamente você empurrar para o seu "único e verdadeiro repo" e nada mudou.

Para não mencionar a outra coisa agradável sobre repos distribuídos: full história disponíveis sempre. Você precisa olhar para os logs de revisão quando longe da net? Você precisa anotar a fonte para ver como um erro foi introduzido? Tudo é possível com repos distribuídos.

Por favor, por favor, não acredito que distribuiu vs centralizada é sobre propriedade ou cópias de autoridade ou qualquer coisa assim. A realidade é distribuído é o próximo passo na evolução do SCM da.

Answer 3

Não é realmente uma comparação, mas aqui é o que grandes projetos estão usando:

centralizada VCSes

• Subversion

  Apache, GCC, Ruby, MPlayer, Zope, Plone, Xiph, FreeBSD, WebKit, ...

• CVS

  CVS

Distribuído VCSes

• git

  kernel do Linux, KDE, Perl, Ruby on Rails, Android, Vinho, Fedora, X.org, Mediawiki, Django, VLC, Mono, Gnome, Samba, CUPS, GnuPG, Emacs ELPA ...

• mercurial (hg)

  Mozilla e Mozdev, OpenJDK (Java), OpenSolaris, ALSA, NTFS-3G, Dovecot, MoinMoin, vira lata, PETSc, Octave, FEniCS, aptidão, Python, XEmacs, Xen, Vim, Xine ...

• bzr

  Emacs, Apt, Mailman, MySQL, Squid, ... também promoveu dentro Ubuntu.

• darcs

  ghc, íon, xmonad, ... popular dentro da comunidade Haskell.

• fóssil

  SQLite

Answer 4

Craig Trader disse isso sobre DVCS e CVCS:

Se você precisa de ambos, você está fsck'd.

Eu não diria que você está fsck'd ao usar ambos. Praticamente desenvolvedores que utilizam ferramentas DVCS geralmente tentam fundir as suas alterações (ou enviar solicitações de pull) contra uma localização central (normalmente a um ramo release em um repositório release). Há alguma ironia com os desenvolvedores que usam DVCS mas na vara final com um fluxo de trabalho centralizado, você pode começar a se perguntar se a abordagem distribuída é realmente melhor do que centralizado.

Existem algumas vantagens com DVCS sobre um CVCS:

• A noção de commits exclusivamente reconhecíveis torna o envio de correções entre pares indolor. Ou seja, você faz o patch como um commit, e compartilhá-lo com outros desenvolvedores que precisam dele. Mais tarde, quando todo mundo quer se fundem, que determinado cometer é reconhecido e pode ser comparada entre ramos, tendo menos chance de conflito de mesclagem. Os desenvolvedores tendem a enviar patches para si por stick USB ou e-mail, independentemente da ferramenta que você usa versão. Infelizmente, no caso CVCS, controle de versão irá registrar os commits como independente, não reconhecer que as mudanças são os mesmos, levando a uma maior chance de conflito de mesclagem.

• Você pode ter filiais experimentais locais (repositórios clonados também pode ser considerada um ramo) que você não precisa mostrar para os outros. Isso significa que, alterações significativas não precisa afetar os desenvolvedores se você não empurrou nada upstream. Em um CVCS, quando você ainda tem uma alteração de quebra, você pode ter que trabalhar offline até que você fixa-lo e confirmar as alterações até então. Esta abordagem derrota efetivamente a finalidade do uso de versões como uma rede de segurança, mas é um mal necessário em CVCS.

• No mundo de hoje, as empresas costumam trabalhar com desenvolvedores de off-shore (ou se ainda melhor eles querem trabalhar em casa). Ter um DVCS ajuda a este tipo de projectos, porque ele elimina a necessidade de uma conexão de rede confiável, já que todos tem seu próprio repo.

... e algumas desvantagens que geralmente têm soluções alternativas:

• Quem tem a última revisão? Em um CVCS, o tronco geralmente tem a última revisão, mas em um DVCS, pode não ser claramente óbvio. A solução alternativa é o uso de regras de conduta, que os desenvolvedores em um projeto tem que chegar a um acordo em que repo para mesclar seu trabalho contra.

• bloqueios pessimistas, ou seja, um arquivo está bloqueado ao fazer um check-out, geralmente não são possíveis por causa da concorrência que pode acontecer entre os repositórios em DVCS. existe o bloqueio de arquivos razão no controle de versão é porque os desenvolvedores querem evitar conflitos de mesclagem. No entanto, o bloqueio tem a desvantagem de retardar o desenvolvimento para baixo como dois desenvolvedores não podem trabalhar no mesmo pedaço de código simultaneamente como com um modelo de transação longa e não é garantia de uma prova completa contra conflitos de mesclagem. As maneiras única sãos independentemente de controle de versão é combater grandes conflitos de mesclagem é ter uma boa arquitetura de código (como baixo acoplamento alta coesão) e dividir suas tarefas de trabalho para que eles tenham baixo impacto sobre o código (que é mais fácil dizer do que fazer) .

• Em projetos proprietários que seria desastroso se todo o repositório se torna disponível publicamente. Ainda mais se um programador descontente ou malicioso se apodera de um repositório clonado. código de fuga Fonte é uma dor severa para as empresas proprietárias. DVCS de torna este simples simples como você só precisa clonar o repositório, enquanto alguns sistemas CM (como ClearCase) tenta restringir o acesso. No entanto, em minha opinião, se você tem uma quantidade suficiente de disfuncionalidade em sua cultura de empresa, em seguida, sem controle de versão no mundo irá ajudá-lo contra vazamento de código-fonte.

Answer 5

Durante minha pesquisa para o SCM certo, eu encontrei os seguintes links para ser de grande ajuda:

1. melhor SCM Initiative: Comparação. Comparação de cerca de 26 sistemas de controle de versão.
2. Comparação de software de controle de revisão . Artigo da Wikipédia comparando cerca de 38 sistemas de controle de versão cobrindo tópicos como diferenças técnicas, características, interfaces de usuário, e muito mais.
3. sistemas de controle de versão distribuído . Outra comparação, mas centrou-se principalmente em sistemas distribuídos.

Answer 6

Em certa medida, os dois esquemas são equivalentes:

• Uma distribuídos VCS pode trivialmente emular um centralizado se você apenas empurrar sempre as alterações a alguns repositório montante designado após cometer cada local.
• A centralizados VCS normalmente não irá ser capaz de emular um distribuída tão naturalmente, mas você pode obter algo muito semelhante, se você usar algo como colcha em cima dela. Quilt, se você não está familiarizado com ele, é uma ferramenta para o gerenciamento de grandes conjuntos de remendos em cima de algum projeto upstream. A idéia aqui é que os DVCS cometer comando é implementado através da criação de um novo patch, eo comando impulso é implementado por cometer cada pedaço excepcional para os VCS centralizado e, em seguida, descartar os arquivos de patch. Isso soa um pouco estranho, mas na prática ele realmente funciona bastante bem.

Dito isto, há um par de coisas que DVCSes tradicionalmente fazem muito bem e que VCSes mais centralizados fazer um pouco de um hash. A mais importante delas é provavelmente ramificação: a DVCS fará com que seja muito fácil de ramificar o repositório ou ramos de mesclagem que não são mais necessários, e irá acompanhar a história enquanto você fazê-lo. Não há nenhuma razão específica para que um esquema centralizado teria problemas com isso, mas, historicamente, ninguém parece ter bastante acertado ainda. Se isso é realmente um problema para você depende de como você está indo para organizar o desenvolvimento, mas para muitas pessoas é uma consideração importante.

A outra vantagem postulada de DVCSes é que eles trabalham offline. Eu realmente nunca tinha muito uso para isso; Eu, principalmente, fazer o desenvolvimento, quer no escritório (assim do repositório na rede local) ou em casa (por isso há ADSL). Se você faz um monte de desenvolvimento em laptops enquanto viajam, em seguida, isso pode ser mais de uma conta para você.

Não há realmente muito muitas armadilhas que são específicos para DVCSes. Há uma tendência ligeiramente maior para as pessoas a ir tranquilo, porque você pode cometer sem apertar e é fácil acabar polimento coisas em privado, mas para além de que não tivemos muitos problemas. Isso pode ser porque nós temos um número significativo de desenvolvedores de código aberto, que geralmente são familiarizados com o modelo de patch-trading de desenvolvimento, mas de entrada desenvolvedores de código fechado também parecem pegar coisas razoavelmente rápido.

Answer 7

VCS distribuídos são atraentes de muitas maneiras, mas uma desvantagem que será importante para a minha empresa é a questão do gerenciamento de arquivos não-mergable (tipicamente binário, documentos, por exemplo, Excel). Subversion lida com isso, apoiando o "svn: needs-lock" de propriedade, o que significa que você deve obter um bloqueio para o arquivo não-mergable antes de editá-lo. Isso funciona bem. Mas esse fluxo de trabalho exige um modelo de repositório centralizado, o que é contrário ao conceito DVCS.

Então, se você quiser usar um DVCS, não é realmente apropriado para o gerenciamento de arquivos que são não-mergable.

Answer 8

Eu tenho usado subversão por muitos anos agora e eu estava realmente feliz com isso.

Em seguida, o zumbido GIT começou e eu só tinha de testá-lo. E para mim, o principal ponto de venda foi ramificação. Oh garoto. Agora eu já não necessidade de limpar meu repositório, voltar uma versão poucas ou nenhuma das coisas bobas que eu fiz quando usando subversão. Tudo é mais barato em DVCS. Tentei, apenas, fósseis e git embora, mas eu tenho Perforce usado, CVS e Subversion e parece que DVCS todos têm realmente barato ramificação e marcação. Não é mais preciso copiar todo o código para um lado e, portanto, a fusão é apenas uma brisa.

Qualquer DVCS pode ser configurado com um servidor central, mas o que você é, entre outras coisas

Você pode checkin qualquer pequena mudança que você gosta, como Linus diz que se você precisa usar mais de uma frase para descrever o que você fez, você está fazendo muito. Você pode ter o seu caminho com o código, ramo, merge, clone e testar todos localmente, sem causar qualquer um baixar grande quantidade de dados. E você só precisa empurrar as mudanças finais no servidor central.

E você pode trabalhar sem rede.

Assim, em breve, usando um controle de versão é sempre uma coisa boa. Usando DVCS é mais barato (em KB e largura de banda), e eu acho que é mais divertido de usar.

Para git checkout: http://git-scm.com/
Para Fossil check-out: http://www.fossil-scm.org
Para finalizar compra Mercurial: https://www.mercurial-scm.org

Agora, só posso recomendar sistemas DVCS, e você pode facilmente usar um servidor central

Answer 9

O principal problema (além da questão da largura de banda óbvio) é propriedade .

Isso é ter a certeza de diferentes local (geográfico) não estão funcionando no mesmo elemento que o outro.

O ideal é que a ferramenta é capaz de propriedade atribuir a um arquivo, um ramo ou mesmo um repositório.

Para responder os comentários de esta resposta, você realmente deseja que a ferramenta para dizer-lhe quem possui o quê, e então comunicar (através de telefone, mensagens instantâneas ou e-mail) com o local distante.
Se você não tem mecanismo de propriedade ... você vai "comunicar", mas muitas vezes demasiado tarde;.) (I .: depois de ter feito o desenvolvimento simultâneo de um conjunto idêntico de arquivos no mesmo ramo O cometem pode ficar confuso)

Answer 10

Para mim esta é uma outra discussão sobre um gosto pessoal e é bastante difícil de ser realmente objetiva. Eu pessoalmente prefiro Mercurial sobre os outros DVCS. Eu gosto de ganchos de gravação na mesma língua que Mercurial está escrito no e a sobrecarga de rede mais pequena - apenas para dizem que algumas das minhas próprias razões.

Answer 11

Todos estes dias está na onda sobre como DVCSs são superiores, mas o comentário de Craig é importante. Em um DVCS, cada pessoa tem toda a história do ramo. Se você estiver trabalhando com um monte de arquivos binários, (por exemplo, arquivos de imagem ou AVL) isso requer uma enorme quantidade de espaço e você não pode fazer diffs.

Answer 12

Eu tenho um sentimento que Mercurial (e outros DVCS) são mais sofisticados do que os centralizados. Por exemplo, fundindo uma filial em Mercurial mantém o histórico completo do ramo enquanto no SVN você tem que ir para o diretório ramo para ver a história.

Answer 13

Outra vantagem para SCM distribuído mesmo em cenário de desenvolvedor de solo é se você, como muitos de nós lá fora, têm mais de uma máquina que trabalha.

Vamos dizer que você tem um conjunto de scripts comuns. Se cada máquina que você trabalha em tem um clone que puder na atualização demanda e mudar seus scripts. Dá-lhe:

1. uma poupança de tempo, especialmente com chaves ssh
2. uma maneira de diferenças filiais entre sistemas diferentes (por exemplo, Red Hat vs Debian, BSD vs Linux, etc)

Answer 14

W. somas resposta de Craig Trader-se a maior parte, no entanto, acho que o estilo de trabalho pessoal faz uma diferença enorme também. Onde eu trabalho atualmente usamos subversão como nosso Único e Verdadeiro Fonte, no entanto, muitos desenvolvedores usar git-svn em suas máquinas pessoais para compensar a emissão de fluxo de trabalho que temos (falha de gestão, mas isso é outra história). Em qualquer caso. é realmente sobre como equilibrar o que conjuntos de recursos torná-lo mais produtivo com o que as necessidades de organização (autenticação centralizada, por exemplo).

Answer 15

Um sistema não necessariamente impedi-lo de usar ramos separados para fazer o desenvolvimento em centralizado. que não precisa ser uma única cópia fiel da base de código, em vez diferentes desenvolvedores ou equipes podem ter diferentes ramos, galhos legados poderia existir etc.

O que ele faz geralmente média é que o repositório é gerido centralmente -. Mas isso é geralmente uma vantagem em uma empresa com um departamento de TI competente, porque isso significa que não é apenas um lugar para backup e somente um lugar para gerenciar o armazenamento em