Aluno: Leandro Santiago da Silva. Artigo. Sistemas de controle de versão

Transcrição

1 Aluno: Leandro Santiago da Silva Artigo Sistemas de controle de versão Maringá/PR UEM 2011

2 1 Resumo Sistemas de controle de versão permitem um maior controle sobre documentos digitais e são 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.

3 Índice 1. Resumo Introdução O que são sistemas de controle de versão Quando e porque utilizar VCS e o processo de software Tipos de sistemas de controle de versão Sistemas de controle de versão centralizados Sistemas de controle de versão distribuídos Sistemas de controle de versão embarcados Softwares disponíveis no mercado CVS Subversion Mercurial Bazaar Git Outros Darcs Monotone Serviços disponíveis Github Gitorious Google Code Launchpad Sourceforge BitBucket CodePlex A influência do desenvolvimento distribuído Ambientes de desenvolvimento e os VCS Eclipse e VCS Operações comuns Criar um repositório Copiar o projeto Buscar modificações Enviar modificações Comparar diferentes versões ou revisões Obter o histórico de modificações Criar forks Executar merges Conclusão Referências...27

4 Índice de Ilustrações Ilustração 1: Processo de fork/merge e tempo de linha de um projeto...8 Ilustração 2: Arquitetura de um sistema centralizado...11 Ilustração 3: Arquitetura de um sistema distribuído...12

5 4 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.

6 5 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 clienteservidor, 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. Embora sejam extramente úteis no desenvolvimento de pequenos projetos normalmente

7 6 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.

8 7 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 aberto

9 8 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.

10 9 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.

11 10 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.

12 11 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ções 2, 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 gerenciamento.

13 Devido a esta flexibilidade natural, DVCSs têm tomado o lugar dos sistemas centralizados em grandes projetos pelas suas inúmeras vantagens 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: LibreOffice 4 /OpenOffice 5 Microsoft Office 6 Apple iwork 7 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

14 13 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 LFS 8, suportado no Linux Time Machine 9, 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: LibGit2 10, Git para C, C++, Ruby e outras LibQtGit 11, Git integrada ao framework Qt Libsvn 12, Subversion para C hg4j 13, Mercurial para Java

15 14 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 14 Acrô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 15 O Subversion também chamado de SVN surgiu como um substituto para o CVS e seu desenvolvimento é gerenciado pela Apache Foundation 16. É 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 Ruby Mercurial 18 Desenvolvido desde 2005, é um VCS distribuído e de código aberto que vem atraído muito a

16 15 atenção de vários grandes projetos de código aberto. Tem como mais famosos usuários: Mozilla Foundation 19 Linguagem de programação Go 20 (da empresa Google 21 ) NetBeans 22 (da empresa Oracle 23 ) OpenJDK 24, versão comunitária da máquina virtual Java da Oracle. VIM 25, famoso editor de textos. XEN 26, conjunto de ferramentas para virtualização 7.4 Bazaar 27 O 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: Ubuntu 28 MySQL 29, da empresa Oracle GNU Emacs 30, famoso editor de textos

17 Git 31 Desenvolvido 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éculo 33. É criticado por muitos como difícil 34, 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: Linux 35 Plataforma KDE 36 Plataforma GNOME 37 Sistema operacional Android 38 Perl 39 (linguagem de programação) X.org 40 (principal implementação do protocolo X11) Rails 41 (framework Ruby) Samba 42 (implementação em código aberto do protocolo SMB, da Microsoft) Apresentação de Linus Towarlds, na Conferência Google Talk, em O vídeo encontra-se disponível no endereço:

18 Outros Darcs 43 Desenvolvido com base na teoria da álgebra dos patches 44, foi pensado inicialmente como um substituto do já não mais mantido GNU Arch, VCS desenvolvido pela GNU Foundation 45. É um DVCS Monotone 46 O 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 Pidgim 47, programa de mensagens instantâneas multiprotocolo

19 18 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 48 Como 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: Facebook 49 Jquery 50 Rails MongoDB Gitorious 52 Outro serviço dedicado ao Git, sendo o próprio serviço um software livre, tendo seu códigofonte disponível. Dentre os projetos hospedados nele, destacam-se: Qt 53 (framework para desenvolvimento de aplicações na linguagem C++) OpenSUSE 54, famoso sistema operacional baseado em Linux 8.3 Google Code 55 Serviço oferecido pela empresa Google, que hospeda seus próprios projetos neste portal, embora

20 19 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 GWT Launchpad 57 Portal gerenciado pela empresa Canonical 58, visa a hospedagem de softwares para o sistema operacional Ubuntu e a utilização do VCS Bazaar 59. Dentre os softwares que o utilizam está o próprio Ubuntu. 8.5 Sourceforge 60 Conhecido 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ários 61 Devido à questões políticas, bloqueou seu acesso aos países considerados inimigos dos EUA 62, como Cuba, Irã e Coréia do Norte, o que provocou algum descontentamento pro parte de alguns usuários 63. Oferece várias opções de VCS: Git, Subversion, Bazaar, CVS e Mercurial, além de acesso à banco de dados. 8.6 BitBucket 64 Oferece 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 Opera 65, que

21 20 desenvolve um navegador web de mesmo nome. 8.7 CodePlex 66 Portal gerenciado pela empresa Microsoft, dedica-se ao desenvolvimento de aplicações de código aberto para a plataforma Windows. Oferece o Subversion como VCS. 66

22 21 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: Eclipse

23 22 NetBeans CodeBlocks 68 KDevelop 69 Anjuta 70 Emacs Qt Creator 71 MonoDevelop 72 IntelliJ IDEA 73 Komodo 74 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: Git: Egit: Subversion: Subeclipse: Bazaar:

24 23 CVS: Embora estes projetos possuam algumas funcionalidades distintas, são apresentados para o programador sob uma mesma interface.

25 24 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 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 d423e886888a2da4341e5e4cac fbea81e # código da revisão Subversion: git diff -r 30 # número da revisão 11.6 Obter o histórico de modificações Git: git log