O que tem de tão legal em usar um DVCS?

April 22, 2008

Contrariamente aos desejos do nosso editor-chefe, este blog ainda não é o seu ponto único de informação sobre tecnologia. Se fosse, você estaria perdendo muita informação interessante que foi produzida em outros lugares. Por exemplo: muitas pessoas estão passando a adotar software para gerenciamento distribuído de código e controle de versão. Tendo em vista que nosso editor-chefe é um usuário de CVS e SVN, não faz muito sentido para ele acompanhar as experiências das pessoas que estão adotando sistemas que se fundamentam em outra arquitetura básica, logo ele terá pouca oportunidade para escrever a respeito.

Esse não é um texto para falar sobre as vantagens técnicas de usar sistemas distribuídos de versão (Distributed Version Control System – DVCS) como o Git, Darcs ou Mercurial. Já existe muito material que você pode encontrar por aí, como por exemplo uma apresentação em vídeo do próprio Linus Torvalds sobre o Git e suas vantagens. O que eu quero é justamente comentar sobre os princípios que levaram Torvalds a desenvolver um sistema completamente novo. De acordo com Linus, sistemas distribuídos não são melhores por questões tecnológicas ou de engenharia avançada, mas são melhores por princípios da arquitetura: “Com sistemas centralizados”, diz ele, “o desenvolvedor tem que lidar com questões que podem se tornar problemas políticos – saber quem pode ter acesso ao sistema; quem pode ter acesso de escrita; quem vai ser o responsável por determinados subsistemas, etc. Em sistemas distribuídos, isso não acontece. Cada desenvolvedor é dono do seu próprio repositório e decide livremente de quem ele irá puxar suas alterações. Não existe um repositório canônico, oficial. O meu repositório de código é tão bom quanto o dos desenvolvedores que estão trabalhando em repositórios de quem eu colaboro.”

Uma outra questão – fundamentalmente importante – é a questão da confiança. Diz Torvalds: “Eu não preciso mais ficar verificando a qualidade de cada patch que entra na minha árvore de código. Eu posso puxar qualquer coisa que venha da árvore de Andrew Morton (desenvolvedor principal da versão 2.6 do kernel do Linux) sem medo de causar prejuízo em meu código, pois eu confio em Andrew.”

Esse é um argumento estranho, mas muito poderoso: nós podemos confiar em uma, duas, dez pessoas. Mas não podemos confiar em centenas ou milhares de pessoas. Confiança não é escalável. Podemos até confiar em alguém desconhecido indiretamente (o amigo do meu amigo…) mas esse critério não resiste por muitas iterações. É esse o ponto que torna sistemas que se baseiam em arquiteturas distribuídas melhores.

Não importa o quão superior ou madura seja a implementação de um sistema centralizado, ele jamais terá “trabalhe apenas com as pessoas em que você confia” como uma feature. É impossível obter isso em um sistema centralizado, por design. A killer feature de um DVCS é a possibilidade de gerenciar seus projetos usando o seu grau de confiança nas pessoas.

posted in Design by Raphael Lullis

Follow comments via the RSS Feed | Leave a comment | Trackback URL

  • Sérgio

    Esse negócio de confiança é muito complicado realmente. Primeiro pelos argumentos que citou, com ser expansível a um número grande de pessoas.

    Segundo pois não é uma coisa, um sentimento, que seja recíproco 100% das vezes.

    Os interesses das pessoas sempre são diferentes em algum nível, mesmo que elas falem que não são.

  • http://job4dev.com Raphael

    Bem lembrado, Sérgio. Confiança não é algo simétrico. Vou guardar essa pro próximo texto.

  • http://www.via6.com/topico.php?tid=175591 Miguel via Rec6

    Log4Dev » O que tem de tão legal em usar um DVCS?…

    Sistemas distribuídos de controle de versão já são uma realidade. Basta ver projetos como Mercurial e Git sendo utilizados a pleno vapor em projetos grandes, como o próprio kernel do linux. Pode parecer mais bagunça, mas não é. …

  • http://swen.uwaterloo.ca/~ttonelli/ Bart

    Eu sei que talvez seja meio off-topic, mas essa conversa me lembrou do projeto Jazz (http://jazz.net), que visa dar suporte a desenvolvimento distribuido. Basicamente, o Jazz acrescenta funcionalidades ao Eclipse que ajudam o desenvolvimento colaborativo de aplicações.

    Eu ainda não tive tempo de ler em detalhes, portanto não sei que tipo de suporte eh provido pra repositórios de código fonte (não acredito que eles vão ficar no CVS/SVN, já que um sistema distribuído me parece mais condizente com a mentalidade do Jazz).

    Aqui uma entrevista com o Erich Gamma sobre o Jazz: http://www.theserverside.com/tt/talks/videos/ErichGammaText/interview.tss

  • http://bpfurtado.livejournal.com Bruno

    Mas claramente os esquema DVCS não se aplica para uma enorme gama de projetos desenvolvidos por empresas tradicionais.

    O perfil de um projeto como o kernel do Linux (O linux é o kernel, mas enfim…) é beeem singular eu diria, e distindo do tipo de projeto com o qual a maioria de nós lida no horário comercial.

  • Miguel Galves

    Não me parece tão claro Bruno. Não que esta undança de paradigma me pareça obvia e simples no inicio. Mas me parece viavel, e eu consigo pensar em N casos onde um sistema desses resolve muitas coisas, em ambientes corporativos. Por favor, explique melhor o seu ponto.

  • Raphael

    Bruno,

    Aplica, sim. Não há nada que impeça você de adotar uma política dentro da empresa em fazer com que um dos repositórios seja o repositório “oficial”. A ferramenta é a mesma, apenas com o uso degenerado.

  • http://bpfurtado.livejournal.com Bruno

    Senhores,

    Antes de mais nada, de uma maneira bem informal, qual o problema encontrado no uso de ferramentas de controle de versão que vocês acham que é resolvido pelo esquema descentralizado “da coisa”??

  • Raphael

    Veja o vídeo do Linus. É bastante esclarecedor.

  • http://bpfurtado.livejournal.com Bruno

    Pô Raphael, se é algo tão latente assim você não pode adiantar nada em algumas frases? Para quem defende a idéia o mínimo é conseguir dar um resumo da ópera…

  • Raphael

    Tá bom, Bruno, já que você insiste:

    • Facilidade de merging. O pessoal do SVN adora fazer propaganda falando sobre o quanto é fácil criar um novo branch, se esquece que o que realmente importa é poder fazer merge de novo. Diz Linus que merge é muito mais fácil de se fazer com o Git.

    • Possibilidade de poder criar um histórico de changesets menores e mais relacionados. Cada pequena mudança que você faz pode ser um commit no seu repositório local.

    • Possibilidade de fazer “cherry-picking”, i.e, fazer merge apenas de parte de um changeset.

    Tá bom, ou quer mais?

  • http://bpfurtado.livejournal.com Bruno

    My best practice for branching: don’t do it.

    Mas concordo que projetos como o Kernel do linux usam esta pratica extensivamente, e eu realmente creio que eles tem seus motivos.

    Dizer que é mais fácil fazer é fácil, mas porque é mais fácil? O que ele faz de diferente neste sentido? well…

    Cada pequena mudança que você faz pode ser um commit no seu repositório local.

    Cada pequena mudança que eu faço também pode ser um commit no meu repositório central, qual a diferença?

    - Possibilidade de fazer “cherry-picking”, i.e, fazer merge apenas de parte de um changeset.

    Na boa Raphael, você sente realmente muita falta de fazer “cherry-picking” no seu dia-a-dia?

    Comentados estes pontos, volto a perguntar, o git resolve problemas sérios que você enfrenta diariamente graças ao fato de você usar um repositório centralizado?

  • Raphael

    Olha só: o lance é que você deixa a ferramenta estabelecer a priori quais são as coisas que você pode ou não fazer.

    My best practice for branching: don’t do it.

    Por que não? Nesse exato instante o meu projeto atual tem – só para mim – quatro branches! Uma para a versão facebook do aplicativo, um com os arquivos de configuração para a máquina de dev, outro para o site principal, outro para experimentar com código com outras idéias…

    E eu crio “a vonts”. Pq eu sei que é fácil fazer merge no mercurial. Se a ferramenta não me desse esse poder, até pensaria que você teria razão na sua “best practice”. Mas já que a ferramenta não me prende…

    Cada pequena mudança que eu faço também pode ser um commit no meu repositório central, qual a diferença?

    Pode. Mas digamos que você e uma outra pessoa da equipe estejam trabalhando em vários arquivos que se sobrepõem. Se você quiser diminuir o tamanho do changeset por commit, você corre o risco de ter que ficar fazendo resolução de conflitos a cada commit que quiser fazer. Se o repositório for só seu, isso não existe.

    Na boa Raphael, você sente realmente muita falta de fazer “cherry-picking” no seu dia-a-dia?

    Eu fiz um, hoje. Estava no meio de uma alteração em uma parte do sistema. Apareceu um bug que eu precisava resolver. Eu resolvi o bug no meu repositório de dev. Só puxei para o repo de produção os changesets relacionados à correção de bug, e deixei a parte relacionada as novas mudanças que não estão completas.

  • http://bpfurtado.livejournal.com Bruno

    Bom, você ainda não disse porque é tão mais fácil fazer merges no Mercurial.

    Espero que a resposta não seja: “porque eu faço merges apenas no meu repositório local”. Porque isto é uma ilusão, se existem outros repositórios então um dia um merge com eles deverá ser feito (do contrário eles nem precisariam existir, hehe) e quanto mais este dia demorar para chegar, mais doloroso será o merge.

    Se você curte fazer branches “a vonts”, well, eu certamente prefiro recorrer a eles como última opção, mesmo merges num repositório local, só seu, podem ser bem complicados (mover arquivos de diretório me vem em mente…).

    Aplicar apenas um conjunto de changesets para um ramo principal de um repositório me parece realmente algo útil, mas para uma equipe distribuída (fisicamente até), com vários membros trabalhando em diferentes arquivos e em paralelo, já para uma equipe de um desenvolvedor só…

    Pela sua descrição do tal “cherry-picking”, isto em nada difere do merge de algumas versões específicas de alguns repositórios em um repositório destino, o que no final nada mais é que um merge tradicional (só que vários de fontes diferentes). Não entendi o porquê do nome diferenciado.

    E de novo, falar que merges são mais fáceis porque você na verdade fica adiando um merge com outros repositórios enquanto faz merges apenas localmente é balela, cedo ou tarde merges com outros repositórios (e portanto com código de outros desenvolvedores) virão, ai é exatamente igual ao merge com um repositório centralizado.

    Eu, como já disse, vejo o valor disto para projetos como o Kernel, para empresas “tradicionais” eu realmente acho que pode não ser necessário, e se for, requer desenvolvedores de um nível maior do a média que eu tenho visto, sem dúvidas (IMHO).

    Um DVCS ajuda um perfil de trabalho em equipe, mas não some magicamente com a complexidade dos merges, apenas fatora um pouco sua aplicação, e requer um esforço de manutenção até relativamente maior (fico pensando em como manter neste cenário o repositório a partir do qual o software realmente será construído, aquele a partir do qual a versão oficial da aplicação será gerada…).

  • Raphael

    Bruno, acho saudável ser cético em relação as novidades. Mas você não está sendo apenas cético. Você está querendo racionalizar em torno do esquema que você está acostumado a trabalhar.

    Por exemplo: não faço só merge em repositório local. Faço merge ENTRE repositórios, também. Você está sendo preconceituoso no sentido mais geral do termo – julgando algo antes mesmo de ter contato real.

    Cherry-picking não é fazer merge de diferentes repositórios, também. É diferente. Seria o equivalente a poder dizer “Faça um svn update para revisão 16, mas apenas do arquivos foo.c e bar.c. O restante da pasta eu quero na revisão 18″.

    É por isso que eu prefiro apontar você para outras fontes, ao invés de querer ficar escrevendo o que já foi escrito em outros lugares. Você só vai entender as diferenças e poder fazer um julgamento adequado quando tiver mais informação do que um simples “resumo da ópera”.

  • Miguel Galves

    Bruno,

    gostaria de ressaltar aqui uma diferença de postura entre a gente…

    Eu, assim como vc, nunca mexi ou vi um DVCS de perto. E eu tb fiquei bastante cético em relação a se isso funcionaria ou não.

    Ao contrário de vc, eu imagino alguns usos interessantes.

    Mas uma coisa que me assusta é que vc baseia sua argumentação em 3 pontos: um DCVS não se encaixa no esquema de “empresas tradicionais”, programadores medianos não seriam capazes de usar um sistema desses e esta ferramenta não traz nada que um sistema centralizado já não ofereça.

    Em relação ao terceiro ponto, pode ser verdade. Não sei. Mas acho que isso é uma questão de experimentar, usar um pouco, ver qual é. Me parece impossível dar um veredito final assim, sem mais nem menos.

    Mas os dois outros pontos me preocupam mais. Porque nós estamos aqui tentando discutir sobre novas tecnologias, sobre novos caminhos. É o oposto do que empresas tradicionais ou programadores medianos. Estes em geral não criam tecnologia, eles seguem o que ta na moda. E esta não pode ser nossa postura. Como eu disse no meu ultimo post, eu sou arrogante o suficiente (e metido a besta) para achar que estou entre os profissionais de tecnologia que tem capacidade para criar novas coisas. E acho que vc, o Lullis, o Capitanio, e todos os leitores deste blog também. Sendo assi, não podemos nos balizar pelo o que empresas tradicionais ou programadores medianos pensam.

    Pra finalizar, dois comentários:

    1) Vc se espantaria se visse o número de “empresas tradicionais” que nem CVS usam….é desnessário, segundo elas.

    2) Vc diz que um sistema distribuido é complexo demais para programadores medianos. Deixa a entender que um CVS ou SVN é suficientemente fácil para que qualquer idiota possa usar. Acho isso uma baita sacanagem com estas ferramentas. Elas requerem uma certa prática, e os estragos que mal programador pode fazer em um CVS ou SVN são enormes. O ponto é que os programadores, mesmo os piores, aprenderam às duras custas usar estas ferramentas pq isto foi imposto pelo mercado, como condição sine qua non para exercerem suas funções. E não os programadores medianos que adotaram a ferramenta pq eles a acharam magnifica e intuitiva.

    Acredite: a mediocridade não cria nada, apenas segue o padrão vigente. As grandes evoluções de tecnlogia foram feitas quebrando paradigmas.

  • http://bpfurtado.livejournal.com/ Bruno
    Eu, assim como vc, nunca mexi ou vi um DVCS de perto. E eu tb fiquei bastante cético em relação a se isso funcionaria ou não.

    Estou um passo antes de ser cético, queria saber o problema que o Raphael (ou qualquer um queira falar) acredita que um DVCS endereça. E dado este problema, que mecanismos/método o DVCS oferece para resolvê-lo.

    Ao contrário de vc, eu imagino alguns usos interessantes.
    Eu disse que para o desevolvimento do Kernel (Linux) ele realmente deve ser útil.
    Mas uma coisa que me assusta é que vc baseia sua argumentação em 3 pontos: um DCVS não se encaixa no esquema de “empresas tradicionais”, programadores medianos não seriam capazes de usar um sistema desses
    Yeap, ainda acho isto.
    e esta ferramenta não traz nada que um sistema centralizado já não ofereça.
    Se assim fosse eu não teria dito que para um desenvolvimento com o perfil do Kernel (Linux) o Git se aplica.
    Em relação ao terceiro ponto, pode ser verdade. Não sei. Mas acho que isso é uma questão de experimentar, usar um pouco, ver qual é. Me parece impossível dar um veredito final assim, sem mais nem menos.
    Não dei um veredicto, eu perguntei qual o problema que um DVCS resolve, com relação a sua contrapartida “centralizada” e como ele resolve isto, que mecanismos ou praticas ele oferece?
    Mas os dois outros pontos me preocupam mais. Porque nós estamos aqui tentando discutir sobre novas tecnologias, sobre novos caminhos. É o oposto do que empresas tradicionais ou programadores medianos. Estes em geral não criam tecnologia, eles seguem o que ta na moda. E esta não pode ser nossa postura. Como eu disse no meu ultimo post, eu sou arrogante o suficiente (e metido a besta) para achar que estou entre os profissionais de tecnologia que tem capacidade para criar novas coisas. E acho que vc, o Lullis, o Capitanio, e todos os leitores deste blog também. Sendo assi, não podemos nos balizar pelo o que empresas tradicionais ou programadores medianos pensam.
    Miguel, estou sendo bem prático aqui, se o post elogia tanto os tais DVCS então meus questionamentos procedem como esperado. Para achar alguma coisa “legal” eu preciso saber um mínimo dela. No post e respostas subseqüentes eu realmente não encontrei “O que tem de tão legal em usar um DVCS?”.
    Pra finalizar, dois comentários: 1) Vc se espantaria se visse o número de “empresas tradicionais” que nem CVS usam….é desnessário,
    Na boa, eu nem chamo isto de empresa de software, talvez uma pastelaria de software, uma padaria de programas, algo do tipo, hehe.

    segundo elas. 2) Vc diz que um sistema distribuido é complexo demais para programadores medianos. Deixa a entender que um CVS ou SVN é suficientemente fácil para que qualquer idiota possa usar. Acho isso uma baita sacanagem com estas ferramentas. Elas requerem uma certa prática, e os estragos que mal programador pode fazer em um CVS ou SVN são enormes.

    O programador mediano faz apenas commits, updates, talvez uns diffs, log… Quiçá um merge vez ou outra hehe. Isto, nestas proporções, realmente um mediano consegue fazer. Já as outras atividades isto requer alguém além mais preparado e experiente.

    O ponto é que os programadores, mesmo os piores, aprenderam às duras custas usar estas ferramentas pq isto foi imposto pelo mercado, como condição sine qua non para exercerem suas funções.
    Aprenderam o básico, como eu descrevi acima.
    E não os programadores medianos que adotaram a ferramenta pq eles a acharam magnifica e intuitiva. Acredite: a mediocridade não cria nada, apenas segue o padrão vigente. As grandes evoluções de tecnlogia foram feitas quebrando paradigmas.
    Concordo plenamente, mas eu realmente quis me ater a questões práticas sobre um DVCS apenas, já seria um bom desfecho para este post.

  • Raphael

    Bruno, você está comparando “apples and oranges”.

    Você está querendo que eu diga alguma coisa na linha “com um DVCS você resolve o problema XYZ que as pessoas tem no processo ABC que surge por usar o CVS/SVN”.

    Esqueça isso. A idéia do post é justamente que o interessante é a mudança do processo. O ganho (o “legal”) é justamente a mudança da forma do gerenciamento de sua base de código.

    Se isso para você não é relevante, tudo bem. Se você está satisfeito com o modelo centralizado, tudo bem. Não precisa mudar. Ninguém vai lhe tirar o emprego por causa disso, ok?

  • Bruno da Silva

    Acho bem interessante o “software para gerenciamento distribuído de código e controle de versão” … acho que realmente deve ser muito pratico pra um projeto com poucos desenvolvedores e com muita confianca entre si… ateh mesmo posso dizer que um projeto pequeno um sistema distribuido funcionaria bem..

    mas pra o projeto mediano , grande com uma variadade de competencias e experiencias um sistema centralizado eh bem melhor.

  • Raphael

    Bruno da Silva,

    Não me leve a mal, mas eu tenho que perguntar: a sua afirmação é baseada em alguma experiência, estudo, ou mero “achismo”?

  • Bruno da Silva

    Rafael ,

    experiencia… se vc prestar atencao ao q linus diz no uso em sistemas comercias ele nada menos define centralizacoes pra o codigo se vc quiser usar SDCF “sistemas distribuidos de controle de fonte”…

    acho realmente o cvs ruim… svn faz o mesmo um pouco melhor… mais pra uma empresa q todos trabalham juntos 9.. as 5pm atende muito bem…

    SDCF atende perfeitamente a projetos open source.. que de fato estao os dev distribuidos e conectados ou naum …

  • Raphael

    Ok. Creio que você tem experiência com sistemas como SVN. Mas estou perguntando se você tem experiência com algum sistema distribuído.

    Afinal de contas, só podemos fazer afirmações categóricas como a sua (pra o projeto mediano , grande com uma variadade de competencias e experiencias um sistema centralizado eh bem melhor.) quando nós temos base de comparação, não é mesmo?

blog comments powered by Disqus

Switch to our mobile site

 
Powered by Wordpress and MySQL. Theme by Shlomi Noach, openark.org