O documento analisa sistemas de controle de versões, destacando as diferenças entre modelos centralizados (como CVS e SVN) e modelos distribuídos (como Git e Mercurial). A escolha entre esses sistemas depende das características da equipe e do projeto, incluindo a necessidade de colaboração e flexibilidade. Conclui que não existe uma resposta absoluta para a escolha do sistema, sendo fundamental considerar o tipo de dados e a interação desejada entre os membros da equipe.

1. Doutorado em Ciência da Computação
Gerência de Configuração
Making Sense of Revision-Control Systems 1
Luiz Matos
Rio Branco, Maio de 2012.
1
Slides concedidos sob [1] O’Sullivan, B. Making sense of revision-control systems. Communications of the ACM, v.52, n.9, p.56-62. 2009.
Licença Creative Commons.

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
2

3. Contextualização
3

4. Software é …
complicado?
complexo?
4

5. 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
Visão limitada dos dados
CVS ou SVN
(centralizados)
[Murta 2012, adaptado]
Metadados
Histórico 10

11. Qual ferramenta de controle de versão
devo escolher?
11

12. Team Foundation
Server
PVCS Pro
ClearCase
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?”
14
http://www.nextbillion.net/archive/files/images/india-call-center.jpg http://linguagenscontemporaneas.files.wordpress.com/2012/05/campus_party1.jpg

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
check-in
clone/pull
clone/pull
push
check-out
Metadados push Metadados
História
História
Git ou Mercurial
(distribuídos)
Metadados
História 17

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

20. Onde está o problema?
Desenvolvimento Concorrente/Paralelo
Como gerenciar grandes projetos ???
20

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

22. Árvore de evolução histórica de um projeto
22
http://en.wikipedia.org/wiki/File:Revision_controlled_project_visualization-2010-24-02.svg

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. 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?
Alice
R.: Perda ou inconsistência de dados (código-fonte).
Bob
106 105
105
E ser não tiver quaisquer problemas?
R.: Alice e Bob não serão notificados sobre as alterações.
SVN (centralizado)
25
[Murta 2012, adaptado]

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. 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
check-in
Alice
clone/pull Bob
push
check-out
Git ou Mercurial
(distribuídos) 27

28. SCV Centralizado versus SCV Distribuído
28

29. Flexibilidade
SVN Git e Mercurial
Convenção em /trunk e /branches Repositório tratado como uma
unidade de trabalho
Problemas de inconsistência git commit -a
(commit e update em porções hg update
diferentes do workspace)
Adequado quando usuários estão Publicação ad hoc
conectados na mesma rede
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 é Separação entre check-in e
publicado implicitamente publicação
Não permite trabalho off-line Permite trabalho off-line
Compartilhamento de projetos Fácil compartilhamento de projetos
somente com permissão (hospedado no próprio host)
30

31. Merges e Nomes de Arquivos/Diretórios
SVN Git e Mercurial
Arquivos renomeados não são Merges frequentes, logo, lidam bem
detectados no merge (?) com mudanças de nome
Problemas em plataformas Mecanismo de case-insensitive
diferentes (foo.txt != FOO.txt) (Mercurial)
31

32. Nova forma de identificar bugs
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
32

33. Pontos Positivos das Ferramentas Centralizadas
• Gerenciamento de arquivos binários (lock)
• História linear de um branch facilitando a compreensão
• Configuração de scripts pre-commit
33

34. Conclusões
34

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

36. Quando usar o quê?
• SCV Centralizado
 Versionamento de arquivos binários
 Controle de acesso no nível de arquivos
36

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

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

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