Repositórios 2

Sistemas de controle de versionamento

Allan C. Trevisan

PET-COCE

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 :

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?

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?

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 configura-tion management, source code management (SCM) or

source code control

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.

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.

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.

Como Funciona o Controle de Versão?

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

Controle de Versão Centralizado

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.

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

Questões de concorrência

Abordagem pessimista : lock-modify-unlock

Abordagem otimista : copy-modify-merge

Sincronização no Controle de Versão Centralizado

Sincronização no Controle de Versão Centralizado

Sincronização no Controle de Versão Centralizado

Sincronização no Controle de Versão Centralizado

Sincronização no Controle de Versão Centralizado

Sincronização no Controle de Versão Centralizado

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.

Controle de Versão Distribuído

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

Controle de Versão Distribuído

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.

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.

Controle de Versão Distribuído

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

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

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

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

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

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

Diferentes versões de projeto

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

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.

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

Maior complexidade

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

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.

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.

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

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

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.

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] http://www.ericsink.com/scm/scm_intro.html, acessado em 3/06/11 [5] http://pronus.eng.br/blog/http:/pronus.eng.br/blog/vantagens-e-desvantagens-do-controle-de-versao-distribuido, acessado em 5/06/11