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