Repositórios 2. Sistemas de controle de versionamento. Allan C. Trevisan PET-COCE

Transcrição

1 Repositórios 2 Sistemas de controle de versionamento Allan C. Trevisan PET-COCE

2 Introdução Muitos problemas de desenvolvimento de software são causados por falta de controle de versão. Algumas questões que valem a pena serem respondidas :

3 Introdução Alguém já sobrescreveu o código de outra pessoa por acidente e acabou perdendo as alterações? Tem dificuldades em saber quais as alterações efetuadas em um programa, quando foram feitas e quem fez? Tem dificuldade em recuperar o código de uma versão anterior que está em produção? Tem problemas em manter variações do sistema ao mesmo tempo?

4 Introdução Esta apresentação pretende responder as seguintes perguntas : 1. Para que serve um sistema de controle de versão? 2. Como funciona o controle de versão? 3. Quais as semelhanças e diferenças entre o modelo centralizado e o distribuído? 4. Em que casos um tipo é melhor que outro?

5 Introdução Quando se fala em sistemas de controle de versão, version control systems (VCS' s), alguns termos podem ser usados de maneira intercambiável : revision control systems (RCS), software configuration management, source code management (SCM) or source code control

6 Para que Serve o Controle de Versão? O Controle de versão apoia o desenvolvimento de diversas maneiras: Histórico. Registra toda a evolução do projeto, cada alteração sobre cada arquivo. Com essas informações sabe-se quem fez o que, quando e onde. Além disso, permite reconstruir uma revisão específica do arquivo sempre que desejado; Colaboração. O controle de versão possibilita que vários desenvolvedores trabalhem em paralelo sobre os mesmo arquivos sem que um sobrescreva o código de outro, o que traria reaparecimento de defeitos e perda de funcionalidades; Variações no Projeto. Mantém linhas diferentes de evolução do mesmo projeto. Por exemplo, mantendo uma versão 1.0 enquanto a equipe prepara uma versão 2.0.

7 Para que Serve o Controle de Versão? Enfim, controle de versão é fundamental para o desenvolvimento de software. Todos os ambientes de desenvolvimento modernos, tais como o Eclipse e o NetBeans, já possuem plugins para integração com algum sistema de controle de versão.

8 Como Funciona o Controle de Versão? O desenvolvedor não trabalha diretamente nos arquivos do repositório. Ao invés disso, usa uma área/cópia de trabalho que contém a cópia dos arquivos do projeto e que é monitorada para identificar as mudanças realizadas. Essa área é individual e isolada das demais áreas de trabalho. A sincronização entre a área de trabalho e o repositório é feita através dos comandos de commit e update. Tanto o controle de versão centralizado quanto o distribuído possuem repositórios e áreas de trabalho. A diferença está em como cada uma dessas partes está arranjada.

9 Como Funciona o Controle de Versão?

10 Controle de Versão Centralizado No controle de versão centralizado há um único repositório e várias cópias de trabalho que se comunicam apenas através do repositório central. A cópia de trabalho não inclui nenhuma história

11 Controle de Versão Centralizado

12 Controle de Versão Centralizado Ex : CVS, SVN Uma revisão precisa de uma identificação única. No controle de versão centralizado, cada revisão produzida recebe um número inteiro sequencial: 1, 2, 3... Como só existe um repositório, a numeração de revisão é a mesma para todos os desenvolvedores.

13 Controle de Versão Centralizado Uma revisão consiste de um arquivo e alguns metadados (log) As mudanças entre uma versão e outra são chamadas de diff ou delta A rede é um gargalo Trunk, branch tagging

14 Questões de concorrência Abordagem pessimista : lock-modify-unlock Abordagem otimista : copy-modify-merge

15 Sincronização no Controle de Versão Centralizado

16 Sincronização no Controle de Versão Centralizado

17 Sincronização no Controle de Versão Centralizado

18 Sincronização no Controle de Versão Centralizado

19 Sincronização no Controle de Versão Centralizado

20 Sincronização no Controle de Versão Centralizado

21 Controle de Versão Distribuído No controle de versão distribuído cada desenvolvedor possui um repositório próprio acoplado a uma área de trabalho. A comunicação entre eles continua sendo através de commit e update.

22 Controle de Versão Distribuído

23 Controle de Versão Distribuído Um repositório pode se comunicar com qualquer outro através de duas operações básicas: pull e push: Pull (Puxar). Atualiza o repositório local (destino) com todas as alterações feitas em outro repositório (origem). Push (Empurrar). Envia as alterações do repositório local (origem) para um outro repositório (destino). Não há necessidade de uma topologia pré-definida

24 Controle de Versão Distribuído

25 Controle de Versão Distribuído A sincronização entre os desenvolvedores acontece de repositório a repositório e não existe, em princípio, um repositório mais importante que o outro, embora o papel de um repositório central possa ser usado para convencionar o fluxo de trabalho.

26 Controle de Versão Distribuído No sistema distribuído, os repositórios são autônomos e portanto não há como definir uma numeração sequencial compartilhada para todos. A solução é identificar cada revisão com uma numeração que nunca se repita em qualquer outro repositório. A forma mais usada é através de um hash SHA-1, que produz um número de 160 bits (40 dígitos na forma hexadecimal). Esse um número é tão grande e específico que torna extremamente improvável a colisão com um hash produzido por outro repositório.

27 Controle de Versão Distribuído

28 Sincronização no Controle de Versão Distribuído

29 Sincronização no Controle de Versão Distribuído

30 Sincronização no Controle de Versão Distribuído

31 Sincronização no Controle de Versão Distribuído

32 Sincronização no Controle de Versão Distribuído

33 Sincronização no Controle de Versão Distribuído

34 Diferentes versões de projeto

35 Benefícios do Controle de Versão Distribuído Do ponto de vista do desenvolvedor : Rapidez. As operações são processadas localmente. Não é necessário passar pela rede e contatar o servidor central para fazer um commit, log ou diff por exemplo. Autonomia. A conexão com a rede só é necessária para trocar revisões com outros repositórios. Fora isso, trabalha-se desconectado e em qualquer lugar, como num cliente por exemplo. Ramos privativos. Além de um repositório próprio, o trabalho local é feito em um ramo privativo que não interfere, nem sofre interferência dos demais, mesmo nas operações de sincronização entre repositórios. O momento de combinar um ramo com outro é uma decisão do desenvolvedor e não obrigatório antes de cada commit, como acontece no centralizado. Facilidade de Mesclagem. Só a facilidade de criação de ramos não seria suficiente se não fosse o rastreamento automático usado pelos DVCS, que torna o processo de mesclagem muito mais simples e indolor. Observação: No Subversion, o rastreamento automático de merges começou a partir da versão 1.5

36 Benefícios do Controle de Versão Distribuído Do ponto de vista da gerência/coordenação : Confiabilidade. No sistema centralizado, uma pane no servidor interrompe todo o desenvolvimento. Já no sistema distribuído, além de a equipe poder continuar seu trabalho os repositórios dos desenvolvedores funcionam como cópias de backup de todo o projeto. Redução de custos com servidor. A carga de processamento fica distribuída nas próprias máquinas dos desenvolvedores. O repositório central, quando existe, tem o papel do repositório oficial e não como processador central das requisições.

37 Em que situações o DVCS não vai tão bem? Maior complexidade

38 Em que situações o DVCS não vai tão bem?

39 Em que situações o DVCS não vai tão bem? Ao contrário do centralizado, não adianta só commit e update para funcionar no tranco. Todos os desenvolvedores da equipe precisam ter um conhecimento maior do modelo, da ferramenta e, de preferência, também de um processo de desenvolvimento que padronize fluxos de trabalho a serem seguidos. Só assim, o grafo acima deixa de ser apenas um emaranhado e passa a representar muito claramente o fluxo do trabalho.

40 Em que situações o DVCS não vai tão bem? Travamento de arquivos binários precisa ser centralizado : O modelo puramente distribuído não é adequado para lidar com travamento justamente por não possuir um servidor central que possa controlar as travas de todos.

41 Em que situações o DVCS não vai tão bem?

42 Em que situações o DVCS não vai tão bem?

43 Em que situações o DVCS não vai tão bem? Controle de mudança ainda é centralizado : As ferramentas de controle de mudança (e.g. Trac, Redmine, Mantis, Bugzilla) ainda não acompanharam as de controle de versão na arquitetura peer-to-peer.

44 Referencias [1] Version Control Systems, Stefan Otte, Computer Systems and Telematics, Institute of Computer Science, Freie Universitat, Berlin Germany [2] Collaboration Tools for Global Software Engineering, Filippo Lanubile, Christof Ebert, Rafael Prikladnicki, and Aurora Vizcaíno [3] Engenharia de Software para Software Livre, Cesar Augusto de Azambuja Brod, Joice Käfer [4] acessado em 3/06/11 [5] acessado em 5/06/11