Quais são seus sistemas de controle de versão favoritos? [fechadas]

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?

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 suponho que ele também se qualifique.

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.

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ã do SVN sobre o Git.

Por quê? Como o SVN era muito mais fácil para um único desenvolvedor ou equipe pequena, 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ário 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 eu quisesse pressionar, o que era extremamente irritante.

E nunca gostei muito de estar desmontando todo o repositório. 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 depois fui para o diretório principal. 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 precisar consultar uma documentação estranha.

Falando em documentação, pelo menos quando eu a estava usando, parecia que tudo estava no formato de arquivo linux man, ou seja, confuso e inútil para mim. Eu raramente conseguia encontrar muita ajuda nos documentos e simplesmente recorria ao 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, a integração completa do shell para fazer tudo no repositório (e para o pessoal do Linux, o RabbitVCS faz a mesma coisa), sem a necessidade de uma GUI principal. 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 opção muito útil selecionar todos que, na minha versão do msysgit, não estava disponível, digita uma mensagem de confirmação e pressiona a confirmação. 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 legal

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

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

        - Tor Norbye, podcast sobre Java Posse

Além disso, o hgsubversion é um bom cliente de subversão para Linux (onde eu costumo usar a linha de comando, diferente do Windows, onde geralmente uso o TortoiseSVN). A maior vantagem: nenhuma .svnsubpasta em todas as pastas, apenas uma .hgno 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:

e este é o Git:

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 tweet apropriado que 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."

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

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

Não me importo com qual DVCS você escolher (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, logicamente, fazer essa emulação deve ter alguma sobrecarga (e de fato tem), ainda acho mais fácil de usar (para não mencionar muito mais desempenho devido ao cache local) do que qualquer um dos CVCSs que usei.

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.

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

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

Team Foundation Server

Porque:

1. É um VCS bom e sólido . (Eu não consideraria o melhor por nenhum meio, mas tem ótimos extras.)
2. Seu rastreamento de tarefas e erros integrado ao Visual Studio me ajuda a manter o foco e saber o que preciso para 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 tenho que 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.

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 excepcionalmente bom ou ruim.
• 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 de seu uso nunca o colocará na minha lista "preferida".
• SVN - ramificar e mesclar é uma merda, 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 era "boa". 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.

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.

SCCS .

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

Sério, minha empresa está usando o 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 o Java parecia se mover tão devagar.

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

Isso aconteceu quando eu estava aprendendo programação 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, o 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.

RCS - Sistema de Controle de Revisão

Codificação de solo facilitada.

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 nosso 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 se divertem bastante com as tarefas diárias; é apenas a configuração inicial que leva algum trabalho.

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.