SUBVERSION GIT Ferramentas de Controle de Versão 1.

Apresentação em tema: "SUBVERSION GIT Ferramentas de Controle de Versão 1."— Transcrição da apresentação:

1 SUBVERSION GIT Ferramentas de Controle de Versão 1

2 Centralizado x Distribuído Centralizado: Subversion Distribuído: Git, Mercurial Repositório Espaço de Trabalho check-in / commit check-out / update Repositório Espaço de Trabalho check-in Repositório Espaço de Trabalho clone / pull push 2

3 INTRODUÇÃO CONTROLE DE CONCORRÊNCIA REPOSITÓRIO ESPAÇO DE TRABALHO JUNÇÃO COMANDOS PROPRIEDADES Subversion 3

4 Histórico 4 Projeto iniciado em 2000  Iniciativa da CollabNet  Open-Source Intuito de substituir o CVS  Similar no uso  Melhor na implementação Auto controlado desde agosto de 2001

5 Características 5 Versionamento de diretórios Copia, renomeação e movimentação com histórico Check-ins atômicos Versionamento de meta-dados Acesso via http/https Uso extensivo de deltas  Delta de binários  Delta bidirecional na comunicação cliente/servidor

6 Características Metadados versionados  Cada arquivo e diretório têm um conjunto de propriedades - chaves e os seus valores - associados a eles. Você pode criar e fornecer qualquer par chave/valor arbitrario que deseje. As propriedades são versionadas no tempo, como os conteúdos dos arquivos. Versionamento de diretórios ou pastas  O Subversion implementa um sistema de arquivos versionados virtual que mantém o registro de modificações em árvores de diretórios ou pastas inteiras no tempo. Os arquivos e os diretórios são versionados. Opções de Acesso à Rede  Subversion foi projetado para uma camada abstrata de acesso ao repositório, o que permite a implementação de novos mecanismos de rede.  Um dos mecanismos existentes usa o protocolo WebDAV/DeltaV baseado em HTTP através do Apache.  A outra opção é o servidor dedicado svnserve como opção ao Apache, e que pode ser combinado ao ssh. 6

7 Características Arquivos Binários e de Texto Tratados Consistentemente  CVS que não funciona tão bem com arquivos binários.  Por outro lado, o Subversion usa um algoritmo de diferenciação binário que funciona de modo idêntico tanto para arquivos texto (legíveis por humanos) quanto para arquivos binários (ilegíveis para humanos). Ramificações e Rotulações em Tempo Constante Facilidade de criação de rótulos e ramos  O tempo das operações de ramificação e rotulação é constante, e não depende do tamanho do projeto no repositório.  Esse resultado é obtido por meio da operação de cópia que resulta em links, ocupando pouco espaço e um intervalo de tempo constante. Uso mais Eficiente da Rede  Interoperabilidade via protocolo http.  O protocolo de rede usa a largura de banda eficientemente enviando as diferenças entre cliente/servidor e servidor/cliente sempre que possível, ao contrário do CVS que envia as diferenças do servidor ao cliente, mas não do cliente ao servidor. 7

8 Características Controle de Diretórios, Renomeações e Metadados  Subversion não só controla a versão do conteúdo dos arquivos, mas também de diretórios, cópias, renomeações e metadados. Operações Atômicas de commit  Um conjunto de modificações a serem realizadas em um commit é aceito como um todo ou nenhuma alteração é feita.  Não há a possibilidade de aceitar apenas uma parte das alterações quando enviadas ao repositório tal como acontecia no CVS. 8

9 Comparativo svn x cvs cvs  A posição dos parâmetros na linha de comando é importante.  A ordem dos parâmetros “-j” é importante! cvs update -j R_1_0_1 -j R_1_0_2  Migra todas as modificações ocorridas entre a liberação 1.0.1 e a liberação 1.0.2 para os artefatos locais; cvs update -j R_1_0_2 -j R_1_0_1  Desfaz, nos artefatos locais, todas as modificações ocorridas entre a liberação 1.0.1 e a liberação 1.0.2;  A ordem invertida dos parâmetros “-j” é útil para reverter arquivos específicos. Exemplo: cvs update -j R_1_0_2 -j R_1_0_1 hello. svn  A posição dos parâmetros na linha de comando não importa. Exemplo: $ svn log – r 123 hello.c $ svn log hello.c – r 123 9

10 Arquitetura 10 mod_dav_svn Plug-in para servidor Apache usado para disponibilizar repositório na rede. svnserve Servidor standalone que roda como daemon ou via ssh disponibilizando repositório na rede. Similar ao pserver do CVS.

11 Arquitetura Conexão Local  Necessário ter conta de usuário na máquina local.  Autenticação do próprio sistema operacional.  Uso de um desenvolvedor  Acesso direto ao arquivo com permissão de leitura/escrita Conexão Remota  Conexão via http ou https no caso do Apache.  Conexão via túnel ssh no caso de svnserve.  Não é necessário que usuários do subversion sejam usuários do servidor. Duas opções de armazenamento:  Berkeley Database: SGBD.  Apresenta vantagens como: integridade, recuperabilidade, atomicidade e backup.  FSFS: Baseado no sistema de arquivos do sistema operacional. 11

12 Problema da concorrência 12

13 Política pessimista 13

14 Política pessimista 14 Problemas administrativos  Bloqueios esquecidos podem atrasar o andamento do projeto Problemas de serialização desnecessária  Em alguns casos, as modificações atuam sobre partes independentes dos arquivos bloqueados Falsa sensação de segurança  Dependências semânticas podem cruzar a fronteira de arquivos Bloqueios são necessários  Quando se trata de arquivos que não podem ser combinados

15 Política otimista (1/2) 15

16 Política otimista (2/2) 16

17 Controle de concorrência no Subversion 17 Política pessimista e otimista em conjunto Qualquer artefato pode ser sujeito a bloqueio Artefatos podem ser demarcados com “necessita de bloqueio” Artefatos bloqueados por um desenvolvedor podem ser editados por outros  O commit dos outros somente ocorrerá depois do término do bloqueio  Os outros deverão fazer merge Artefatos bloqueados podem ser “roubados”  Bloqueio apóia à comunicação  Bloqueio não engessa o processo

18 Como roubar o lock? Administrador pode remover um lock caso necessário via comando svnadmin : admin$ svnadmin rmlocks Usuário pode remover um lock caso necessário usando opção –-force em svn lock e svn unlock : ciclano$ svn unlock --force banana.jpg ‘banana.jpg' unlocked. ciclano$ svn lock banana.jpg ‘banana.jpg' locked by user ‘ciclano'. Ou fazer os dois passos em um único passo: ciclano$ svn lock --force banana.jpg ‘banana.jpg' locked by user ‘ciclano'. 18

19 Repositório 19 Sistema de arquivos versionado  Check-in equivale a uma foto do sistema de arquivos num dado momento Versionamento global  Número de versão dado por commit  Identificador implícito de conjunto de modificações Algoritmo “Bubble up”  Economia de espaço  Velocidade na atualização  Controle do histórico

20 Sistema de arquivo convencional 20 Dimensão ESPAÇO

21 Sistema de arquivo versionado 21 Dimensão ESPAÇO Dimensão TEMPO

22 Versionamento global 22 O repositório é mais que um conjunto de arquivos independentes  Mudança de versionamento de arquivos para versionamento do repositório  Versão N é o estado do repositório depois do commit N  “Versão 5 do arquivo X” passa a ser lido como “arquivo X na versão 5 do repositório”

23 Versionamento global 23 Repositório (versão 1) Arquivo1 (versão 1) Arquivo2 (versão 1) Arquivo3 (versão 1) Repositório (versão 2) Arquivo1 (versão 2) Arquivo2 (versão 1) Arquivo3 (versão 1) Repositório (versão 0) 1º commit 2º commit Repositório (versão 3) Arquivo1 (versão 2) Arquivo2 (versão 3) Arquivo3 (versão 1) Arquivo4 (versão 3) Repositório (versão 4) Arquivo1 (versão 4) Arquivo2 (versão 3) Arquivo3 (versão 4) Arquivo4 (versão 3) 4º commit3º commit Arquivo1 Versão 1 Versão 2 Versão 4 Arquivo2 Versão 1 Versão 3 Arquivo3 Versão 1 Versão 4 Arquivo4 Versão 3 Relatório por arquivo

24 Versionamento global 24 Repositório (versão 1) Arquivo1 (versão 1) Arquivo2 (versão 1) Arquivo3 (versão 1) Repositório (versão 2) Arquivo1 (versão 2) Arquivo2 (versão 1) Arquivo3 (versão 1) Repositório (versão 0) 1º commit 2º commit Repositório (versão 3) Arquivo1 (versão 2) Arquivo2 (versão 3) Arquivo3 (versão 1) Arquivo4 (versão 3) Repositório (versão 4) Arquivo1 (versão 4) Arquivo2 (versão 3) Arquivo3 (versão 4) Arquivo4 (versão 3) 4º commit3º commit 1º commit Arquivo1 adicionado Arquivo2 adicionado Arquivo3 adicionado 2º commit Arquivo1 modificado 3º commit Arquivo2 modificado Arquivo4 adicionado Relatório por commit 4º commit Arquivo1 modificado Arquivo3 modificado

25 Comando log 25 Fornece um relatório sobre as versões do repositório  Por arquivo  Por commit Exibe, para cada versão  Identificação (número da modificação)  Quem (autor)  Quando (data)  Onde (caminhos)  Como (ação nos caminhos)  O que (mensagem)  Por que (número da solicitação de modificação)

26 Comando log 26 Exemplo Sintaxe svn log [-q] [-v] [-r VERSÃO] [URL] svn log -q https://reuse.cos.ufrj.br/svn/brecho/trunk/build.xml r92 | ronaldo | 2007-04-01 17:28:55 -0300 (dom, 01 abr 2007) r91 | paulacibele | 2007-03-19 12:53:47 -0300 (seg, 19 mar 2007) r90 | paulacibele | 2007-03-19 12:44:20 -0300 (seg, 19 mar 2007) r51 | marinho | 2006-01-18 19:03:39 -0200 (qua, 18 jan 2006) r47 | alexrd | 2006-01-07 10:44:46 -0200 (sáb, 07 jan 2006) r37 | mlopes | 2005-09-27 00:46:04 -0300 (ter, 27 set 2005) r31 | alexrd | 2005-09-12 11:15:33 -0300 (seg, 12 set 2005)... svn log -q https://reuse.cos.ufrj.br/svn/brecho/trunk/build.xml r92 | ronaldo | 2007-04-01 17:28:55 -0300 (dom, 01 abr 2007) r91 | paulacibele | 2007-03-19 12:53:47 -0300 (seg, 19 mar 2007) r90 | paulacibele | 2007-03-19 12:44:20 -0300 (seg, 19 mar 2007) r51 | marinho | 2006-01-18 19:03:39 -0200 (qua, 18 jan 2006) r47 | alexrd | 2006-01-07 10:44:46 -0200 (sáb, 07 jan 2006) r37 | mlopes | 2005-09-27 00:46:04 -0300 (ter, 27 set 2005) r31 | alexrd | 2005-09-12 11:15:33 -0300 (seg, 12 set 2005)...

27 Comando log 27 Exemplo Sintaxe svn log [-q] [-v] [-r VERSÃO] [URL] svn log -v -r 92 https://reuse.cos.ufrj.br/svn/brecho r92 | ronaldo | 2007-04-01 17:28:55 -0300 (dom, 01 abr 2007) | 1 line Caminhos mudados: M /trunk/build.xml M /trunk/src/br/ufrj/cos/reuse/biblioteca/category/CategoryUtil.java A /trunk/src/br/ufrj/cos/reuse/biblioteca/category/Suggestions.java M /trunk/src/br/ufrj/cos/reuse/biblioteca/category/dao/HibernateCategoryDAO.java Issue #234: Troca do algoritmo de sugestão de categorias svn log -v -r 92 https://reuse.cos.ufrj.br/svn/brecho r92 | ronaldo | 2007-04-01 17:28:55 -0300 (dom, 01 abr 2007) | 1 line Caminhos mudados: M /trunk/build.xml M /trunk/src/br/ufrj/cos/reuse/biblioteca/category/CategoryUtil.java A /trunk/src/br/ufrj/cos/reuse/biblioteca/category/Suggestions.java M /trunk/src/br/ufrj/cos/reuse/biblioteca/category/dao/HibernateCategoryDAO.java Issue #234: Troca do algoritmo de sugestão de categorias

28 Nomes padrões para versões 28 HEAD  Versão mais recente do recurso no repositório. BASE  Versão do recurso no espaço de trabalho. COMMITTED  Versão mais recente, anterior ou igual a BASE, em que o recurso foi modificado.  Versão do recurso no repositório após efetuar último commit. PREV  Versão anterior ao último commit realizado.  COMMITTED - 1

29 Nomes padrões para versões $ svn diff -r PREV:COMMITTED hello.c # mostra as últimas alterações efetuadas em hello.c $ svn log -r HEAD # mostra log da última versão do repositório. $ svn diff -r BASE:HEAD hello.c # compara a versão local (sem alterações) com a última versão do repositório. $ svn log -r BASE:HEAD # mostra log dos commits realizados no repositório desde o último update realizado no espaço de trabalho.

30 Algoritmo “Bubble up” 30 Mecanismo interno do Subversion para controle do repositório  Entender esse mecanismo ajuda a entender o funcionamento do Subversion Para um dado commit as ações são  Aplicadas nas folhas  Propagadas para os diretórios pais Arquivos e diretórios não afetados pelas modificações são preservados Algoritmo utilizado para armazenamento  Reverse delta

31 Repositório inicial 31 Repositório 1 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3

32 Commit: modificação em um único arquivo 32 Repositório 1 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3

33 Propagação para o diretório pai 33 Repositório 1 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3 Diretório 2 Arquivo 3

34 Criação da nova versão 34 Repositório 12 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3 Diretório 2 Arquivo 3

35 Commit: adição de um novo arquivo 35 Repositório 12 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3 Diretório 2 Arquivo 3 Arquivo 4

36 Propagação para o diretório pai 36 Repositório 12 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3 Diretório 2 Arquivo 3 Diretório 1 Arquivo 4

37 Criação da nova versão 37 Repositório 12 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3 Diretório 2 Arquivo 3 3 Diretório 1 Arquivo 4

38 Cópia “barata” 38 O projeto interno do Subversion visa prover cópias “baratas” de diretório  Os dados não são duplicados  Conceito semelhante a hard-link do unix  Somente quando há mudanças, o link é quebrado  Tempo constante gasto para cópias Mecanismo utilizado para  Etiquetas (tags)  Ramos (branches)

39 Versão atual do repositório 39 Repositório 5 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3 Diretório 3 Arquivo 4

40 Diretório 2 movido para dentro do Diretório 1 com outro nome 40 Repositório 5 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3 Diretório 3 Arquivo 4 Diretório 2’

41 Conteúdo idêntico ao original 41 Repositório 5 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3 Diretório 3 Arquivo 4 Diretório 2’

42 Propagação para o diretório pai 42 Repositório 5 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3 Diretório 1 Diretório 3 Arquivo 4 Diretório 2’

43 Criação da nova versão 43 Repositório 56 Diretório 1 Arquivo 1 Diretório 2 Arquivo 2 Arquivo 3 Diretório 1 Diretório 3 Arquivo 4 Diretório 2’

44 Layout do repositório 44 Layout é uma convenção  Permite mais de um projeto por repositório  Ajuda a organizar cada projeto Layout sugerido  Um diretório por projeto na raiz do repositório Layout para cada projeto  Um diretório para o ramo principal: trunk  Um diretório para os ramos: branches  Um diretório para as etiquetas: tags

45 Layout do repositório 45 https://svn.ic.uff.br/ proj1/ trunk/ branches/ tags/ dissertacoes/ fulano/ trunk/ branches/ tags/ beltrano/ trunk/ branches/ tags/...

46 Etiquetas e Ramos 46 Etiquetas (tags)  Cópias “baratas” do trunk para o diretório tags  Troca de nome pelo nome da etiqueta  Por convenção, nenhuma edição é feita sobre esse diretório copiado Ramos (branches)  Cópias “baratas” do trunk para o diretório branches  Troca de nome pelo nome do ramo  Edição no diretório copiado

47 Comando copy 47 Copia um arquivo ou diretório com histórico entre caminhos no repositório ou espaço de trabalho Casos típicos  URL  URL: cópia executada atomicamente no servidor, utilizada usualmente para criar etiquetas e ramos  Diretório local  diretório local: cópia feita no cliente e adição (com histórico) agendada para o próximo commit

48 Comando copy 48 Exemplo Sintaxe svn copy ORIGEM DESTINO [-m MENSAGEM] svn copy dir1 dir2/novo_dir_1 svn copy https://svn.ic.uff.br/proj1/trunk https://svn.ic.uff.br/proj1/branches/1.0.x -m “Criação do ramo 1.0.x” svn copy https://svn.ic.uff.br/proj1/branches/1.0.x https://svn.ic.uff.br/proj1/tags/1.0.1 -m “Criação da etiqueta 1.0.1” svn copy dir1 dir2/novo_dir_1 svn copy https://svn.ic.uff.br/proj1/trunk https://svn.ic.uff.br/proj1/branches/1.0.x -m “Criação do ramo 1.0.x” svn copy https://svn.ic.uff.br/proj1/branches/1.0.x https://svn.ic.uff.br/proj1/tags/1.0.1 -m “Criação da etiqueta 1.0.1”

49 Espaço de trabalho 49 Diretório comum no sistema de arquivos local Guarda uma cópia limpa do checkout (.svn)  Permite algumas operações off-line  Permite transmissão de diffs para o servidor Área isolada das modificações de outros desenvolvedores  Suas modificações podem ser publicadas com commit  Modificações de outros podem ser incorporadas com update Um usuário pode ter vários espaços de trabalho para um mesmo projeto

50 Comando check-out 50 Constrói um espaço de trabalho a partir de uma versão do repositório (ou parte dela)

51 Comando check-out 51 Exemplo Sintaxe svn checkout [-r VERSÃO] URL [CAMINHO] svn checkout https://svn.ic.uff.br/proj1/trunk svn checkout -r 15 https://svn.ic.uff.br/proj1/trunk svn checkout https://svn.ic.uff.br/proj1/tags/1.0.3 rel1.0.3 svn checkout https://svn.ic.uff.br/proj1/trunk svn checkout -r 15 https://svn.ic.uff.br/proj1/trunk svn checkout https://svn.ic.uff.br/proj1/tags/1.0.3 rel1.0.3

52 Comando commit 52 Envia modificações do espaço de trabalho para o repositório  Detecta automaticamente o que mudou  Libera todos os bloqueios  Aplica a modificação de forma atômica no repositório Pode não conseguir enviar caso algum outro usuário tenha dado commit  Necessário um update

53 Comando commit 53 Exemplo Sintaxe svn commit [-m MENSAGEM] [CAMINHO] svn commit -m “Adição da versão 1.4.5 do modelo” svn commit -m “Issue #34: Correção de erro de digitação” src svn commit -m “Adição da versão 1.4.5 do modelo” svn commit -m “Issue #34: Correção de erro de digitação” src

54 Comando update 54 Atualiza o espaço de trabalho com as últimas modificações existentes no repositório Pode encontrar conflitos durante a atualização  É importante verificar cada um dos arquivos atualizados Ações sobre o espaço de trabalho  Adição de arquivos (A)  Remoção de arquivos (D)  Atualização de arquivos (U)  Arquivos com conflito (C)  Arquivos combinados (G)

55 Comando update 55 Exemplo Sintaxe svn update [-r VERSÃO] [CAMINHO] svn update svn update -r 12 svn update dir1 svn update svn update -r 12 svn update dir1

56 Comportamento dos comandos Arquivo modificado localmente Arquivo modificado no repositório Comando commit Commando update Não Nenhuma ação NãoSimNenhuma ação Versão local substituída pela versão do repositório SimNãoPublica a versão local no repositório Nenhuma ação Sim Falha, avisando que o arquivo está desatualizado Versão local combinada com a versão do repositório 56

57 Ciclo básico de trabalho 57 Construção do espaço de trabalho svn checkout svn update svn switch Implementação svn add svn delete svn copy svn move svn lock svn blame svn log Verificação svn status svn diff svn revert Integração svn update svn resolved svn commit

58 Junção de ramos 58 Deve ser feita em um espaço de trabalho limpo  Check-out do destino da junção Deve ser entendida como diff & apply Diff é dependente de ordem  Diff(A, B): ações necessárias para transformar o caminho A no caminho B O diff pode atuar tanto no espaço quanto no tempo  Espaço: diff entre dois diretórios (copiados de um lugar comum)  Tempo: diff entre duas versões de um mesmo diretório

59 Merge no tempo 59 Normalmente usado para ramos Espaço de trabalho apply: ∆ 1 ∆ 1 = diff(v4, v10) trunk     12 3 6811 12457109 131415 branches/1.0.x

60 Merge no espaço 60 Normalmente usado para etiquetas 1.0.01.0.1 Espaço de trabalho apply: ∆ 1 ∆ 1 = diff(1.0.0, 1.0.1) trunk branches/1.0.x tags     12 34 6811 1257109 131415

61 Comando merge 61 Aplica a diferença entre dois caminhos no espaço de trabalho svn merge A B  Calcula as ações que precisam ser feitas para transformar o caminho A no B  Aplica essas ações no espaço de trabalho

62 Comando merge 62 Exemplo Sintaxe svn merge [-c VERSÃO | -r VERSÃO1:VERSÃO2] CAMINHO svn merge CAMINHO1 CAMINHO2 svn merge [-c VERSÃO | -r VERSÃO1:VERSÃO2] CAMINHO svn merge CAMINHO1 CAMINHO2 svn merge https://svn.ic.uff.br/proj1/trunk svn merge --reintegrate https://svn.ic.uff.br/proj1/branches/1.0.x svn merge -r 20:23 https://svn.ic.uff.br/proj1/branches/1.0.x svn merge -c 23 https://svn.ic.uff.br/proj1/branches/1.0.x svn merge -c -23 https://svn.ic.uff.br/proj1/branches/1.0.x svn merge https://svn.ic.uff.br/proj1/tags/1.0.1 https://svn.ic.uff.br/proj1/tags/1.0.2 svn merge https://svn.ic.uff.br/proj1/trunk svn merge --reintegrate https://svn.ic.uff.br/proj1/branches/1.0.x svn merge -r 20:23 https://svn.ic.uff.br/proj1/branches/1.0.x svn merge -c 23 https://svn.ic.uff.br/proj1/branches/1.0.x svn merge -c -23 https://svn.ic.uff.br/proj1/branches/1.0.x svn merge https://svn.ic.uff.br/proj1/tags/1.0.1 https://svn.ic.uff.br/proj1/tags/1.0.2

63 Comando merge Conflitos marcam os arquivos com ‘C’. Arquivos com conflito podem ser identificados com svn update. Esta característica torna possível a análise dos arquivos originais e o uso de outras ferramentas na junção. Três arquivos temporários são criados: .rOLDREV : Arquivo local que existe no espaço de trabalho e que foi usado como BASE para as modificações efetuadas antes do update. .rNEWREV : Arquivo que existe no repositório após executar update e trazê-lo para o espaço de trabalho. Corresponde ao HEAD. .mine: Arquivo que identifica o código que estava sendo modificado no espaço de trabalho antes do update. Contém as modificações locais.  : Arquivo com conflitos identificados após executar update. 63

64 Comando merge Conflitos podem ser resolvidos no arquivo original do próprio espaço de trabalho. Depois:  Executar svn revert caso necessário reverter as alterações.  Executar snv resolved após resolver os conflitos.  Apagar os arquivos temporários. Resolve conflito com svn resolved 64

65 Sincronização 65 ∆ 1 = diff(2, 10) trunk 457109 svn checkout https://svn.ic.uff.br/proj1/branches/sm15 Espaço de trabalho = branches/sm15 svn merge https://svn.ic.uff.br/proj1/trunk Espaço de trabalho = branches/sm15 + ∆2 svn checkout https://svn.ic.uff.br/proj1/branches/sm15 Espaço de trabalho = branches/sm15 svn merge https://svn.ic.uff.br/proj1/trunk Espaço de trabalho = branches/sm15 + ∆2 branches/sm15 1 3 68112 ∆ 2 = diff(2, 11)

66 Sincronização 66 ∆ 1 = diff(2, 10) trunk 4579 svn checkout https://svn.ic.uff.br/proj1/trunk Espaço de trabalho = trunk svn merge --reintegrate https://svn.ic.uff.br/proj1/branches/sm15 Espaço de trabalho = trunk + ∆1 svn checkout https://svn.ic.uff.br/proj1/trunk Espaço de trabalho = trunk svn merge --reintegrate https://svn.ic.uff.br/proj1/branches/sm15 Espaço de trabalho = trunk + ∆1 branches/sm15 1 3 68112 ∆ 2 = diff(2, 11) ∆2∆2 1210

67 Sincronização 67 ∆ 1 = diff(2, 10) trunk 4579 branches/sm15 1 3 682 ∆ 2 = diff(2, 11) ∆2∆2 ∆1∆1 1210 1311

68 Ciclo básico de junção 68 Construção do espaço de trabalho svn checkout svn update svn switch Junção svn merge svn blame svn log Verificação svn status svn diff svn revert Integração svn update svn resolved svn commit

69 Propriedades 69 Cada diretório ou arquivo pode ter metadados anexados a ele  Tuplas  Versionados Algumas propriedades built-in  svn:mime-type: tipo do arquivo  svn:ignore: elementos que não devem ser versionados em um diretório  svn:needs-lock: indica que o arquivo precisa de política de controle de concorrência pessimista

70 Propriedades Metadados são propriedades incorporadas a um item de configuração no espaço de trabalho. Associado ao arquivo ou diretório. Não versionado quando corresponde às informações de uma versão do arquivo. Versionado quando corresponde às informações do arquivo. São armazenados internamente como arquivo xml. 70

71 Propriedades Utiliza tuplas propriedade:valor onde propriedade serve como chave de busca.  owner do arquivo : ownership.author  scripts de testes: test.unit Sintaxe:  svn propset property-key “ property value ”  svn propset copyright '(c) 2006 Red-Bean Software' calc/* svn:mime-type: Identifica tipo de arquivo (e.g: texto, binário caso contrário). 71

72 Propriedades Propriedade svn:needs-lock pode ser utilizada para forçar o uso de lock em um arquivo.  Arquivo fica read-only e somente com o uso do lock pode ser read-write.  É uma forma de forçar uma notificação sobre o bloqueio.  Não fica dependente do comando svn status --show-updates quando quer ser informado sobre o lock. 72

73 Referências 73 http://svnbook.red-bean.com/en/1.5 http://svn.apache.org/repos/asf/subversion/trunk/notes/sub version-design.html

74 INTRODUÇÃO COMPARATIVO CARACTERISTICAS COMANDOS RAMOS E JUNÇÕES REBASE x MERGE CHERRY PICKING Git 74

75 Introdução Controle de versões distribuído. Desenvolvido em 2005 e utilizado pela comunidade linux. Suporte ao desenvolvimento não linear. Rápido, open-source, gratuíto. Todo o histórico disponível como uma cópia local. A operação mais lenta é justamente clonar o repositório. Disponível em: http://git-scm.com/http://git-scm.com/ 75

76 Comparativo com svn 76

77 Comparativo com svn Não é considerado uma evolução do svn 77

78 Modelo de Desenvolvimento 78 Modelo de desenvolvimento utilizado no repositório GitHub Modelo de desenvolvimento centralizado

79 Versionamento 79 Snapshots, ao invés de Deltas.

80 Referência Tudo no Git é referenciado como um objeto da seguinte forma: 24b9da6552252987aa493b52f8696cd6d3b00373 Mecanismo que usa para checksum: SHA-1 hash Git armazena/endereça pelo hash value do conteúdo do arquivo. 80

81 Tipos 81

82 Referência 82

83 Referência 83

84 Referência 84

85 Referência 85

86 Comandos Iniciais $ git init : cria um repositório git. $ git clone: traz uma cópia do repositório git existente (remoto).  git://  http(s)://  ssh://user@server:/path.git 86

87 Clone 87

88 Log $ git log: informa o log dos arquivos modificados. 88

89 Estágios Três estágios: commited, modified, staged 89

90 Commit $ git add : adiciona arquivos no estágio staged. $ git add README test.rb LICENSE $ git commit -m 'initial commit of my project' 90

91 Add/Commit 91

92 Add/Commit 92

93 Add/Commit 93

94 Add/Commit 94

95 Commit A medida que novos commits são feitos, guarda-se a referência para o snapshot. 95

96 Comandos $ git rm: remove um arquivo da staging area e working directory. $ git status : verifica o estágio do arquivo. # On branch master # Changes to be committed: # (use "git reset HEAD..." to unstage) # # new file: README # $ git diff: mostra as diferenças entre dois arquivos. $ git reset HEAD : retorna ao estágio unstaged. $ git checkout -- : discarta as modificações no working directory. 96

97 Ramos Ponteiros para commits. 97

98 Ramos $ git checkout testing 98

99 Ramos $ vim test.rb $ git commit -a -m 'made a change' 99

100 Junções $ git checkout -b iss53 vim index.html $ git commit -a -m 'added a new footer [issue 53]' 100

101 Junções Commit antes de mudar de branch. $ git checkout master $ git checkout -b hotfix Switched to a new branch "hotfix“ $ vim index.html $ git commit -a -m 'fixed the broken email address‘ [hotfix]: created 3a0874c: "fixed the broken email address" 1 files changed, 0 insertions(+), 1 deletions(-) 101

102 Junções $ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast forward README | 1 – 1 files changed, 0 insertions(+), 1 deletions(-) Merge fast-forward. Possível apagar ramo depois da junção. $ git branch -d hotfix Deleted branch hotfix (3a0874c). 102

103 Junções $ git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'finished the new footer [issue 53]' [iss53]: created ad82d7a: "finished the new footer [issue 53]" 1 files changed, 1 insertions(+), 0 deletions(-) 103

104 Junções Merge com um ancestral comum: 3-way-merge 104

105 Conflitos $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. [master*]$ git status index.html: needs merge # On branch master # Changes not staged for commit: # (use "git add..." to update what will be committed) # (use "git checkout --..." to discard changes in working directory) # # unmerged: index.html 105

106 Comandos $ git branch : cria um ramo. $ git checkout –b : cria e referencia o ramo criado. $ git checkout : muda a referência do ramo. $ git merge : merge fast-forward/3-way merge. $ git branch -d : apaga um ramo. $ git branch : lista os ramos $ git branch -v : mostra o ultimo commit nos ramos $ git branch --merged : mostra os ramos que foram juntados $ git branch --no-merged : mostra os ramos ainda sem junções. 106

107 Tag $ git tag: lista as tags existentes. $ git tag -a v1.4 -m 'my version 1.4': cria uma tag. $ git show v1.4: exibe informações da tag. $ git push origin v1.5: Envia tag para repositório remoto. 107

108 Fetch $ git fetch: traz as modificações do repositório remoto. 108

109 Fetch $ git remote add: adiciona como referência um repositório remoto. 109

110 Fetch 110

111 Push/Pull $ git pull: traz as modificações do repositório remoto e faz o merge com o repositório local. $ git push: envia modificações para o repositório remoto. $ git push [remote-name] $ git push [remote-name] [branch-name] $ git push origin master 111

112 Push/Pull 112

113 Push/Pull 113

114 Push/Pull 114

115 Push/Pull 115

116 Push/Pull 116

117 Push/Pull 117

118 Rebase $ git rebase: Traz as modificações que estão no estágio commited de um ramo para outro ramo. Não é recomendado utilizar rebase quando as modificações já foram para o repositório remoto (c/ git push) e são publicas. 118

119 Rebase 119

120 Rebase 120

121 Rebase 121

122 Rebase 122

123 Rebase 123

124 Rebase 124

125 Rebase 125

126 Rebase 126

127 Rebase 127

128 Rebase 128

129 cherry-picking http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html Envia um commit específico com o comando: $ git cherry-pick $ git cherry-pick E 129

130 cherry-picking http://think-like-a-git.net/sections/rebase-from-the-ground-up/cherry-picking-explained.html $ git cherry-pick C D E Neste caso o commit muda o ID de C para C’ sendo o pai no grafo diferente. Usado quando o time decide quais features devem ser incorporadas na mainline antes do fechamento da release. 130

131 Referências Guia Prático: http://rogerdudler.github.io/git-guide/index.pt_BR.html "Pro Git" Book http://git-scm.com/bookhttp://git-scm.com/book Git reference http://git-scm.com/docshttp://git-scm.com/docs http://www.slideshare.net/chacon/getting-git http://training.github.com/resources/videos/ 131