Upload
luiz-matos
View
344
Download
2
Embed Size (px)
DESCRIPTION
Apresentação do artigo com o mesmo título realizada na disciplina Gerência de Configuração do doutorado em Ciência da Computação da Universidade Federal Fluminense.
Citation preview
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