Artigo
Sistemas de controle de versão
Maringá/PR UEM
amplamente utilizados em muitas áreas, sendo a mais conhecida a de desenvolvimento de softwares de computador. Seu uso permite um maior controle sobre documentos que costumam sofrer atualizações frequentes por várias pessoas, quase sempre remotamente distantes.
Seu uso se tornou, se não recomendado, essencial para todo processo de desenvolvimento de software, e entendê-los é essencial para desenvolver sistemas em equipe.
1. Resumo...2
2. Introdução...4
3. O que são sistemas de controle de versão...5
4. Quando e porque utilizar...7
5. VCS e o processo de software...9
6. Tipos de sistemas de controle de versão...10
6.1. Sistemas de controle de versão centralizados...10
6.2. Sistemas de controle de versão distribuídos...11
6.3. Sistemas de controle de versão embarcados...12
7. Softwares disponíveis no mercado...14
7.1. CVS...14 7.2. Subversion...14 7.3. Mercurial...14 7.4. Bazaar...15 7.5. Git...16 7.6. Outros...17 7.6.1. Darcs... 17 7.6.2. Monotone...17 8. Serviços disponíveis...18 8.1. Github...18 8.2. Gitorious...18 8.3. Google Code...18 8.4. Launchpad...19 8.5. Sourceforge...19 8.6. BitBucket...19 8.7. CodePlex...20
9. A influência do desenvolvimento distribuído...21
10. Ambientes de desenvolvimento e os VCS...21 10.1. Eclipse e VCS...22 11. Operações comuns...24 11.1. Criar um repositório...24 11.2. Copiar o projeto...24 11.3. Buscar modificações...24 11.4. Enviar modificações...24
11.5. Comparar diferentes versões ou revisões...24
11.6. Obter o histórico de modificações...24
11.7. Criar forks...25
11.8. Executar merges...25
12. Conclusão...26
Ilustração 2: Arquitetura de um sistema centralizado...11 Ilustração 3: Arquitetura de um sistema distribuído...12
2 Introdução
O processo de desenvolvimento de software mudou muito desde seu surgimento, há décadas atrás. Pode-se até dizer que hoje tem um destaque maior do que o próprio desenvolvimento de hardware, embora ainda seja muito dependente deste.
Com uma complexidade cada vez maior, é natural que haja uma maior necessidade maior de gerenciarmos o processo de desenvolvimento de um software. E é neste ponto que os sistemas de controle de versão ganham destaque.
Um sistema de controle de versão – VCS, do inglês Version Control System – é um software capaz de gerenciar a criação e modificação de documentos, sejam eles textos, imagens, arquivos binários, tanto no espectro temporal quanto na manipulação destes documentos por vários membros de uma mesma equipe.
Por armazenar todo o histórico de modificações destes documentos e permitirem seu acesso em qualquer momento do projeto, um VCS também atua como ferramenta de backup destes documentos.
Recentemente o controle de versão foi embutido em alguns sistemas operacionais para gerenciar, em baixo nível, os arquivos do sistema de arquivos.
Usualmente são classificados em sistemas centralizados ou sistemas distribuídos, devido à forma forma como organizam o acesso aos documentos versionados.
3 O que são sistemas de controle de versão
De maneira breve, um sistema de controle de versão é um software capaz de gerenciar a criação e o desenvolvimento de um ou mais documentos no decorrer do tempo. Embora sua principal utilização atualmente seja no controle de códigos de software de computador, não existem restrições quanto ao seu uso, podendo ser utilizado para versionar qualquer tipo de arquivo ou mesmo embutido em outras aplicações que visem o gerenciamento de documentos do usuário, tais como editores de textos, editores de imagens ou vídeo, etc.
Tradicionalmente os VCS contam com uma base de dados chamada de repositório. É esta base que armazena todo o conteúdo dos documentos versionados, e todo documento versionado deve estar registrado neste repositório.
Diferentes VCS tratam seus repositórios de maneiras igualmente diferentes.
Para os sistemas centralizados, este repositório é único e encontra-se num local comum a todos membros da equipe, e deve estar sempre disponível para que estes possam efetivar as modificações feitas nos documentos versionados.
Estes membros têm em seus computadores uma cópia de uma determinada versão dos documentos contida no repositório. A esta cópia dá-se o nome de cópia de trabalho.
Já os sistemas distribuídos (DVCS, do inglês distribuited version control system), embora permitam uma simulação de um sistema centralizado (podendo substituir completamente o uso este), não possuem o conceito de cópia de trabalho, tratando cada cópia como um repositório completo dos documentos, contendo todo o histórico dos documentos contidos naquele repositório.
Estes sistemas são chamados distribuídos por não funcionarem numa arquitetura cliente-servidor, mas numa arquitetura peer-to-peer, onde cada membro é capaz de colaborar com o repositório de qualquer outro membro, sem requerer um serviço central. E esta é a principal razão do sucesso desta arquitetura nos últimos anos.
Outra utilização comum de VCS ocorre em aplicações baseadas na manipulação de documentos. Neste caso não existe o conceito explícito de repositório ou cópia de trabalho: o próprio arquivo atua como um repositório, contendo não só a versão corrente do conteúdo do arquivo – como uma monografia -, mas todo o histórico de modificação do mesmo. Neste caso a própria aplicação se encarrega de permitir ao usuário o gerenciamento e manipulação de todas estas versões de seu documento, contidas num único arquivo-repositório.
manipulados por poucas pessoas ou mesmo um só membro, têm evoluído de forma a apresentar recursos que facilitem o gerenciamento de grandes projetos onde trabalham várias equipes de até milhares de membros.
Com o advento do software livre, modalidade de desenvolvimento e distribuição de software que permite que pessoas fora de uma equipe local possam contribuir com no desenvolvimento de um projeto, os VCSs se tornaram indispensáveis neste processo.
4 Quando e porque utilizar
A razão mais imediata para se utilizar um VCS é, no contexto do desenvolvimento de um software, facilitar o controle sobre o código que está sendo desenvolvido, e utilizá-lo como método de acompanhamento deste desenvolvimento, como será visto adiante. Por meio do histórico de desenvolvimento, é possível saber o que está sendo modificado, por quem e porque e quando.
Mas há outras características interessantes, como por exemplo o melhor gerenciamento de equipes trabalhando num mesmo projeto, mas em diferentes funcionalidades, sem que precise criar projetos distintos. De tempos em tempos, quando as funcionalidades se tornam estáveis, é realizado o processo de merge, onde o código da funcionalidade desenvolvida fora da árvore principal do processo é unida a esta.
Junto a este processo de merge, ou mesclagem, em tradução livre, surgem problemas como os conflitos de código, quando um mesmo código foi modificado por diferentes membros. Um bom
VCS apresenta aos seus usuários mecanismos de resolução destes conflitos.
Complementar ao processo de merge, existe o fork, ou, em forma traduzida, bifurcação. Um
fork constitui na criação de uma cópia de um repositório que desenvolverá uma versão alternativa
do projeto versionado. Pode ser ou não criado no intuito de sofrer processo de merge com o projeto inicial ou mesmo com outro fork.
Processos de fork/merge são especialmente e frequentemente utilizados no desenvolvimento de softwares de código aberto1.
Ilustração 1: Processo de fork/merge e tempo de linha de um projeto
Na ilustração 1 podemos ver um exemplo de representação do desenvolvimento de um projeto, onde vemos vários processos de fork e merge. As linhas pretas representam forks, as vermelhas representam os merges e as linhas azuis as chamadas versões estáveis do software. A direção das setas acompanha o espectro temporal.
Nesta figura, os retângulos verdes representam as versões da chamada árvore principal do projeto, enquanto que os amarelos representam as versões que desenvolvem funcionalidades alternativas e os azuis representam os marcos do desenvolvimento em que existe um produto ou artefato estável e usável. Na mesma ilustração, o retângulo cor-de-rosa representa uma versão do projeto que foi abandonada, ou seja, o código ali criado não foi reaproveitado pelo projeto.
O processo de fork/merge é gerenciado de formas distintas pelos variados softwares existentes no mercado.
5 VCS e o processo de software
Um VCS pode influenciar de forma profunda o processo de software de uma organização.
Embora seu uso se concentre nas fases de projeto e de construção de um software, eles podem ser utilizados em outras fases que não envolvem código, como na criação da documentação e dos documentos anexos ao desenvolvimento da aplicação, tais como arquivos de diagramas, ou mesmo em ferramentas de diagramação que possuem um versionador integrado.
Há vários aspectos ao analisarmos esta influência, como segue:
1. Falta de organização entre os membros de uma equipe, principalmente se estiverem geologicamente distantes, sobre que funcionalidade foi implementada, por quem foi implementada, quando e porque. Também auxilia na descoberta de bugs e reversão destes. Manter manualmente cópias de segurança – backup – de um software sempre que houver uma mudança pode ser um processo dispendioso e difícil de gerenciar.
2. Esta falta de organização pode dificultar a divisão das tarefas entre diferentes membros da equipe, ou mesmo entre diferentes times de desenvolvimento de um mesmo projeto. A utilização de um VCS ajuda na organização destes times/membros ao longo do processo de desenvolvimento.
3. Acompanhamento e métrica: Por meio do histórico do desenvolvimento do projeto, é possível fazer um acompanhamento objetivo do projeto. Isso pode ser feito por meio de várias métricas, como por exemplo número de linhas inseridos ou removidos ao longo do projeto, partes do sistema que tiveram maior dedicação dos desenvolvedores, tempo utilizado no desenvolvimento de cada funcionalidade, bem como quais desenvolvedores trabalharam mais no processo. A utilização de ferramentas dedicadas na mineração destas informações baseadas no histórico do repositório do projeto podem realizar estas tarefas. 4. Esta métrica permite um melhor planejamento de futuros projetos, baseados nas deficiências
encontradas no processo atual, facilitando o processo de aprendizado e melhoria no trabalho da equipe.
No entanto, somente auxiliado pelo uso de boas praticas de engenharia de software um VCS pode ter um bom impacto no processo de software.
6 Tipos de sistemas de controle de versão
Como já dito anteriormente, podemos categorizar os VCSs segundo a maneira como tratam o repositório do projeto. Segundo estes critérios, temos duas possibilidades: sistemas distribuídos e sistemas centralizados.
6.1 Sistemas de controle de versão centralizados
Este tipo de VCS possui uma arquitetura mais rígida, onde existe uma classificação entre as partes: ou se é o próprio repositório central, ou se é uma cópia de trabalho.
O repositório central frequentemente localiza-se no servidor central, que serve aos usuários uma revisão contida no seu histórico. Todo o histórico do projeto está neste único servidor, e a única maneira de efetivar uma mudança, ou seja, criar uma revisão, é por meio deste servidor. Ele deve sempre estar ativo para que os membros da equipe possam colaborar no desenvolvimento do projeto. E única e exclusivamente por meio dele que os membros da equipe podem colaborar com o projeto e permitir que os outros membros tenham acesso às funcionalidades desenvolvidas.
Esta arquitetura rígida tem feito com que grandes projetos migrem para sistemas distribuídos, como será explicado adiante.
Além de mais simples, esta arquitetura pode ser benéfica em projetos pequenos, onde a colaboratividade entre os membros sem passar pelo servidor central não seja requerido, como quando necessita-se que todo e qualquer trabalho realizado sobre o projeto fique registrado de forma centralizada, seja para controle quanto para consulta.
Outra deficiência deste modelo é a possibilidade de perda de dados por problemas neste repositório central. Caso algum problema aconteça a ele, mesmo a cópia de trabalho com a versão mais recente não terá o histórico do desenvolvimento do projeto. Uma abordagem para resolver este problema seria manter cópias de segurança manuais deste repositório, mas esta abordagem é contrária aos próprio sistema. Como o próprio repositório é, do ponto de vista do sistema operacional do servidor, composto de arquivos, poderíamos pensar em versionar os arquivos do próprio repositório, mas isto entraria num processo de recursão infinita, se considerarmos o problema inicial.
Ilustração 2: Arquitetura de um sistema centralizado
Na ilustração 2 podemos ver a representação de um sistema centralizado. O retângulo alaranjado representa o servidor central, com o repositório, enquanto os retângulos verdes representam as cópias de trabalho.
6.2 Sistemas de controle de versão distribuídos
Em oposição aos VCSs centralizados, houve nos últimos anos uma explosão de novos softwares para controle distribuído.
Como o desenvolvimento de software se dá de forma cada vez mais distribuída, aplicações preparadas para gerenciar sistemas distribuídos se tornaram, senão benéficas, essenciais no desenvolvimento de software.
Nos sistemas de controle de versão distribuídos (DVCS), toda cópia de um projeto versionado é efetivamente um repositório, com algumas exceções2, e costuma-se dar a este o nome de clone.
A arquitetura de um DCVS, diferentemente dos sistemas centralizados, que são árvores de altura igual a um, tem o aspecto de uma rede onde todos os nós são capazes de ter ligações entre si. Estas ligações normalmente são unidirecionais, ou seja, ou de envio ou de recebimento de dados, embora seja possível ter as duas modalidades ativadas.
Ainda sim, é possível e desejável a existência de um ou mais repositórios centrais, que podem ser simulados como repositórios que não possuem manipulação direta dos membros da equipe.
Todo nó da rede é um repositório completo, que pode trabalhar de forma independente dos outros. Isso permite a existência de equipes trabalhando em versões paralelas de um projeto sem que interfiram no projeto principal.
2 O software Monotone, como será visto adiante, possui o conceito de cópia de trabalho, mas esta opera sobre um arquivo local, que representa o repositório em si. É sobre este arquivo que são efetuados processos de
Devido a esta flexibilidade natural, DVCSs têm tomado o lugar dos sistemas centralizados em grandes projetos pelas suas inúmeras vantagens3.
Ilustração 3: Arquitetura de um sistema distribuído
Na ilustração 3 podemos ver um exemplo de sistema distribuído, onde os nós alaranjados são cópias do repositório central representado pelo retângulo verde. Nota-se que nem todos os nós estão ligados neste repositório central, pelo simples fato de ele não ser requerido, mas é comummente utilizado como referência àqueles que acharem necessário.
6.3 Sistemas de controle de versão embarcados
Estes VCSs são comumente embarcados em aplicações não relacionadas ao desenvolvimento de softwares de computador, como editores de texto ou planilhas eletrônicas.
Exemplos de softwares que possuem um sistema de versionamento de documentos: – LibreOffice4/OpenOffice5
– Microsoft Office6
– Apple iWork7
Alguns sistemas operacionais permitem o versionamento dos arquivos de forma integrada ao núcleo do sistema, independente de qualquer aplicação. Isto permite que o usuário mantenha um 3 http://ldn.linuxfoundation.org/book/export/html/9744
4 http://libreoffice.org/ 5 http://www.openoffice.org/ 6 http://office.microsoft.com 7 http://www.apple.com/iwork/
histórico de qualquer arquivo armazenado, podendo acessar o conteúdo deles em qualquer instante desde o momento em que foram criados.
Exemplos de sistemas de arquivos com este suporte – ZFS, suportado no Solaris, OS X e FreeBSD – LFS8, suportado no Linux
– Time Machine9, disponível para OS X
Alguns criadores de VCS oferecem também uma camada em nível de programação das funcionalidades que oferece. Isto permite que programadores criem novas aplicações que utilizem versionamento de arquivos sem a necessidade de reescrever toda uma arquitetura para isso.
Exemplos de bibliotecas disponíveis:
– LibGit210, Git para C, C++, Ruby e outras
– LibQtGit11, Git integrada ao framework Qt
– Libsvn12, Subversion para C
– hg4j13, Mercurial para Java
8 http://logfs.sourceforge.net/ 9 http://www.apple.com/macosx/what-is-macosx/time-machine.html 10 http://libgit2.github.com/ 11 http://gitorious.org/libqtgit 12 http://svn.collab.net/svn-doxygen/ 13 http://hg4j.com/
7 Softwares disponíveis no mercado
Há vários fornecedores de softwares de controle de versão voltados ao desenvolvimento de software, mas este artigo foca-se somente nos que são caracterizados como software de código aberto.
7.1 CVS
14Acrônimo de “Concurrent Versions System”, foi um dos primeiros VCSs centralizados de código aberto disponível, e foi por muito tempo o mais amplamente utilizado em projetos de software aberto. Surgiu no início da década de 90 e desde então não mudou muito sua forma de funcionamento, sendo considerado por muitos inadequado ao processo de desenvolvimento de software atual.
Possui um gerenciamento rígido, onde um repositório gerencia vários módulos, onde cada um destes módulos é um projeto.
Pelo seu tempo de vida, é considerado um software estável e maduro, mas seu uso teve um declínio nos últimos anos, vindo a ser substituído por outros VCSs centralizados, como o
Subversion, ou mesmo sistemas distribuídos.
Atualmente os grandes projetos de código aberto em ativos já não mais o utilizam.
7.2 Subversion
15O Subversion – também chamado de SVN – surgiu como um substituto para o CVS e seu desenvolvimento é gerenciado pela Apache Foundation16. É desenvolvido de forma ativa desde o
ano 2000 e é talvez o VCS centralizado de maior uso no mundo, tanto por projetos de código aberto quanto proprietários.
É um serviço oferecido por boa parte das empresas de hospedagem, e tem como principais usuários os projetos da Apache Foundation e outros projetos como a linguagem de programação Ruby17.
7.3 Mercurial
18Desenvolvido desde 2005, é um VCS distribuído e de código aberto que vem atraído muito a 14 http://www.nongnu.org/cvs/
15 http://subversion.apache.org/ 16 http://apache.org/
17 http://www.ruby-lang.org/en/ 18 http://mercurial.selenic.com/
atenção de vários grandes projetos de código aberto. Tem como mais famosos usuários:
– Mozilla Foundation19
– Linguagem de programação Go20 (da empresa Google21)
– NetBeans22 (da empresa Oracle23)
– OpenJDK24, versão comunitária da máquina virtual Java da Oracle.
– VIM25, famoso editor de textos.
– XEN26, conjunto de ferramentas para virtualização
7.4 Bazaar
27O Baazar é um VCS distribuído desenvolvido desde 2007 pela empresa Canonical para o desenvolvimento de seus projetos no portal de software Launchpad, dedicado ao desenvolvimento de softwares para seu sistema operacional Ubuntu, sendo este inclusive hospedado no portal Launchpad.
Ainda assim, embora possua esta integração com o portal, o Bazaar permite a utilização fora daquele. Sua principal “filosofia” é tornar fácil o processo de colaboratividade em projetos de código aberto.
Como principais usuários, temos: – Ubuntu28
– MySQL29, da empresa Oracle
– GNU Emacs30, famoso editor de textos
19 http://mozilla.org 20 http://golang.org/ 21 http:/google.com 22 http://netbeans.org 23 http://oracle.com 24 http://openjdk.java.net/ 25 http://vim.org/ 26 http://xen.org/ 27 http://bazaar.canonical.com 28 http://ubuntu.com/ 29 http://mysql.com/ 30 http://www.gnu.org/software/emacs/
7.5 Git
31Desenvolvido desde 2005 pelos mesmos desenvolvedores do sistema operacional Linux. É um
DVCS. Foi pensado pelos seus desenvolvedores para “não fazer o que o CVS faz”32. Seu principal
desenvolvedor é Linus Torvalds, também criador do Linux, e seu nome no projeto serve para alguns como atestado de qualidade do Git, por ser Linus talvez o desenvolvedor mais famoso do mundo e considerado, segundo a revista estadunidense Time, uma das 100 mais importantes pessoas do século33.
É criticado por muitos como difícil34, devido à pouca integração com ambientes de
desenvolvimento consagrados, e por requerer um conhecimento maior de outras ferramentas do sistema operacional para ser utilizas, bem como ter comandos mais complexos, se comparado com sistemas similares, como o Mercurial.
Como principais usuários, possui: – Linux35
– Plataforma KDE36
– Plataforma GNOME37
– Sistema operacional Android38
– Perl39 (linguagem de programação)
– X.org40 (principal implementação do protocolo X11)
– Rails41 (framework Ruby)
– Samba42 (implementação em código aberto do protocolo SMB, da Microsoft)
31 http://git-scm.com/
32 Apresentação de Linus Towarlds, na Conferência Google Talk, em 2007. O vídeo encontra-se disponível no endereço: http://www.youtube.com/watch?v=4XpnKHJAok8 33 http://www.time.com/time/time100/poc/century.html 34 http://www.vogella.de/blog/2010/09/21/complexity-git/ 35 http://kernel.org 36 http://kde.org 37 http://gnome.org 38 http://android.com/ 39 http://perl.org/ 40 http://x.org/ 41 http://rubyonrails.org/ 42 http://samba.org/
7.6 Outros
7.6.1 Darcs
43Desenvolvido com base na teoria da álgebra dos patches44, foi pensado inicialmente como um
substituto do já não mais mantido GNU Arch, VCS desenvolvido pela GNU Foundation45. É um
DVCS.
7.6.2 Monotone
46O Monotone é desenvolvido ativamente desde 2003 e seu modelo de funcionamento serviu de inspiração para o Git, sendo, como este, um sistema distribuído.
Como diferencial, seu repositório é contido num arquivo único, de fácil distribuição, pois pode ser copiado como um arquivo comum. Todos os desenvolvedores precisam ter uma cópia local deste arquivo, de onde se obtém uma cópia de trabalho. Este arquivo é então utilizado para sincronização com outros repositórios do mesmo projeto.
Seu mais famoso usuário é o projeto Pidgim47, programa de mensagens instantâneas
multi-protocolo. 43 http://darcs.net/ 44 http://urchin.earth.li/~ian/conflictors/paper-2006-10-30.pdf 45 http://gnu.org 46 http://www.monotone.ca/ 47 http://pidgin.im/
8 Serviços disponíveis
Embora existam custos na hospedagem de repositórios de software, e existem empresas que oferecem estes serviços de forma paga, existem várias iniciativas que incentivam a criação de softwares de código aberto por meio da hospedagem gratuita dos repositórios e alguns com vários outros serviços que acompanham o desenvolvimento de um software, tal como ferramenta de gerenciamento de projetos, wiki, registro de bugs, etc.
8.1 Github
48Como o nome sugere, é voltado à hospedagem de projetos que utilizam o Git. Possui, como slogan, a frase “Social coding”, ou “Desenvolvimento de código social”, numa tradução livre. Possui, além disso, ferramenta de acompanhamento de bugs (bug tracker).
Exemplos de projetos hospedados: – Facebook49
– Jquery50
– Rails – MongoDB51
8.2 Gitorious
52Outro serviço dedicado ao Git, sendo o próprio serviço um software livre, tendo seu código-fonte disponível.
Dentre os projetos hospedados nele, destacam-se:
– Qt53 (framework para desenvolvimento de aplicações na linguagem C++)
– OpenSUSE54, famoso sistema operacional baseado em Linux
8.3 Google Code
55Serviço oferecido pela empresa Google, que hospeda seus próprios projetos neste portal, embora 48 https://github.com/ 49 http://www.facebook.com/ 50 http://jquery.com/ 51 http://www.mongodb.org/ 52 https://gitorious.org/ 53 http://qt.nokia.com/ 54 http://opensuse.org 55 http://code.google.com/
disponibilize-o como serviço para quem desejar hospedar projetos de código aberto.
Possui vários recursos como wiki e gerenciamento de bugs, embora não ofereça exclusivamente um serviço de controle de versão, tendo o cliente a possibilidade de escolher entre o Subversion e o Mercurial.
A maior parte dos projetos em código aberto da Google estão hospedados lá, como o framework para web GWT56.
8.4 Launchpad
57Portal gerenciado pela empresa Canonical58, visa a hospedagem de softwares para o sistema
operacional Ubuntu e a utilização do VCS Bazaar59.
Dentre os softwares que o utilizam está o próprio Ubuntu.
8.5 Sourceforge
60Conhecido como o repositório de código aberto do mundo, é o mais antigo ainda em atuação e oferece vários serviços, como gerenciamento de projetos, controle de versão, wiki, dentre outros. Estima-se que hospede mais de 230 mil projetos e possui mais de 2 milhões de usuários61
Devido à questões políticas, bloqueou seu acesso aos países considerados inimigos dos EUA62,
como Cuba, Irã e Coréia do Norte, o que provocou algum descontentamento pro parte de alguns usuários63.
Oferece várias opções de VCS: Git, Subversion, Bazaar, CVS e Mercurial, além de acesso à banco de dados.
8.6 BitBucket
64Oferece o serviço de hospedagem de projetos que utilizam o Mercurial. Limita a cinco usuários por projeto de código aberto no plano gratuito, mas possui planos pagos para um número maior que este ou para a hospedagem de softwares proprietários. Dentre os usuários encontra-se a Opera65, que
56 http://code.google.com/webtoolkit 57 http://launchpad.net 58 http://canonical.com 59 http://bazaar.canonical.com/ 60 http://sf.net/ 61 http://sourceforge.net/apps/trac/sourceforge/wiki/What%20is%20SourceForge.net 62 http://info.abril.com.br/noticias/ti/sourceforge-censura-inimigos-dos-eua-26012010-44.shl 63 http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ 64 https://bitbucket.org/ 65 https://opera.com/
desenvolve um navegador web de mesmo nome.
8.7 CodePlex
66Portal gerenciado pela empresa Microsoft, dedica-se ao desenvolvimento de aplicações de código aberto para a plataforma Windows. Oferece o Subversion como VCS.
9 A influência do desenvolvimento distribuído
Não só os VCSs influenciam o processo de desenvolvimento de software, mas o próprio processo de desenvolvimento de softwares de forma distribuída favoreceu o desenvolvimento de
VCSs, pois demandou a criação destes.
Um caso notável deste processo foi o desenvolvimento do Git. Segundo Linus Torvalds, principal desenvolvedor do Linux, durante os dez primeiros anos de desenvolvimento de desenvolvimento do Linux, nenhum VCS foi utilizado, devido ao fato de nenhum de código aberto atender as necessidades do projeto.
Mas o desenvolvimento do Linux encontrava-se de maneira cada vez mais acelerada, tendo contribuição de pessoas de todo o mundo. Este é o típico caso onde um sistema VCS distribuído é essencial.
Para contornar este problema, os desenvolvedores do Linux desenvolveram um software que fosse capaz de resolver este problema.
Por isso não é complicado entender que a demanda do mercado por VCSs distribuídos é que favoreceu o seu desenvolvimento, e não o contrário.
10 Ambientes de desenvolvimento e os VCS
Outro aspecto relacionado ao sucesso de um VCS é a sua integração com outras ferramentas, e principalmente com ambientes de desenvolvimento.
Um ambiente de desenvolvimento é um conjunto de ferramentas que trabalham de forma integrada para permitir o desenvolvimento de um software. Existem no mercado diversos ambientes de desenvolvimento, alguns mais complexos, que auxiliam desde as fases de captura e análise de requisitos até a codificação, testes e distribuição.
Todo este processo pode ser acompanhado por um VCS, auxiliando no controle sobre o desenvolvimento do sistema.
O suporte a VCSs pode vir nativamente com o ambiente de desenvolvimento ou com o uso de
plugins ou mesmo extensões.
São exemplos de ambientes de desenvolvimento de código aberto com suporte a vários VCSs: – Eclipse67
– NetBeans – CodeBlocks68 – KDevelop69 – Anjuta70 – Emacs – Qt Creator71 – MonoDevelop72 – IntelliJ IDEA73 – Komodo74
Ainda sim é perfeitamente possível utilizar a maioria dos VCSs externamente aos ambientes de desenvolvimento, por meio de bibliotecas de funções que permitem que o programador embarque o
VCS em seu software, ou por meio de aplicações gráficas ou em linha-de-comando para gerenciar o
repositório de código de um projeto.
10.1Eclipse e VCS
O ambiente de desenvolvimento integrado (Integrated Development Environment, ou IDE) Eclipse é um dos mais versáteis disponíveis hoje no mercado. E isto se reflete também no seu suporte à VCS.
Por ser desenvolvido de forma comunitária e bastante democrática, o suporte à VCS no Eclipse é desenvolvido na forma de subprojetos, conforme segue a lista:
– Mercurial: http://javaforge.com/project/HGE – Git: Egit: http://www.eclipse.org/egit/
– Subversion: Subeclipse: http://subclipse.tigris.org/ – Bazaar: http://wiki.bazaar.canonical.com/BzrEclipse 68 http://codeblocks.org 69 http://kdevelop.org 70 http://projects.gnome.org/anjuta/ 71 http://qt.nokia.com/products/developer-tools/ 72 http://monodevelop.com/ 73 http://www.jetbrains.com/idea/ 74 http://www.openkomodo.com/
– CVS: http://www.eclipse.org/eclipse/platform-cvs/
Embora estes projetos possuam algumas funcionalidades distintas, são apresentados para o programador sob uma mesma interface.
11 Operações comuns
Embora sejam softwares diferentes, todos os VCSs, sejam centralizados ou distribuídos, possuem algumas operações comuns, necessárias para que cumpram seu papel. Os exemplos são executados num prompt do sistema operacional, e serão mostrados exemplos com o Git (distribuído) e Subversion (centralizado). Os parâmetros dentro de [] são opcionais. A expressão nó indica repositório remoto deverá ser consultado.
11.1 Criar um repositório
É o primeiro passo para se usar um VCS. Exemplos de uso: Git: mkdir project; cd project; git init
Subversion: svnadmin create project/
11.2 Copiar o projeto
Git: git clone git://url.do.reposotorio.git
Subversion: svn checkout svn://url.do.reposotorio
11.3 Buscar modificações
Trata-se da tarefa de atualizar o repositório local ou cópia de trabalho para a última versão Git: git pull [nó]
Subversion: svn update
11.4 Enviar modificações
Git: git commit -a -m “mensagem”; git push [nó|--all] [branch] Subversion: svn commit -m “messagem”
11.5 Comparar diferentes versões ou revisões
Git: git diff d423e886888a2da4341e5e4cac4958068fbea81e # código da revisão Subversion: git diff -r 30 # número da revisão
11.6 Obter o histórico de modificações
Subversion: svn log
11.7 Criar forks
Git75: git branch new_fork
Subversion: svn copy svn://repo/ svn://repo_branch2 -m "Segundo branch";
11.8 Executar merges
Git: git merge [nó] branch
Subversion: svn merge svn://merge_repo
75 Todo repositório de um DVCS é um fork por natureza. Mas é possível criar forks dentro de um mesmo repositório, de maneira tradicional.
Os sistemas de controle de versão são atualmente ferramentas essenciais para qualquer projeto que manipule documentos que sofrem modificações frequentes, e projetos de desenvolvimento de software são o exemplo mais notável desta necessidade.
Aliado à boas práticas de engenharia de software, manter o código e documentação do projeto auxilia numa melhor extração de informações referentes aos dados coletados pelo software de controle utilizado. Estas informações são uma boa métrica para sabermos se o processo de desenvolvimento de software está adequado e propor melhorias a este.
distributed-version-control-illustrated>
K. Fogel; M. Bar;, Open Source Development with CVS, 3rd Edition – disponível em <http://cvsbook.red-bean.com/>
Version Control: A Case Study in the Challenges and Opportunities for Open Source
Software Development - Mark C. Chu-Carroll, David Shields and Jim Wright – disponível em <http://opensource.ucc.ie/icse2002/ChuCarrollShieldsWright.pdf>
Fagerholm , F & Taina , J 2008 , ' Collecting data from distributed FOSS projects ' , pp. 5-11 . Disponível em <https://helda.helsinki.fi/bitstream/handle/10138/23994/wopdasd2008.pdf> Draheim, D.; Pekacki, L.; , "Process-centric analytical processing of version control data," Software Evolution, 2003. Proceedings. Sixth International Workshop on Principles of , vol., no., pp. 131- 136, 1-2 Sept. 2003 doi: 10.1109/IWPSE.2003.1231220 Disponível
em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1231220&isnumber=27581> Oracle Solaris ZFS – disponível em
<http://www.oracle.com/us/products/servers-storage/solaris/034779.pdf>
FOSS Culture – COMP8440: Lectutes – disponível em
<http://cs.anu.edu.au/student/comp8440/lectures/foss_culture.pdf> Analysis of Git and Mercurial – disponível em
<http://code.google.com/p/support/wiki/DVCSAnalysis>
B. O'Sullivan, Mercurial: The Definitive Guide, – disponível em <http://hgbook.red-bean.com/index.html>
Darcs User Manual – disponível em <http://darcs.net/manual/>
Monotone Documentation – disponível em <http://www.monotone.ca/docs/index.html> The Git Community Book – disponível em <http://book.git-scm.com/>
Welcome to Bazaar – disponível em <http://wiki.bazaar.canonical.com/Welcome> Central vs Distributed VCS – disponível em
<http://ldn.linuxfoundation.org/book/export/html/9744>
