Você usa controle de versão distribuído?

https://stackoverflow.com/questions/26845

09-06-2019
|

Pergunta

Gostaria de ouvir as pessoas que usam controle de versão distribuído (também conhecido como controle de revisão distribuído, controle de versão descentralizado) e como o encontram.O que você está usando, Mercurial, Darcs, Git, Bazaar?Você ainda está usando?Se você já usou rcs cliente/servidor no passado, acha que é melhor, pior ou apenas diferente?O que você poderia me dizer que me faria entrar no movimento?Ou então, estou interessado em ouvir pessoas com experiências negativas também.

Atualmente estou pensando em substituir nosso atual sistema de controle de origem (Subversion), que é o ímpeto para esta questão.

Eu estaria especialmente interessado em qualquer pessoa que o tenha usado com colegas de trabalho em outros países, onde suas máquinas podem não estar ligadas ao mesmo tempo e sua conexão é muito lenta.

Se você não tiver certeza do que é controle de versão distribuído, aqui estão alguns artigos:

Introdução ao controle de versão distribuído

Entrada da Wikipédia

Solução

Tenho usado o Mercurial no trabalho e em meus projetos pessoais e estou muito feliz com isso.As vantagens que vejo são:

Controle de versão local. Às vezes estou trabalhando em algo e quero manter um histórico de versões, mas não estou pronto para enviá-lo aos repositórios centrais.Com o VCS distribuído, posso simplesmente me comprometer com meu repositório local até que esteja pronto, sem ramificar.Dessa forma, se outras pessoas fizerem as alterações que eu preciso, ainda poderei obtê-las e integrá-las ao meu código.Quando estiver pronto, envio-o para os servidores.
Menos conflitos de mesclagem. Eles ainda acontecem, mas parecem ser menos frequentes e apresentam menos riscos, porque todo o código é verificado em meu repositório local, portanto, mesmo que eu estrague a mesclagem, sempre posso fazer backup e fazê-lo novamente.
Repos separados como ramificações. Se eu tiver alguns vetores de desenvolvimento em execução ao mesmo tempo, posso simplesmente fazer vários clones do meu repositório e desenvolver cada recurso de forma independente.Dessa forma, se algo for rasgado ou escorregado, não preciso retirar os pedaços.Quando eles estiverem prontos, eu simplesmente os funciono.
Velocidade. O Mercurial é muito mais rápido de trabalhar, principalmente porque a maioria das operações comuns são locais.

É claro que, como qualquer novo sistema, houve alguns problemas durante a transição.Você precisa pensar sobre o controle de versão de maneira diferente de quando usava o SVN, mas no geral acho que vale muito a pena.

Outras dicas

No local onde trabalho, decidimos mudar do SVN para o Bazaar (após avaliação do git e do mercurial).O Bazaar foi fácil de começar, com comandos simples (diferente dos 140 comandos que o git possui)

As vantagens que vemos é a possibilidade de criar filiais locais e trabalhar nelas sem atrapalhar a versão principal.Também podendo trabalhar sem acesso à rede, fazer diferenças é mais rápido.

Um comando no bzr que eu gosto é a extensão shelve.Se você começar a trabalhar em duas partes de código logicamente diferentes em um único arquivo e quiser submeter apenas uma parte, poderá usar a extensão shelve para literalmente arquivar as outras alterações posteriormente.No Git você pode fazer o mesmo brincando no índice (área de teste), mas o bzr tem uma interface de usuário melhor para isso.

A maioria das pessoas relutou em mudar, pois precisava digitar dois comandos para confirmar e enviar (bzr ci + bzr push).Também foi difícil para eles entenderem o conceito de ramificações e fusões (ninguém usa ramificações ou as mescla no svn).

Depois de entender isso, a produtividade do desenvolvedor aumentará.Até que todos entendam isso, haverá um comportamento inconsistente entre todos.

No meu local de trabalho, mudamos do CVS para o Git há cerca de dois meses (a maior parte da minha experiência é com o Subversion).Embora tenha havido uma curva de aprendizado envolvida na familiarização com o sistema distribuído, descobri que o Git é superior em duas áreas principais:flexibilidade do ambiente de trabalho e fusão.

Não preciso estar em nossa VPN, nem mesmo ter conectividade de rede, para ter acesso a recursos completos de controle de versão.Isso significa que posso experimentar ideias ou realizar grandes refatorações onde quer que esteja quando a necessidade surgir, sem ter que me lembrar de verificar aquele enorme commit que criei ou me preocupar em não conseguir reverter quando fizer uma bagunça.

Como as mesclagens são executadas no lado do cliente, elas são muito mais rápidas e menos propensas a erros do que iniciar uma mesclagem no lado do servidor.

Minha empresa atualmente usa Subversion, CVS, Mercurial e git.

Quando começamos, há cinco anos, escolhemos o CVS, e ainda o usamos em minha divisão para nosso ramo principal de desenvolvimento e manutenção de releases.No entanto, muitos de nossos desenvolvedores usam o Mercurial individualmente como uma forma de ter pontos de verificação privados sem o incômodo das filiais do CVS (e particularmente de mesclá-las) e estamos começando a usar o Mercurial para algumas filiais que têm até 5 pessoas.Há uma boa chance de finalmente abandonarmos o CVS em mais um ano.Nosso uso do Mercurial cresceu organicamente;algumas pessoas ainda nem sequer tocam nele, porque estão felizes com o CVS.Todos que experimentaram o Mercurial ficaram satisfeitos com ele, sem muita curva de aprendizado.

O que funciona muito bem para nós com o Mercurial é que nossos servidores de integração contínua (fabricados em casa) podem monitorar os repositórios Mercurial do desenvolvedor, bem como a linha principal.Assim, as pessoas se comprometem com seu repositório, fazem com que nosso servidor de integração contínua verifique e depois publique o conjunto de alterações.Oferecemos suporte a muitas plataformas, por isso não é viável fazer um nível decente de verificações manuais.Outra vantagem é que as mesclagens geralmente são fáceis e, quando são difíceis, você tem as informações necessárias para fazer um bom trabalho na mesclagem.Depois que alguém faz a versão mesclada funcionar, ele pode enviar seus conjuntos de alterações de mesclagem e ninguém mais precisa repetir o esforço.

O maior obstáculo é que você precisa reconectar os cérebros de seus desenvolvedores e gerentes para que eles se afastem do modelo de ramificação linear única.O melhor remédio para isso é uma dose de Linus Torvalds dizendo que você está estúpido e feio se você usar SCM centralizado.Boas ferramentas de visualização de histórico ajudariam, mas ainda não estou satisfeito com o que está disponível.

Mercurial e CVS funcionam bem para desenvolvedores que usam uma mistura de Windows, Linux e Solaris, e não notei problemas com fusos horários.(Realmente, isso não é muito difícil;você apenas usa segundos de época internamente, e eu esperaria que todos os principais sistemas SCM acertassem).

Foi possível, com bastante esforço, importar nosso histórico de CVS principal para o Mercurial.Teria sido mais fácil se as pessoas não tivessem introduzido deliberadamente casos extremos em nosso histórico principal de CVS como uma forma de testar ferramentas de migração de histórico.Isso incluiu a fusão de algumas ramificações do Mercurial no histórico do CVS, para que o projeto pareça estar em uso desde o primeiro dia.

Nosso grupo de design de silício escolheu o Subversion.Eles estão principalmente a oito fusos horários de distância do meu escritório e, mesmo em uma linha dedicada bastante boa entre nossos escritórios, as verificações do SUbversion são dolorosas, mas viáveis.Uma grande vantagem dos sistemas centralizados é que você pode potencialmente inserir grandes binários nele (por exemplo,lançamentos de fornecedores) sem tornar todos os repositórios distribuídos enormes.

Usamos git para trabalhar com o kernel Linux.O Git seria mais adequado para nós quando uma versão nativa do Windows estiver madura, mas acho que o design do Mercurial é tão simples e elegante que vamos continuar com ele.

Não estou usando o controle de origem distribuído, mas talvez estas perguntas e respostas relacionadas forneçam alguns insights:

Eu pessoalmente uso o sistema de controle de origem Mercurial.Estou usando há pouco mais de um ano.Na verdade, foi minha primeira experiência com um VSC.

Eu tentei o Git, mas nunca me empurrei porque achei que era demais para o que eu precisava.O Mercurial é realmente fácil de aprender se você é um usuário do Subversion, pois compartilha muitos comandos com ele.Além disso, acho o gerenciamento dos meus repositórios muito fácil.

Tenho 2 maneiras de compartilhar meu código com as pessoas:

Compartilho um servidor com um colega de trabalho e mantemos um repositório principal para nosso projeto.
Para alguns projetos OSS em que trabalho, criamos patches do nosso trabalho com Mercurial (hg export) e o mantenedor do projeto apenas os aplica no repositório (hg import)

Realmente fácil de trabalhar, mas muito poderoso.Mas geralmente, a escolha de um VSC realmente depende das necessidades do nosso projeto...

Antes de desligarmos as estações de trabalho da Sun para o desenvolvimento de sistemas embarcados, usávamos o EquipeWare solução.TeamWare é uma solução de distribuição completa que usa SCCS como sistema de revisão de arquivos de repositório local e, em seguida, empacota isso com um conjunto de ferramentas para lidar com as operações de fusão (feitas por meio de renomeação de ramificação) de volta aos repositórios centralizados, que podem ser muitos.Na verdade, por ser distribuído, não existe um repositório mestre propriamente dito (exceto por convenção, se você desejar) e todos os usuários têm suas próprias cópias de toda a árvore de origem e revisões.Durante as operações de "reposição", a ferramenta de mesclagem usando diferenças de 3 vias classifica algoritmicamente o que é o quê e permite combinar as alterações de diferentes desenvolvedores que foram acumuladas ao longo do tempo.

Depois de mudar para o Windows como nossa plataforma de desenvolvimento, acabamos mudando para AccuRev.Embora o AccuRev, por depender de um servidor centralizado, não seja verdadeiramente uma solução distribuída, logicamente de um modelo de fluxo de trabalho chega muito perto.Enquanto o TeamWare teria cópias completamente separadas de tudo em cada cliente, incluindo todas as revisões de todos os arquivos, no AccuRev isso é mantido no banco de dados central e as máquinas clientes locais têm apenas a versão atual do arquivo simples para edição local.No entanto, essas cópias locais podem ser versionadas através da conexão do cliente com o servidor e rastreadas de forma completamente separada de quaisquer outras alterações (ou seja:ramificações) criadas implicitamente por outros desenvolvedores

Pessoalmente, acho que o modelo distribuído implementado pela TeamWare ou o tipo de modelo híbrido implementado pela AccuRev é superior às soluções completamente centralizadas.A principal razão para isso é que não existe a noção de ter que fazer check-out de um arquivo ou de ter um arquivo bloqueado por outro usuário.Além disso, os usuários não precisam criar ou definir as ramificações;as ferramentas fazem isso implicitamente para você.Quando há equipes maiores ou equipes diferentes contribuindo ou mantendo um conjunto de arquivos de origem, isso resolve colisões relacionadas a bloqueios "gerados por ferramentas" e permite que as alterações de código sejam coordenadas mais no nível do desenvolvedor, que, em última análise, precisa coordenar as alterações de qualquer maneira.De certa forma, o modelo distribuído permite um "bloqueio" de granularidade muito mais refinada, em vez do bloqueio de granularidade instituída pelos modelos centralizados.

Usei darcs em um grande projeto (GHC) e em muitos projetos pequenos.Eu tenho uma relação de amor/ódio com os darcs.

Vantagens:repositório incrivelmente fácil de configurar.Muito fácil de mover alterações entre repositórios.Muito fácil de clonar e testar 'branches' em repositórios separados.É muito fácil fazer 'commits' em pequenos grupos coerentes, o que faz sentido.Muito fácil de renomear arquivos e identificadores.

Desvantagens:nenhuma noção de história – você não pode recuperar “o estado das coisas em 5 de agosto”.Eu realmente nunca descobri como usar o darcs para voltar a uma versão anterior.

Empecilho:darcs não é escalonável.Eu (e muitos outros) tivemos grandes problemas com o GHC usando darcs.Eu o peguei com 100% de uso da CPU por 9 dias tentando realizar 3 meses em alterações.Tive uma experiência ruim no verão passado, onde perdi duas semanas tentando fazer com que o DARCS funcione e, eventualmente, recorri a repetir todas as minhas mudanças manualmente em um repositório intocado.

Conclusão:darcs é ótimo se você deseja uma maneira simples e leve de evitar dar um tiro no pé em seus projetos de hobby.Mas mesmo com alguns dos problemas de desempenho abordados no darcs 2, ainda não é para força industrial.Não acreditarei realmente em darcs até que a alardeada “teoria das manchas” seja algo um pouco mais do que algumas equações e algumas belas imagens;Quero ver uma teoria real publicada em um local arbitrado.Já passou da hora.

Eu realmente amo o Git, especialmente com o GitHub.É tão bom poder confirmar e reverter localmente.E mesclagens seletivas, embora não sejam triviais, não são terrivelmente difíceis e são muito mais avançadas do que qualquer coisa que Svn ou CVS possam fazer.

Meu grupo de trabalho está usando Git e isso tem feito toda a diferença no mundo.Estávamos usando SCCS e uma pilha enorme de scripts csh para gerenciar projetos bastante grandes e complicados que compartilhavam código entre eles (tentativa, de qualquer maneira).

Com o Git, o suporte a submódulos facilita muitas dessas coisas e apenas um mínimo de scripts é necessário.Nosso esforço de engenharia de lançamento diminuiu muito porque as filiais são fáceis de manter e rastrear.Ser capaz de ramificar e mesclar de maneira barata realmente torna razoavelmente fácil manter uma única coleção de fontes em vários projetos (contratos), ao passo que antes, qualquer interrupção no fluxo típico das coisas era muito, muito cara.Também descobrimos que a capacidade de script do Git é uma enorme além disso, porque podemos personalizar seu comportamento através de ganchos ou scripts que fazem . git-sh-setup, e não parece uma pilha de bobagens como antes.

Às vezes também temos situações em que precisamos manter nosso controle de versão em sites distribuídos e fora da rede (neste caso, laboratórios seguros desconectados), e o Git tem mecanismos para lidar com isso de maneira bastante tranquila (pacotes, o mecanismo básico de clonagem, formatados manchas, etc.).

Parte disso é apenas porque saímos do início dos anos 80 e adotamos alguns mecanismos modernos de controle de versão, mas o Git "fez certo" na maioria das áreas.

Não tenho certeza da extensão da resposta que você está procurando, mas nossa experiência com o Git tem sido muito, muito positiva.

Usando o Subversion com o SourceForge e outros servidores em diversas conexões diferentes com equipes de médio porte, está funcionando muito bem.

Sou um grande defensor do controle centralizado de origem por vários motivos, mas experimentei o BitKeeper em um projeto brevemente.Talvez depois de anos usando um modelo centralizado em um formato ou outro (Perforce, Subversion, CVS), eu tenha achado difícil usar o controle de origem distribuído.

Acredito que nossas ferramentas nunca devem atrapalhar o trabalho real;eles deveriam facilitar o trabalho.Então, depois de algumas experiências dolorosas, desisti.Eu aconselharia fazer alguns testes realmente difíceis com sua equipe antes de balançar o barco, porque o modelo é muito diferente daquele com o qual a maioria dos desenvolvedores provavelmente está acostumada no mundo SCM.

eu usei bazar já faz um tempinho e adorei.A ramificação e a fusão triviais proporcionam grande confiança no uso das ramificações como devem ser usadas.(Eu sei que as ferramentas centrais de vcs deveriam permitir isso, mas as comuns incluindo o subversion não permitem isso facilmente).

bzr suporta vários fluxos de trabalho desde solo, passando por trabalhar como um repositório centralizado até totalmente distribuído.Com cada ramificação (para um desenvolvedor ou recurso) capaz de ser mesclada de forma independente, as revisões de código podem ser feitas por ramificação.

bzr também tem um ótimo plugin (bzr-svn) permitindo que você trabalhe com um repositório Subversion.Você pode fazer uma cópia do repositório svn (que inicialmente demora um pouco, pois busca todo o histórico do seu repositório local).Você pode então criar ramificações para recursos diferentes.Se você quiser fazer uma correção rápida no tronco enquanto estiver no meio do seu recurso, você pode fazer uma ramificação extra, trabalhar nisso e depois mesclar de volta ao tronco, deixando seu recurso incompleto intocado e fora do tronco.Maravilhoso.Trabalhar contra a subversão tem sido meu principal uso até agora.

Observação: eu só o usei no Linux e principalmente na linha de comando, embora deva funcionar bem em outras plataformas, possui GUIs como TartarugaBZR e muito trabalho está sendo feito na integração com IDEs e similar.

Estou brincando com o Mercurial para meus projetos domésticos.Até agora, o que mais gosto é que posso ter vários repositórios.Se eu levar meu laptop para a cabine, ainda terei controle de versão, ao contrário de quando executei o CVS em casa.Ramificar é tão fácil quanto hg clone e trabalhando no clone.

Usando Subversão

O Subversion não é distribuído, então isso me faz pensar que preciso de um link da Wikipedia caso as pessoas não tenham certeza do que estou falando :)

Tenho usado o darcs 2.1.0 e é ótimo para meus projetos.Fácil de usar.Adoro escolher mudanças.

Eu uso Git no trabalho, junto com um de meus colegas de trabalho.O repositório principal é o SVN.Muitas vezes temos que trocar de estação de trabalho e o Git torna muito fácil extrair alterações de um repositório local em outra máquina.Quando trabalhamos em equipe no mesmo recurso, mesclar nosso trabalho é fácil.

A ponte git-svn é um pouco instável, porque ao fazer check-in no SVN ela reescreve todos os commits para adicionar seu comentário git-svn-id.Isso destrói o bom histórico de fusões entre o repositório e o meu do meu colega de trabalho.Prevejo que não usaríamos um repositório central se todos os membros da equipe usassem Git.

Você não disse em qual sistema operacional você desenvolve, mas o Git tem a desvantagem de que você precisa usar a linha de comando para obter todos os recursos.Gitk é uma ótima interface para visualizar o histórico de mesclagem, mas a mesclagem em si deve ser feita manualmente.Os plug-ins do Git-Gui e do Visual Studio ainda não estão tão polidos.

Usamos controle de versão distribuído (SCM de plástico) para cenários de vários locais e desconectados.

1- Multisite:se você tem grupos distantes, às vezes não pode confiar na conexão com a Internet ou ela não é rápida o suficiente e retarda os desenvolvedores.Então, ter um servidor independente que pode sincronizar de volta (o plástico replica ramificações para frente e para trás) é muito útil e acelera as coisas.É provavelmente um dos cenários mais comuns para as empresas, já que a maioria delas ainda está preocupada com práticas “totalmente distribuídas”, onde cada desenvolvedor possui seu próprio repositório replicado.

2- Desconectado (ou verdadeiramente distribuído se preferir):cada desenvolvedor tem seu próprio repositório que é replicado com seus pares ou com o local central.É muito conveniente ir até a localização de um cliente ou simplesmente ir para casa com seu laptop, e continuar podendo trocar de agência, código de checkout e checkin, consultar o histórico, executar anotações e assim por diante, sem precisar acessar a “central” remota. servidor.Então, sempre que você voltar ao escritório, basta replicar suas alterações (normalmente filiais) com apenas alguns cliques.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow