1

Making Sense of Revision-Control Systems1

Luiz MatosRio Branco, Maio de 2012.

Slides concedidos sob Licença Creative Commons.

[1] O’Sullivan, B. Making sense of revision-control systems. Communications of the ACM, v.52, n.9, p.56-62. 2009.

Doutorado em Ciência da Computação

Gerência de Configuração

2

ORGANIZAÇÃO

Contextualização

Ramos (branches) e Junção (merging)

SCV2 Centralizado versus SCV Distribuído

Conclusões

2 Sistema de Controle de Versões

3

Contextualização

4

Software é …

complicado?

complexo?

5

6

Os métodos utilizados para gerenciar o

desenvolvimento de um software

refletem a sua complexidade.

6

7

Mas …

if (Gerência de Configuração == “o controle da evolução de

sistemas complexos”)

...[Estublier 2000]

7

8

CVS (Concurrent Versions System)

Dominou o mercado por mais de uma década

Limitações

Sistema legado

Subversion (SVN)

Popularizado em meados dos anos 2000

Construído para superar as limitações do CVS

8

9

Modelo Cliente/Servidor

[Tanenbaum 2007]

9

10

Modelo Cliente/Servidor e o Controle de Versões

[Murta 2012, adaptado]

Visão limitada dos dados

MetadadosHistórico

CVS ou SVN (centralizados)

10

11

Qual ferramenta de controle de versão

devo escolher?

11

12

PVCS Pro

ClearCase

Team Foundation Server

12

13

“All revision-control systems come with

complicated sets of trade-offs.”

13

14

“How do you find the best match

between tool and team?”

http://www.nextbillion.net/archive/files/images/india-call-center.jpg http://linguagenscontemporaneas.files.wordpress.com/2012/05/campus_party1.jpg

14

15

Início dos anos 2000

Projetos buscando algo DIFERENTE do modelo centralizado

Mais populares

Git

Mercurial

15

16

Modelo Peer-to-Peer

[Tanenbaum 2007]16

17

Modelo Peer-to-Peer e o Controle de Versões

Git ou Mercurial (distribuídos)

MetadadosHistória

MetadadosHistória

MetadadosHistória

push

push

clone/pull

17

clon

e/pu

ll

check-out

check-in

18

Tarefas básicas de um Sistema de Controle de Versões

História dos arquivos

Quem fez uma mudança

Quando e por qual motivo foi realizada

Recuperação para um estado consistente (“giant UNDO key”)

Permite o trabalho em subprojetos independentes

Branches

18

19

Fatos em Sistema de Controle de Versões

Cada ferramenta tem sua própria abordagem de trabalho e colaboração

Cada ferramenta possui suas particularidades

Nenhuma vai atender os anseios de TODA a equipe de desenvolvimento19

20

Onde está o problema?

Desenvolvimento Concorrente/Paralelo

Como gerenciar grandes projetos ???

20

Ramos (branches) e Junções (merging)

21

http://en.wikipedia.org/wiki/File:Revision_controlled_project_visualization-2010-24-02.svg

Árvore de evolução histórica de um projeto

22

23

Cenário de Riscos

Desenvolvimento concorrente + SCV centralizado

• Programador habituado com bugs em módulos não relacionados

Assume o risco utilizando branches isolados

23

24

Cenário de Riscos

Desenvolvimento concorrente + SCV centralizado

• Branches isolados por muito tempo

Equipes em diferentes ramos e alterações conflitantes para o mesmo código

• Merge torna-se ALTAMENTE arriscado

Introdução de bugs e criação de novos problemas 24

25

[Murta 2012, adaptado]

SVN (centralizado)

AliceBob

1– Alice e Bob fazem check-out da versão 105

2 – Alice faz check-in e a versão é atualizada para 106

3 – Se Bob tentar fazer check-in, o SVN o notifica de que é necessário realizar merge de sua contribuição com a versão 106 (de Alice)

E ser der algum problema nessa operação de merge?

R.: Perda ou inconsistência de dados (código-fonte).

E ser não tiver quaisquer problemas?

R.: Alice e Bob não serão notificados sobre as alterações.

105 105106

25

26

Cenário Ideal

Desenvolvimento concorrente + SCV distribuído

• Repositório contém uma cópia completa do histórico e dos arquivos do projeto.

26

27

Bob

Alice

1– Alice clona uma cópia do repositório de Bob (ou de um servidor)

2 – Alice faz check-out e check-in localmente

3 – Oportunamente, Alice deverá publicar o repositório em um servidor ou devolvê-lo para Bob

27

Git ou Mercurial (distribuídos)

push

clone/pull

check-out

check-in

push

SCV Centralizado versus SCV Distribuído

28

29

Flexibilidade

SVN Git e MercurialConvenção em /trunk e /branches Repositório tratado como uma

unidade de trabalho

Problemas de inconsistência (commit e update em porções diferentes do workspace)

git commit -a

hg update

Adequado quando usuários estão conectados na mesma rede

Publicação ad hoc

29

30

Publicação de Mudanças

SVN Git e Mercurial

Merge crítico (sintática/semântica) Não realizam merge de mudanças remotas com mudanças locais

Ao fazer um check-in ele é publicado implicitamente

Separação entre check-in e publicação

Não permite trabalho off-line Permite trabalho off-line

Compartilhamento de projetos somente com permissão

Fácil compartilhamento de projetos (hospedado no próprio host)

30

31

Merges e Nomes de Arquivos/Diretórios

31

SVN Git e Mercurial

Arquivos renomeados não são detectados no merge

Merges frequentes, logo, lidam bem (?) com mudanças de nome

Problemas em plataformas diferentes (foo.txt != FOO.txt)

Mecanismo de case-insensitive (Mercurial)

32

Nova forma de identificar bugs

32

Git e Mercurial

• Comando bisect

Compara versão SEM bug e versão COM bug

Solicita confirmação se a versão realmente contém um bug

Repete o processo até encontrar a versão que INSERIU o bug

33

Pontos Positivos das Ferramentas Centralizadas

33

• Gerenciamento de arquivos binários (lock)

• História linear de um branch facilitando a compreensão

• Configuração de scripts pre-commit

Conclusões

34

35

35

Quando usar o quê?

• SCV Centralizado

Equipe altamente engajada e estruturada.

Equipe com acesso de escrita ao servidor (repositório) e seus

membros estão conectados na mesma rede.

36

36

Quando usar o quê?

• SCV Centralizado

Versionamento de arquivos binários

Controle de acesso no nível de arquivos

37

37

Quando usar o quê?

• SCV Distribuído

Membros da equipe passam muito tempo em viagem e/ou

no cliente.

Projeto exige agilidade, inovação e muita colaboração.

http://noticias.uol.com.br/album/110318_terremotonojapao_4_album.jhtm?abrefoto=78#fotoNav=7238

39

40

“Choosing a revision-control system is a question

with a surprisingly small number of absolute answers.

The fundamental issues to consider are what kind of data

your team works with, and how you want

your team members to interact.”

40

41

Referências

[1] O’Sullivan, B. Making sense of revision-control systems. Communications of the ACM, v.52, n.9, p.56-62. 2009.

[2] Estublier, J. Software Configuration Management: a Roadmap. International Conference on Software Engineering (ICSE), The Future of Software Engineering. Limerick, Ireland. June, 2000. 279-289 p.

[3] TANENBAUM, A. Sistemas Distribuídos: princípios e prática. 2. ed. São Paulo: Bookman, 2007.

[4] MURTA, L. Gerência de Configuração: terminologia. Slides de aula. Universidade Federal Fluminense, Doutorado em Ciência da Computação, 2012.

* Os logotipos do slide 12 foram obtidos nos sites oficiais dos respectivos fornecedores/ferramentas, para quaisquer formas de utilização, deve-se atentar às normas de utilização correspondentes.

41