ti-enxame.com

Quais são seus sistemas de controle de versão favoritos?

Esta é mais uma questão de discussão do que uma tentativa real de determinar o "melhor", pois isso varia claramente de acordo com as necessidades da organização. Estou mais curioso sobre os argumentos a favor de diferentes sistemas entre categorias (centralizado versus distribuído, aberto versus proprietário, etc.).

Então, qual você acha que é o melhor sistema de controle de versão?

41
Fishtoaster

Mercurial

Devido à sua capacidade sofisticada de ramificar e mesclar código, é o melhor que já usei. Todo o paradigma DVCS faz muito sentido. Eu não usei o Git, mas acho que ele também se qualifica.

81
epotter

Git

O Git é fantástico, e eu particularmente o recomendaria a qualquer pessoa que trabalhe em projetos de código aberto: é muito mais fácil contribuir com uma pequena alteração pontual em um projeto no Git, especialmente se estiver hospedado no GitHub, do que em lidar com enviando correções sobre o SVN.

Uma grande ressalva para os usuários do Windows: as ferramentas do Git para Windows, embora definitivamente utilizáveis, não são totalmente adequadas. Quando fui forçado a usar o Windows por um tempo, experimentei a interface do Mercurial para Windows com uma ferramenta de integração Hg-Git para poder usar meus repositórios Git e achei muito mais fácil de usar.

72
Gaurav

Aviso: Desde este post, encontrei o Mercurial e o amo muito melhor que o SVN. Portanto, este post está um pouco desatualizado com os comentários do Pro SVN e o anti-DVCS geral, mas o material anti-git ainda é relevante


Sou fã de SVN sobre o Git.

Por quê? Como o SVN era muito mais fácil para um desenvolvedor ou equipe pequena, e o git (especificamente o msysgit) me deixou com um gosto ruim na boca.

Quando eu estava internando em uma pequena loja, fui apresentado ao git no Windows. Percebi imediatamente a quantidade de trabalho necessária para fazê-lo funcionar com o Github. Primeiro, eu tive que gerar uma chave privada ssh, colar a chave pública no Github, abrir o concurso e abrir minha chave privada toda vez que quisesse enviar por push, o que era extremamente irritante.

E eu realmente nunca gostei de baixar o repositório inteiro. Admito que nunca trabalhei com nada grande, mas teria medo de baixar o repositório do KDE no Git se todo o repositório e suas revisões estiverem no meu HD.

Depois, houve o processo confuso de fazer uma confirmação. TMK, eu tive que primeiro "preparar" todos os arquivos que eu queria confirmar (o que foi um saco quando você tinha muitos arquivos, demorei um pouco para encontrar o comando manual para preparar tudo), depois fiz o commit e pressione Push para o main repo (por que isso é uma operação separada ?!).

Você também tinha os dados de confirmação não (!) Muito úteis. Oh, olhe, isso é commit 14f74433245ae17aeea parte da árvore 2167a4934d0a4a7db0de e pai d7042abb4821d3faf600. Que diabos isso significa? Eu deveria ser capaz de descobrir as coisas rapidamente e não ter que consultar alguma documentação estranha.

Falando em documentação, pelo menos quando eu a estava usando, parecia que tudo estava no formato de arquivo linux man, IE confuso e inútil para mim. Eu raramente conseguia encontrar muita ajuda nos documentos e simplesmente recorria para o google.

E com confirmações, a única coisa que eu não gostei foi a falta de números de versão. Agora eu sei que isso se deve ao design do git, mas qualquer software precisa de um número de versão. Ainda me lembro dos marcadores confirmados que apareceriam dizendo "Versão alterada para 1.8.6" ou algo semelhante, mas você ainda não conseguiu criar números. Para mim, ter a versão 1.8.6.5164 (a última parte é o número da revisão) me diz muito mais do que simplesmente 1.8.6 e uma nota dizendo que algo menor mudou, tente

Especificando o software, o programa base no Windows é o msysgit, que é uma interface terrível. Ele me trancou algumas vezes, tinha uma interface horrível e a integração CLI-GUI era, na melhor das hipóteses, duvidosa. Os viciados em linha de comando ao meu redor odiavam ainda mais a GUI.


Agora vamos ver o SVN. E já que estou no Windows e tenho uma conta do Google, especificamente o TortoiseSVN e o Google Code.

Primeiro, complete a integração do Shell para fazer tudo no repositório (e para o pessoal do Linux, o RabbitVCS faz a mesma coisa), nenhuma GUI principal necessária. Obter um repositório é fácil como um checkout, não é necessário SSH (não me lembro se o Github exigia SSH para puxar) e nenhum repositório inteiro + todo o passado confirmado sentado no seu HD.

A confirmação é extremamente fácil, principalmente porque não é necessário SSH ou preparo. Você simplesmente verifica todos os arquivos que deseja, usando a muito útil opção selecionar todos que na minha versão do msysgit não estava disponível, digitar uma mensagem de confirmação e clicar em confirmar. O Google Code solicita suas informações de login (que a maioria dos clientes armazena) e pronto. Simples, fácil e sem SSH

Números de versão? Com um código fácil, você pode adicionar um número de versão e um número de confirmação a todos os caixas, o que facilita muito as coisas. Você também obtém números de versão utilizáveis ​​que realmente mostram uma alteração, por exemplo, 1.8.6.5165 é mais recente que 1.8.6.5164.

Documentação? Bem, é difícil dizer. A tartaruga está documentada, mas eu não me refiro à documentação oficial há tanto tempo que não posso julgar. Ler um guia de introdução simples foi o suficiente para mim.

Mesclar é outra coisa que não posso comparar. Eu tive que fazer isso uma vez no Git quando alguém cometeu uma alteração em um arquivo no qual eu estava trabalhando, mas nunca no SVN.


Qual eu recomendaria? Bem, em grandes equipes, o git tem suas vantagens, principalmente em seu ciclo de desenvolvimento não linear. Em outro projeto, vi 4 programadores começarem em ramificações separadas e depois mesclar todo o código de maneiras muito estranhas que de alguma forma se transformaram na ramificação principal final. O Github e o msysgit tinham uma ferramenta de visualização muito boa para todo o projeto que eu realmente gostei.

Para projetos de desenvolvedor único ou de equipe pequena, o SVN seria o melhor, pois a maioria dos recursos do Gits não é usada e você apenas obtém suas partes negativas. Simplicidade é uma coisa tão agradável

24
TheLQ

A seguinte citação de Q4TD resume bastante para mim:

“Eu amei o Git até tentar. Agora eu amo Mercurial.

- Tor Norbye, The Java Posse Podcast

Além disso, hgsubversion cria um cliente Subversion muito bom para Linux (onde eu costumo usar a linha de comando, ao contrário do Windows, onde costumo usar o TortoiseSVN). A maior vantagem: não .svn subpasta em todas as pastas, apenas uma .hg no nível superior.

Atualização: Em resposta à solicitação de Alex nos comentários para "dizer mais sobre por que o git não funcionou para você e como o Mercurial funcionou melhor":

Eu não diria que o Git não funciona para mim, mas o Murcurial funciona melhor na IMO.

Em poucas palavras, isso é Mercurial:

alt text

e este é o Git:

alt text

E afirmo que o Mercurial fará tudo o que a maioria dos desenvolvedores precisará fazer, sem precisar consultar o manual para descobrir como fazer as coisas cotidianas.

É certo que eu só usei o Git ocasionalmente, mas a comunidade de programação tem enlouquecido com linguagens como Ruby e Python, em parte, por sua concisão e elegância, enquanto o Git parece um camelo que foi projetado por um comitê de camelos.

Bah, agora veja o que você fez? Há discursos por todo o lado. Siga em frente, nada para ver ... nada para ver ...

Atualização 2: E outro propósito Tweet Acabei de encontrar:

"O Git fica mais fácil quando você obtém a idéia básica de que os ramos são endofuncores homeomórficos que mapeiam subvariedades de um espaço de Hilbert."

22
Evan

Não tenho um único "melhor" sistema de controle de versão, mas um único melhor paradigma de VCS.

Eu usei vários sistemas de controle de versão centralizados diferentes e vários sistemas de controle de versão distribuídos diferentes. E posso dizer sem hesitação que ninguém jamais deveria infligir um CVCS a si próprio.

Eu não me importo qual DVCS que você escolhe (meu favorito é o Git), mas faça um favor a si mesmo e use um DVCS. Por um lado: você será muito mais flexível. Os DVCSs podem emular trivialmente um fluxo de trabalho CVCS (apenas nunca bifurcam o repositório e tratam seus repositórios locais apenas como um chache em vez de um bifurcação independente), enquanto a inversão é impossível. E enquanto logicamente, fazer essa emulação deveria carregar alguma sobrecarga (e de fato faz), eu ainda acho mais fácil de usar (para não mencionar muito mais desempenho devido ao local cache) do que qualquer um dos CVCSs que usei.

14
Jörg W Mittag

Não posso dizer que encontrei o melhor software de controle de versão, mas posso dizer para você ficar longe do VSS e do MKS. Ambos são cães que devem ser evitados a todo custo.

11
Walter

Eu não diria o melhor, mas um com características e conceitos muito interessantes.

Fossil é um projeto de controle de versão distribuído, rastreamento de bugs e wiki, construído no banco de dados SQLite como repositório.

7
Maniero

Team Foundation Server

Porque:

  1. É um bom, sólido VCS. (Eu não consideraria o melhor por nenhum meio, mas tem extras legais).
  2. Seu rastreamento de tarefas e erros integrado ao Visual Studio me ajuda a manter o foco e saber no que preciso trabalhar em um único local (aplicar automaticamente um check-in a um bug ou tarefa e fechá-lo é muito bom, embora você possa obtenha plugins para outros sistemas/Eclipse/etc para fazer isso.)
  3. Ele integra tarefas/rastreamento de bugs/projetos diretamente ao Project Server, por isso raramente preciso manter atualizados os planos ou quadros de horários do projeto. As atualizações no Project no Project Server são filtradas automaticamente como tarefas no TFS e no Visual Studio para eu ver automaticamente.
5
Ryan Hayes

Eu usei vários sistemas de controle de versão em minha longa história:

  • RPPT Rolos de fita de papel perfurada). Em uma caixa de sapatos. Eu não estou brincando.
  • PVCS - (Sistema de controle de versão Polytron). O primeiro VCS real que eu usei.
  • SCCS - há muito tempo, não me lembro de nada de excepcional ou bom.
  • RCS - como outros já apontaram, prefere chupar bolas de burro suadas.
  • CVS - foi apenas uma dor quando usado com mais de 2 programadores. melhor característica: rcs2cvs.
  • VSS - funciona, exceto às terças-feiras, quando corrompe todo o repositório.
  • Perforce - custa mais do que meu carro. O VCS em si é aceitável, mas o pessoal de TI idiota que controla todos os aspectos do uso nunca o colocará na minha lista "preferida".
  • SVN - ramificar e mesclar é uma droga, mas em geral é melhor do que qualquer um dos anteriores. Não é tão bom com muitas pequenas mudanças pendentes aguardando revisão.
  • Mercurial - que pouca experiência eu tenho com isso, eu gosto. Eu posso tentar no meu próximo projeto.
  • Git - nunca teve a oportunidade de usá-lo.

Embora alguns fossem horrores, a maioria estava "bem". Eles não ficaram no meu caminho. Contanto que uma ferramenta --- (não torne minha vida significativamente mais difícil, eu realmente não me importo.

O verdadeiro é entender os pontos fortes e fracos de cada um. Entenda o ambiente de destino:

  • distribuído ou local
  • equipe pequena ou grande
  • serviço vcs hospedado ou não
  • fácil integração com outras ferramentas

Joel também fez uma observação importante: Aprenda a ferramenta e seu verdadeiro modelo de uso. Ele lutou poderosamente tentando fazer o Mercurial se comportar como o Subversion.

4
brettmjohnson

Um sistema mais novo que usamos no meu escritório é o Plastic SCM (http://www.plasticscm.com/). Funciona muito bem para nossa pequena equipe e nos dá um ótimo controle sobre todos os aspectos do gerenciamento de fontes.

2
Tom A

SCCS .

Ou, se você não vive em uma caverna nos últimos 38 anos, CSSC .

Sério, minha empresa está usando TeamWare , que é um tipo de pseudo DVCS baseado no SCCS.

Não, não estou brincando.

A Sun mudou para o Mercurial do TeamWare apenas alguns anos atrás. Agora você deve entender por que Java parecia se mover tão devagar.

1
Geoffrey Zheng

MPW: Bem, eu realmente não posso fazer uma revisão apesar dos meus esforços.

Isso aconteceu quando eu estava aprendendo a programar no ensino médio, e o único compilador C++ realmente gratuito que havia era o Macintosh Programming Workbench, que eu mantinha em um disco Zip e inseri o que estava disponível no laboratório da Performa.

O MPW veio com dezenas de ferramentas (nenhuma das quais foi reeditada, que era um download separado) e uma delas era um utilitário de controle de versão. Ele abriu uma pequena janela com uma única linha de texto e você deveria arrastar e soltar seus projetos ou arquivos nela. Não havia nenhuma documentação que eu pudesse descobrir, incomum, considerando que todo o resto parecia ter ótimos documentos e, portanto, nunca descobri como usá-lo.

Esse foi o meu primeiro contato com o VC e o último por um bom tempo. Agora eu uso o git para tudo.

1
SingleNegationElimination

RCS - Sistema de Controle de Revisão

Codificação de solo facilitada.

0
Jé Queue

Eu usei o Visual SourceSafe e odiei, mas era melhor que nada, mas não muito. Nos últimos dois anos, usei algo chamado QCVS da Qumasoft.com, escrito, de propriedade e suportado por Jim Voris, o programador. GUI simples, preço barato, bom suporte.

Apenas faz o trabalho.

0
crosenblum

Não o ClearCase, pelo menos para um sistema Unix/Linux (talvez com o Windows o instalador seja mais fácil). Para mim, foi mais fácil aprender uma nova ferramenta, o Perforce, do que atualizar o servidor ClearCase.

Atualmente, uso o Perforce no trabalho e gosto, mas não faço ideia se é o melhor. A configuração do ambiente da linha de comando e do Perforce Server é um pouco estranha, mas o uso do Visual Client é bastante fácil. Eu gosto de pensar que os usuários têm um tempo bastante fácil para as tarefas diárias; é apenas a configuração inicial que leva algum trabalho.

0
Chance