Curso de Controle de Versão com Subversion

Olá pessoal essa é a primeira aula do curso de gerência de configuração de software mas o que é gerência de configuração de software exatamente se você mexe com desenvolvimento de software Então você precisa muito de gerência de configuração de software mesmo que você ainda não saiba disso a gerência de configuração de software lida com Todas aquelas mudanças que nenhum projeto Escapa durante o desenvolvimento mudança nos requisitos Mud no código fonte Mud no ambiente deim etc paraim ordenado e acia de configuração de software resp seguintes perguntas básicas por O sistema mudou Quais foram as mudan o

sistema continua funcionando pergunta dessas é respondid por uma atividade da gercia de configuração de software a primir pergunta é respondida pela atividade de controle de mudança que registra e Acompanha cada pedido de mudança a segunda pergunta é tratada pelo controle de versão que registra a evolução do projeto e a última pela integração contínua estabelece a integridade do projeto a cada alteração no histórico um fluxo de trabalho muito usado dessas atividades funciona assim todo pedido de mudança que chega é registrado em um ticket esse pedido é avaliado e agrupado por algum critério e fica aguardando a

Implementação quando chega o momento o desenvolvedor responsável pelo ticket faz as implementações necessárias no código fonte e e registra essa configuração no controle de versão em uma revisão então o controle de versão dispara dois avisos um deles vai para controle de mudança informando que o ticket foi implementado geralmente o controle de mudança usa essa informação para mudar o estado do Ticket e manter a Rastreabilidade entre a solicitação de mudança e a implementação o outro aviso vai para integração contínua que dispara uma série de testes automatizados e coleta de métricas de qualidade os resultados são apresentados

a todos os membros da equipe que poem fazer ajustes e correções Se necessário para implementar esse Flux o primeiro passo é escolher as ferramentas adequadas Existem várias opções de Ferramentas para controle de mudança controle de versão e integração contínua o desafio é escolher as ferramentas certas que combinam com o perfil da sua equipe e do seu projeto para que a gerência de configuração de software funcione não basta só ter as ferramentas corretas é preciso saber usá-las senão é bem provável que você e sua equipe acabem subutilizando as ferramentas de uma maneira burocrática ou ainda pior

usando de modo errado e perdendo a Informação Resumindo gência de configuração de software é um conjunto de atividades de apoio que lida com as mudanças inerentes ao desenvolvimento de software mantendo a integridade e a estabilidade durante a evolução do projeto a gerência de configuração de software é essencial para produzir software de qualidade existem diversas ferramentas open source de GCS disponíveis não é desculpa para para Você não usar alguma para implementar a gerência de configuração do software é preciso um esforço inicial para entender os conceitos definir alguns processos integrar e aprender a usar as ferramentas mas

é um investimento baixo pelo retorno que oferece essa primeira aula fica por aqui na próxima aula Vamos estudar mais a fundo para que serve o controle de diversão até lá [Música] Olá pessoal Essa é a segunda aula do curso de gerência de configuração de software Vamos ver em mais detalhes para que serve o controle de versão que é a parte central e mais importante da gerência de configuração de software bom talvez você já tenha passado por algumas situações assim durante o desenvolvimento essa mudança não deu certo vamos voltar como estava antes o que mudou nessa

rotina quando foi essa mudança Quem é o responsável Esse defeito já tinha sido corrigido como reapareceu a nova função que implementei ontem era para estar aqui mais sumiu preciso daquela versão que está no cliente Cadê os arquivos como fazer os testes sem parar o desenvolvimento o controle de diversão resolve esses tipos de problemas com três serviços fundamentais registra a evolução do Projeto controla concorrência de edição dos arquivos cria e mantém variações do projeto vamos ver cada uma dessas funcionalidades primeiro o registro da evolução do projeto Imagine a seguinte situação você mexu no cóigo por um

bom tempo e finalmente funcionando compila Passa nos testes etc o melhor fazer agora é registrar ess estado dos arquivos antes de passar próxima impl um Mod bastante comum de fazer esse regist manualmente é compactando os arquivos e adicionando uma data ou uma numeração sequencial no nome do arquivo compactado um dos primeiros problemas que aparec na solução manual é que esses arquivos de backup vão se acumulando com o tempo e fica muito difícil de gerenciá-los outro problema é que só os backups não bastam Você também precisa conseguir extrair informações úteis como o que foi alterado dentro

uma revisão e Outra quem alterou o arquivo tal quando esse trecho foi incluído nesse arquivo etc essa tela apresenta um relatório fornecido por uma ferramenta de controle de versão você pode ar que há informações sobre as revisões existentes Quem é o autor de cada uma das revisões quando foram feitas e o que foi alterado fazer isso manualmente talvez até seja possível mas é muito trabalhoso e demorado melhor deixar isso com controle De versão que faz tudo isso melhor e mais rápido a próxima funcionalidade do controle de versão é que torna o trabalho em equipe possível

qualquer projeto não trivial precisa ser desenvolvido em equipe e isso significa que várias pessoas precisarão editar os mesmos arquivos ao mesmo tempo o problema dessa concorrência é que se não houver nenhum tipo de coordenação uma pessoa acaba Sobrescrevendo as alterações de outra levando a algum tipo de perda de código os sintomas clássicos dessa situação são o desaparecimento de novas implementações e o reaparecimento de defeitos que já haviam sido consertados o controle de versão possui mecanismo específicos para coordenar a edição concorrente de arquivos os mecanismos disponíveis são travamento mesclagem de arquivos e Ramos individuais Mas isso

é assunto para Outro Capítulo projetos de software também precisam de mais outro nível de paralelismo para poder lidar simultaneamente com atividades distintas de desenvolvimento por exemplo manter diferentes versões do software em produção enquanto se desenvolvem novas funcionalidades para a próxima versão que ainda será lançada o controle de versão consegue manter linhas paralelas e isoladas de desenvolvimento ideais para esses Casos Resumindo controle de versão é uma das Ferramentas mais importantes de desenvolvimento de software e é muito mais do que backup se você só consegue isso do seu controle de versão Então você tá subutilizando a ferramenta

o controle de versão mantém o histórico da evolução do projeto torna possível trabalhar em equipe e permite criar variações do projeto isso seria impraticável manualmente e ficamos por aqui nessa Aula a partir da próxima aula veremos uma série de capítulos que analisam em profundidade como controle de versão funciona internamente Além disso teremos demonstrações práticas como uma ferramenta de controle de versão até mais [Música] Olá pessoal vamos a mais uma aula do curso de gerência de configuração de software nos vídeos anteriores vimos o que é gerência de configuração de Software e para que serve o controle

de versão nessa aula vamos tratar da parte do funcionamento do controle de versão relacionado com o repositório e a área de trabalho todo controle de versão possui dois elementos básicos o repositório e o diretório de trabalho o repositório é onde fica armazenado o histórico do projeto o diretório de trabalho também chamado de área de trabalho ou cópia de trabalho é um diretório monitorado pelo Controle de versão que contém os arquivos do projeto com os quais o desenvolvedor trabalha para implementar uma solicitação de mudança que é o ticket o desenvolvedor mexe nos arquivos do diretório de

trabalho até chegar a uma configuração consistente então registra essa configuração no repositório através de uma operação de comit gerando uma nova revisão configuração é o estado dos arquivos do projeto em determinado Momento é como uma foto que contém a posição do projeto naquele instante revisão é uma configuração registrada no repositório durante a implementação de uma mudança o diretório de trabalho passa por várias configurações porque cada edição adição exclusão etc muda o estado do conjunto dos arquivos do projeto Nem todas as configurações são interessantes para serem registradas no repositório se a configuração não está Finalizada não

compila ou não passa nos testes Então ela só problema se for compartilhado com outras pessoas da equipe Na verdade só a configuração final de cada implementação costuma ser interessante para ser registrada no repositório isso depois que estiver compilando e passando nos testes Claro a recomendação é a seguinte cada revisão deve conter uma implementação completa funcional e testada independente da ferramenta de Controle de diversão qualquer revisão possui pelo menos os seguintes atributos ID data e hora autor descrição e configuração ide um número data hora e autor são autoexplicativos configuração nós acabamos de ver o que que

é com essas informações já é possível responder as perguntas quem mudou quando e como estava o projeto naquele momento falta analisar melhor o campo descrição e o seu papel na Rastreabilidade é poder seguir o trajeto de uma solicitação de mudança desde que foi proposta até o momento em que é implementada podendo saber quem implementou como e quando e o caminho contrário também Isto é dado uma revisão é importante poder saber por que a alteração foi feita quem pediu a mudança quando foi feito o pedido etc como Parte dessas informações está no Ticket do controle de

mudança e outra parte está na revisão do controle de versão então é Necessário algum tipo de amarração entre os dois a amarração no controle de versão fica no campo descrição que também é chamado de mensagem de log ou mensagem de consolidação a descrição é apenas um campo texto para resumir as mudanças realizadas Mas como as mudanças já estão descritas no Ticket Então não é necessário repetir nem resumir novamente na descrição da revisão basta referenciar o ticket que gerou a mudança usando padrão ação # númerodo ticket Barra título do Ticket por exemplo resolve #123song repositório envia

ao controle de mudança bastante relacionado com o conceito de revisão temos o Chang set quer dizer conjunto de alterações enquanto uma revisão é uma configuração registrada no repositório o Change set é a diferença entre duas configurações em outras palavras o chs responde a pergunta o que mudou pode ser a Diferença entre uma configuração não consolidada no diretório de trabalho e uma revisão ou entre duas revisões por exemplo seja o arquivo função PP na revisão zero o resultado da função Max está errado porque as linhas c e 7 estão trocadas o teste da linha nove também

pode ser melhorado a correção e a melhoria foram feitas na revisão um o que mudou da revisão zero para a revisão 1 Isto é o Change set 1 é apresentado na terceira coluna no Formato dif Unificado pra gente entender melhor como funciona esse dif imagina o seguinte você precisa dar instruções por telefone para outra pessoa transformar o arquivo da revisão zero paraa revisão um O que você faria é ler as instruções do dif para outra pessoa para que ela Execute os passos especificados Seria algo assim depois da linha quatro incluo as seguintes linhas com return

a e else pule uma linha exclua quatro linhas e Insira a linha com o assert no fim da execução das instruções a pessoa terá exatamente o arquivo função PP na revisão 1 perceba que configuração em Change set são derivados um do outro se você aplicar um Change setet sobre uma configuração você tem outra configuração se você calcular a diferença entre duas configurações você tem um Change set Apesar dessa diferença conceitual é comum encontrar na literatura sobre Controle de diversão os dois conceitos sendo usados como equivalentes não são recapitulando alguns conceitos importantes configuração é o estado

do conjunto de arquivos do projeto em um determinado momento visão é uma configuração registrada no repositório Change set é o conjunto de diferenças entre duas configurações e versão é uma revisão que é usado em produção quando a gente fala de controle De versão na verdade talvez um nome mais apropriado seria controle de revisão mas não é o caso Voltando às operações do controle de versão é importante saber que algumas delas acontecem no diretório de trabalho tal como a adição de um arquivo a configuração remoção renomeação cópia e a edição que não é uma operação do

controle de versão e sim de um editor de texto uma ide etc algumas operações acontecem entre o repositório e o Diretório de trabalho como o commit que registra a configuração do diretório de trabalho no repositório e o update que é simétrico ao commit Isto é traz para o diretório de trabalho uma configuração registrada no repositório a operação de dif que calcula o chs ela pode ser executada tanto entre o diretório de trabalho e o no repositório como apenas no repositório ao comparar duas revisões quaisquer um exemplo de operação Que acontece só no repositório é o

log que Obté o histórico do projeto Outro exemplo é o Blame que mostra o responsável e a revisão da alteração de cada linha de um arquivo todas essas operações serão vistas com mais detalhes quando apresentarmos a demonstração da ferramenta de controle de versão específica seja ela subversion ou Git ou Mercurial e ficamos por aqui na próxima aula veremos a primeira versão do fluxo de trabalho que você deve seguir até [Música] lá agora que vimos como é funcionamento básico do controle de versão é importante estabelecer um procedimento de trabalho para garantir que você não vai esquecer

de executar nenhum passo durante a implementação de uma tarefa o fluxo de trabalho recomendado para esse módulo do curso é esse aí o primeiro passo é obter o próximo ticket a partir do controle de mudança isso está na linha Três nesse primeiro módulo não estamos usando essa ferramenta ainda mas vamos simular isso nos exercícios e demonstrações as linhas 5 a no indicam que a implementação deve ser feita até que se chegue a uma configuração completa e estável Isto é esteja finalizada construía e testada na linha 11 é definida a mensagem de consolidação seguindo o padrão

recomendado para manter a rastreabilidade e na última linha a Consolidação é feita através do comit Então você executar esse procedimento até que tudo isso fique automático antes de finalizar a aula eu quero ressaltar que essa é a primeir versão do fluxo de trabalho Ela está de aco com as necessidades desse módulo do curso na qual você trabalha individualmente um projeto simples mas vamos ver outras versões a partir dos próximos módulos quando você aprenderá operações mais avançadas tais Como trabalho em equipe e variações de projeto e por enquanto é isso Até a próxima [Música] aula Olá

pessoal nessa aula veremos como instalar o Windows subsystem for Linux no Windows 10 se você usa o Linux ou Mac os Então você já tem a interface gráfica de linha de comando necessária não precisa assistir essa aula mas o que é o Windows subsystem for Linux é uma camada de compatibilização que permite executar Binários do Linux nativamente no Windows 10 ou no Windows Server 2019 no nosso caso particular vamos usar o Windows subsystem for Linux para executar comandos best pelo terminal Mas por que usar a linha de comando bem a interface gráfica do controle de

versão não faz tudo cobre apenas as funcionalidades mais básicas e comuns principalmente se você usa o Git em menor grau o Mercurio mais cedo ou mais tarde você Vai ter que usar uma operação na linha de comando então é melhor estar preparado mas por instalar o Linux no Windows o objetivo é uniformizar a interface de linha de comando de modo que você possa aplicar as listagens dos exemplos e demonstrações usadas no curso que estão em B diretamente no Windows a instalação é composto por duas partes a primeira parte é habilitar o Windows subsystem for Linux

e a segunda parte é instalar uma distribuição Linux no caso Buntu a partir da loja do Windows o jeito mais simples de habilitar o Linux no Windows é abrindo powershell como administrador e executando Esse comando aí o computador terá que ser reiniciado depois bom depois de reiniciado você tem que ir à loja virtual da Microsoft e escolher o Ubuntu para baixar e instalar isso demora hein por isso vou fazer um corte no vídeo para Adiantar depois de instalado você tem que criar um usuário e senha esse usuário não tem nenhuma relação com o usuário do

Windows Mas é bom manter o mesmo para simplificar e agora você já tá no Linux o próximo passo é atualizar o sistema Execute sudo APT update e Sud APT upgrade Men Y isso deve demorar alguns minutos então também vou adiantar o vídeo para ir pro final da atualização os sistemas de arquivos do Linux e do Windows são separados porém o Sistema de arquivos do windows está montado a partir do diretório bar mnt e pode ser acessado a partir daí por exemplo o drive C2 do Windows está em Bar mnt barc para usuário de nome Fulano

o caminho dos seus arquivos no Windows É bar mnt barc bar users barano então você pode acessar os arquivos do windows a partir do Linux mas não deve fazer o contrário para não corromper os arquivos e é isso agora você está pronto Para usar o BH no Windows [Música] Olá pessoal nós vamos ver a instalação do subversion no Linux e no Windows vamos começar pela instalação do BL Linux que é bem direta basta executar Esse comando aí e pronto o cadif 3 é opcional mas vai ajudar bastante na visualização de diferenças e na resolução de

conflitos durante mesagens é bom instalar só lembrando que esse Fulano tio que aparece faz parte do Prompt Fulano é usuário e ti indica que o diretório corrente é home voltando ao processo então para testar Você pode executar o comando svn tro Version para confirmar a instalação agora vamos refazer a instalação no Windows no Windows a melhor opção é instalar o tortu svn porque instala interface gráfica e se você habilitar também instala subversion para usar na linha de comando o programa de instalação pode ser obtido a partir Desse link aí a instalação é simples e basta

clicar next até o fim do processo você não precisa instalar Nenhuma ferramenta gráfica adicional no Windows porque o tortu svn já vem com suas próprias ferramentas de visualização e edição de conflitos e elas são muito boas o tortu svn Se integra com explorador de arquivos clique com o botão secundário no mouse e veja se aparecem as opções correspondentes no Menu de contexto uma sugestão é alterar os ícones de estado há vários conjuntos disponíveis no menu de contexto Escolhe a opção settings e depois icon set eu prefiro usar o conjunto Win 10 porque é mais moderno

é só aplicar fechar a janela e quando reiniciar o Windows Eles serão usados e é só isso na próxima aula veremos o subv em Ação usando alguns comandos básicos até lá [Música] Olá pessoal Essa é a segunda aula prática de controle de diversão com subversion na qual veremos o funcionamento de algumas operações básicas relacionadas ao diretório de trabalho e ao repositório nessa aula vamos abordar as seguintes operações criação do repositório adição exclusão cópia e renomeação de arquivos verificação do estado e diferenças do diretório de trabalho consolidação e Visualização do histórico essa operações serão explicadas através

de uma demonstração que será executada duas vezes uma Vez pelo terminal usando comandos de linha que são mais simples diretos e fáceis de serem acompanhados e na segunda vez o mesmo exemplo será refeito através da interface gráfica do tortu as svn no Windows demonstração pelo terminal Vamos criar o repositório do projeto e uma cópia de trabalho a Criação do repositório é feita através do comando svn admin Create que recebe o caminho do diretório de destino como parâmetro criar repositórios não é uma operação frequente geralmente o repositório já existe no servidor e você precisa apenas criar

a sua cópia de trabalho mas para você poder repetir a demonstração sem complicações vamos usar esse repositório local mesmo a criação da cópia de trabalho é feita com o comando sbn checkout você precisa passar A URL do repositório e o caminho de destino do diretório de trabalho a primeira vista o diretório criado parece vazio mas existe um subdiretório pon svn oculto que é mantido pelo subversion para guardar várias informações administrativas comando svn info mostra as informações contidas no ponto svn tais como a localização do repositório a revisão de cada arquivo e subdiretório do diretório de

trabalho e um time ST com a última atualização do repositório O subversion usa essas informações para executar várias operações por isso o diretório p sbn não deve ser alterado manualmente porque pode corromper sua cópia de trabalho para continuar com a demonstração a gente precisa saber que subversion usa uma convenção de diretórios para organizar variações de projeto a raiz do projeto no repositório deve ter três diretórios Trunk brands e tags o diretório Trunk é o ramo principal os Subdiretórios dentro de brands serão os Ramos secundários e os subdiretórios de tags representarão etiquetas essa figura mostra como

fica a estrutura típica de diretórios de um repositório do subversion para projeto mais adiantado Não se preocupe porque veremos tudo isso em detalhes mais paraa frente o importante por enquanto é criar essa estrutura inicial do projeto para isso vamos usar o comando Svn make dear que cria e adiciona diretórios a configuração de uma vez o próximo passo é consolidar para salvar essa alteração no repositório Vamos então ao nosso primeiro comit a cópia de trabalho atual está na raiz do projeto mas o ideal é que fosse apenas do ramo em que a gente estiver trabando para

evitar meer no ramo errado por engano ou acidente como nós vamos trabalhar no ramo principal que é o Trunk essa cópia de trabalho não serve Mais então eu apagar essa e fazer um novo checkout com uma url um pouco diferente que tem Trunk no final do caminho o próximo passo é criar alguns arquivos V criar quatro arquivos iniciais Esses são arquivos texto mas poderiam ser arquivos binários o subv lida bem com ambas um último conceito teórico antes de voltarmos pra demonstração a situação do diretório de trabalho é informado pelo comando svn Status os estados possíveis

são indicados por letras no terminal e por ícones de estados na interface gráfica os estados mais comuns são normal modificado adicionado não rastreado ignorado removido aparecido em conflito read only e travado o estado desaparecido indica que um arquivo ou diretório rastreado Foi removido ou renomeado pelo sistema Operacional e não pelo controle de versão os estados em conflito read only e travado vão aparecer mais para frente quando falarmos de travamento e mesclagem vamos então retomar a demonstração sem mais interrupções o svn status informa que arquivos não rados no diretório de trabalho marcados Com caractere interrogação para

adicionar os arquivos não rastreados à configuração usamos o comando svn AD você pode especificar Quais arquivos a serem adicionados como parâmetro ou adicionar todos os arquivos não rastreados de uma vez usando asterisco como a gente viu no vídeo sobre como funciona o controle de versão o ideal é consolidar Apenas quando a configuração estiver estvel Isto é passando na compilação e testes além disso a mensagem de log deve referenciar um ticket no controle de mudança do projeto nesse exemplo como não estamos trabalhando com projeto real nem H um Controle de mudança do projeto vamos passar direto

PR consolidação e usar uma menagem de log parci com padrão recomendado resolve # inclus do prim ariv doet a Edi de ariv feita por qualqu programa que você quiser o subversion detecta automaticamente a mudança no conteúdo de um arquivo a edição do arquivo funk PP por exemplo leva seu estado para modificado as diferenças entre a configuração do Diretório de trabalho e a revisão anterior são apresentadas pelo comando svn dif no formato dif Unificado vamos consolidar e gerar mais uma revisão a próxima operação é de remover um arquivo isso é feito pelo comando svn RM ou

svn Dell que é um apelido para o mesmo comando um arquivo incluído é imediatamente removido do diretório de trabalho seu estado passa para d e deixa de ser rastreado a partir da próxima Consolidação Porém isso não significa que seu histórico será pagado o arquivo Continua existindo nas revisões anteriores e pode ser analisado ou recuperado Se necessário as próximas operações são cópia e renomeação a cópia é feita pelo comando svn copy ou svn CP para usar o estilo Linux renomear e mover são mesmo comando são executados pelo comando svn rename ou svn MV para encurtar a

renomeação é Como a cópia só que apaga o arquivo de origem e o commit para salvar essa configuração em uma revisão pela linha de comando o histórico do projeto é obtido pelo comando svn log o histórico não apareceu todo Porque apesar dos commits a cópia de trabalho continua na revisão um a gente precisa fazer um svn update para atualizar cópia de trabal E aí o histórico fica disponív sãoas do subversion e ficamos por aqui na próxima aula vamos ver a dem pelo tortu svn até [Música] mais pess nessa aula vamos a demonstração pelo tortu svn

primeiro vamos criar o repositório a partir de uma nova pasta no menu de contexto escolha a opção tortu svn criar repositório aqui clique no botão para criar a estrutura de diretórios isso vai economizar alguns passos você pode confirmar que a estrutura está criada pelo reco Browser Quando a gente for criar a cópia de trabalho já é a partir do tronk além do caminho de destino há várias outras opções a recomendação ao se trabalhar com uma interface gráfica de qualquer controle de versão é não sabe e não mexa isso quer dizer que se você não sabe

Para que serve determinada opção da interface não marque nem desmarque nem modifique mexa apenas no que você tem certeza Para que serve vou acelerar para a criação dos Arquivos iniciais do projeto são os mesmos que vimos na execução pelo terminal a opção tortu svn check for modifications é equivalente ao sbn Status da linha de comando mas a janela que abre permite executar algumas operações tal como a adição dos arquivos não rastreados A configuração outra forma de adicionar os arquivos é selecionando e depois pelo menu de contexto escolhendo a opção Tortu svn AD com a primeira

configuração pronta vamos ao com e geramos a revisão dois a próxima ação é editar o arquivo funk ppy para consertar a função Max a edição do arquivo funk. pi pode ser feito por qualquer programa desejado o totas svn identifica que o arquivo foi modificado para ver as mudanças você pode selecionar o arquivo modificado e depois acionar no menu de contexto e Escolher a opção tortu svn dif isso abre a ferramenta de visualização de diferenças do tortu svn outra forma de ver as diferenças é a partir do tortu svn check for modifications selecione o arquivo modificado

e Escolhe a opção de comparar com o base ou ver as diferenças e vamos consolidar essa configuração a remoção de um arquivo deve ser feita pelo menu de contexto toas svn delete na interface gráfica é Muito comum você esquecer e fazer isso pelo sistema operacional se isso acontecer o arquivo passa para o estado desaparecido e não removido vamos tratar como resolver essas situações em uma outra aula por agora vamos apenas consolidar e continuar o exemplo a renomeação pelo tortu svn é feita pelo menu de contexto tortu svn rename mas outra opção é arrastar e soltar

usando o botão secundário do Mouse não é uma ação muito comum no Windows mas isso abre um menu de contexto que perm permite você escolher a opção svn move que é equivalente ao rename como vimos pela linha de comando você deve escolher uma das opções que começ com svn as que aparecem na parte de baixo do menu são do sistema operacional para copiar um arquivo rastreado pel tortu svn o procedimento é o mesmo arraste e solte com botão secundário do mouse e escolha a opção Apropriada que começa com svn para ver o estado da cópia

de trabalho Vamos abrir mais uma vez o tortu svn check por modifications e a última consolidação para ver o histórico do Trunk Clique na área de trabalho com botão secundário e escolha a opção tortu svn show log se você escolher essa opção a partir de um arquivo verá apenas o histórico desse arquivo e não do ramo principal a janela que se abre Mostra Todas as informações do histórico tais como revisões mensagens de consolidação e mudanças realizadas e assim terminamos a primeira aula de comandos básicos do subversion na próxima aula veremos como filtrar arquivos de projetos

a serem ignorados usando mais conceitos e operações básicas do subversion até mais [Música] Olá pessoal nessa aula veremos Porque alguns tipos de arquivos devem ser Ignorados pelo controle de versão provavelmente todos os arquivos presentes no diretório de trabalho são importantes para o funcionamento do projeto porém nem todos precisam ou devem ser registrados no controle de versão são eles arquivos secundários configurações particulares banco de dados aplicativo e utilitários submódulos de terceiros arquivos secundários são arquivos gerados automaticamente durante o Processo de desenvolvimento a partir do código fonte e de outros arquivos primários do projeto por exemplo arquivos

executáveis intermediários como ponto EZ pbj etc outros arquivos secundários tais como pon PDF ponto ISO log Zip etc arquivos secundários não devem ser incluídos no controle de versão porque podem ser gerados novamente sempre que necessário a a partir dos arquivos primários do projeto que são Versionados arquivos com configurações de preferências pessoais não devem ser rastreados porque a configuração que serve para uma pessoa certamente Não servirá para outra quando compartilhados esses arquivos trazem problema no trabalho em equipe os casos mais comuns são de arquivos de configuração auxiliares de um ide ou de um editor de texto

arquivos com extensões P Project pcfg etc contém informações específicas De preferências e os caminhos de diretório etc que só servem para uma pessoa o mesmo vale para arquivos com informações sigilosas tais como senhas de acesso que além de serem particulares Podem trazer problemas de segurança a dica é use variáveis de ambiente para generalizar configurações o nome das variáveis de ambiente são comuns a todos e ficam no controle de versão mas os valores são específicos e ficam em cada Computador banco de dados o banco de dados não deve ser versionado porque os arquivos são grandes e

binários Isso significa que ocupam muito espaço e não podem ser combinados com os arquivos de bancos de dados feitos por outras pessoas não dá por exemplo para combinar diretamente os arquivos de banco de dados de dois casos de teste para formar um único banco de dados o que deve ser versionado são os scripts de criação migração e população Do banco de dados a partir desses scripts o banco de dados pode ser reconstruído sempre que aplicativos e utilitários não ponha compiladores nem editores ou outros tipos de ferramentas no cont de versão Quando forem necessários novamente podem

obos P interet de uma mdia de instação o que rastreado éa versões do softwares usad novim submódulos de terceiros é bastante comum um projeto depender de outros Projetos bibliotecas ou frameworks não se deve incluir diretamente o código desses outros projetos porque o seu projeto usa e Depende mas não contém nem possui os outros projetos outra maneira não recomendada é o uso de subprojetos várias ferramentas de controle de versão permitem alguma solução assim inclusive o subversion Git e o Mercurial o problema dessas soluções é que elas são complicadas de usar e manter cercadas de Peculiaridades a

melhor alternativa para liar com submódulos de terceiros é usar algun gerenciador de pacotes Python tem o PIP env nodejs tem o npm Ruby tem o Ruby James e por aí gerades dees paraci software de ter pores tipos de arem ignos Prime lugra e vees impem integração do trabalho em equipe devido a mesagens desnecessárias e conflitos inconciliáveis é um desperdício de tempo e esforço que Pode ser evitado vamos falar mais sobre mesclagem e conflitos em um próximo capítulo em segundo lugar esses arquivos ocupam muito espaço no repositório isso sobrecarrega o backup do Servidor que fica muito

maior e também operações de clonagem e sincronização de repositórios que ficam mais demoradas você deve versionar apenas os arquivos primários do projeto se você quiser manter uma cópia de segurança de outros tipos de arquivos escolha um Outro lugar apropriado que não seja o controle de versão lembre-se controle de versão não é ferramenta de backup agora a gente sabe os tipos de arquivos que não devem ser estreados mas como fazer isso todo controle de versão possui algum tipo de lista de padrões para filtrar arquivos a serem ignorados essa lista deve ser adicionada a configuração para que

os padrões de filtro sejam compartilhados por toda a equipe a sintaxe da lista de filtros não Costuma variar muito linhas em Branco São ignoradas e as linhas que começam com hashtag são consideradas comentários cada filtro é definido em uma linha e um filtro pode ser declarado no formato glob ou através de expressões regulares se o caminho de um arquivo corresponder a algum padrão na lista então o arquivo é ignorado mas isso só vale para arquivos não rastreados arquivos rastreados já fazem parte da configuração e não são Afetados outra coisa um comando direto do controle de

versão adiciona um arquivo não rastreado a configuração mesmo se esse arquivo fizer parte da lista de ignorados aí estão alguns exemplos equivalentes de padrões englobe e expressões regulares junto com exemplos de caminhos que são ignorados por esses filtros uma última dica crie a lista de padrões de filtros de arquivos ignorados o mais cedo possível no projeto quanto Antes assegurar que ninguém Adicione um arquivo desnecessário por accidente melhor e ficamos por aqui na próxima aula aul vamos ver como fazer isso diretamente no controle de versão até [Música] lá Olá pessoal essa é a nossa segunda aula

prática de operação do subversion na qual veremos como ignorar certos arquivos do diretório de trabalho na aula anterior nós vimos Porque alguns arquivos do projeto não Devem ser ignorados pelo controle de versão como foi dito antes todo controle de versão possui algum tipo de lista com padrões para filtrar arquivos a serem ignorados no subversion essa lista é guardada em uma propriedade pra gente entender como isso funciona primeiro a gente precisa entender o que são propriedades no subversion e para que elas servem propriedades são metadados que servem para guardar informações Adicionais sobre arquivos diretórios e revisões

essas propriedades quando associadas a arquivos de diretório são versionadas o que significa que podem ser modificada revertidas e consolidadas embora seja possível criar propriedades particulares é mais comum usar as propriedades reservadas do subversion cujos nomes seguem o padrão svn do P nome da propriedade por exemplo a propriedade svn 2 executable é Configurada pelo subversion nos casos em que o arquivo possui o bit de permissão de executável em Sistemas Linux outra propriedade reservada associada a arquivos é svn 2 m type que indica o tipo do arquivo isto permite um tratamento diferenciado Em certas situações tais como

mesclagem e visualização arquivos texto não tem nenhum mtype associado mas os arquivos binários são automaticamente Marcados pelo subversion como mtype application Bar octet stream assim o subversion sabe que não adianta fazer mesclagem nem dif para esses arquivos vamos ver algumas outras propriedades interessantes ess BN EOL Style define o tipo de quebra de linha de arquivos texto os valores possíveis são Native crlf que é usado pelo Windows ou LF que é usado no Linux é necessário definir essa propriedade nos casos em que o projeto é desenvolvido em sistemas operacionais diferentes Windows Linux Mac OS svn merge

info é usado pelo subversion para registrar intervalos de mesclagem já usados vamos falar mais desse assunto na aula de variações de projeto svn needs loock torna arquivo read only na cópia de trabalho para indicar que precisa ser travado paraa edição vamos usar bastante essa propriedade na aula sobre travamento svn Global ignores contém uma lista de filtros de arquivos não rastreados a Serem ignorados por comandos tais como svn status e svn ad é uma propriedade que deve ser associada a um diretório os filtros definidos em svn Global ignores usam um formato glob e valem recursivamente para

todos os subdiretórios por isso é bom definir essa propriedade na raiz da cópia de trabalho quer dizer no Trunk para que ALC todos os subdiretórios do projeto o subversion possui uma outra propriedade parci chamada svn Ignore mas só vale Para diretório em que foi definida então é melhor usar o svn Global ignores a próxima propriedade é svn auts contm uma lista de padrões de nomes de arquivos e as propriedades e Valores que devem ser aplicados automaticamente a esses arquivos veja esse exemplo todos os arquivos P sh adicionados terão a propriedade svn executable configurada para asterisco

todos os arquivos P HTML terão a propriedade svn EOL Style definida para Native e todos os arquivos Com extensão pon jpg terão uma propriedade svn nits loock definida para asterisco e o svn m Type definido para image JPEG svn autoprop também é associado a um diretório e também vale para todos os subdiretórios abaixo da da mesma forma que o svn global ignores é bom que seja aplicada na raiz da cópia de trabalho vamos ver tudo isso funcionando em uma demonstração antes de começar é Importante saber que pelo terminal os comandos do subversion para manipular propriedades

são svn props para definir uma propriedade svn prop list para listar todas as propriedades de um arquivo diretório svn propg para imprimir o valor de uma propriedade svn proped para excluir uma propriedade e svn prop Edit para editar uma propriedade através de um editor externo e agora sim vamos à demonstração vou criar um novo repositório chamado Projeto 2 dentro de um diretório reservado para repositórios em seguida vou criar a estrutura Inicial padrão com Trunk brands e tags isso pode ser feito diretamente pelo comando svn M dear sem passar para uma cópia de trabalho mas isso

gera uma nova revisão e portanto é necessário passar uma mensagem de consolidação em seguida a criação da cópia de trabalho para Trunk que é o ramo principal do subversion e agora vou Criar a estrutura de diretórios e alguns arquivos vazios Vou definir a propriedade svn aprs para raiz da cópia de trabalho que no caso é o próprio diretório projeto 2 o svn status mostra um M na ra do diretório de trabalho resultado da alteração da propriedade os demais arquivos e diretórios aparecem como não rastreados vou definir a propriedade svn Global ignoras também na raiz da

cópia de Trabalho para mostrar a lista de arquivos incluindo os arquivos não ignorados use svn status com opção menos menos no Ignore parece tudo certo vou adicionar todos os arquivos então com o comando svn AD asterisco opa não é era o resultado que eu esperava Afinal os filtros são justamente para evitar isso o problema é que o best expande o asterisco incluindo todos os nomes de arquivos e diretórios Mesmos filtrados por isso adiciona todo mundo para consertar a situação vamos desfazer a adição através do comando svn revert - R asterisco para adicionar apenas os arquivos

e diretórios não rastreados de interesse a gente deve usar svn AD menos menos Force ponto esse ponto giratório corrente que já é rastreado por isso é preciso usar o menos menos Force para forçar a adição dele novamente essa adição percorre todos os arquivos e Subdiretórios respeitando os filtros o svn status Não ignore mostra que agora sim está como esperado antes de consolidar vamos ver algumas propriedades usando o comando svn prop list a opção menos V é para também mostrar os valores além das propriedades as dados do arquivo fundo.jpg foram definidas como especificado no svn Auto

props e o arquivo ridm TXT não tem nenhuma propriedade Associada para finalizar a consolidação e ficamos por aqui na próxima aula vamos refazer a demonstração pelo tortu svn até lá [Música] [Música] Olá pessoal nessa aula vamos refazer a demonstração de como trabalhar com propriedades do subversion ignorar arquivos pelo tortu svn no explorador de arquivos vou até a pasta documentos eu já havia criado uma pasta repositórios Antes vou criar uma nova pasta para o repositório do projeto Dois e depois criar o repositório nessa pasta já com a estrutura Trunk Brains e tags o próximo passo é

criar a cópia de trabalho para isso volto a pasta documentos e executo tortu svn svn checkout Note que o checkout é do Trunk conforme mostro final da URL próximo passo é criar a estrutura de diretórios e os arquivos vazios do exemplo vou fazer isso pelo best do Bunto porque é mais rápido do que pela interface gráfica voltando ao explorador de arquivos na pasta da cópia de trabalho todos os arquivos e pastas já estão lá agora Vou definir a propriedade svn Auto props na raiz da cópia de trabalho Note que eu vou clicar naar em branco

para fazer isso E aí escolho a opção tortu asas VN propriedades na janela que se abre escolha o Nil para definir uma nova Propriedade mas não é nenhuma dessa lista Aí essa outra lista é mais completa basta escolher svn Auto props e digitar os valores na caixa de texto correspondente eu digitei uma declaração errada escrevi svn do. EOL mas deveria ser svn do. EOL trç Style vou deixar assim corrigir mais tarde um segundo comit depois eu faço o mesmo processo para definir svn Global ignores também é Na raiz da cópia de trabalho os ícones de

estado nem sempre funcionam direito no Windows não é problema do tortu svn isso Bom agora eu vou adicionar todos os arquivos ao invés de selecionar todos com o mouse o que equivaleria a um svn asterisco e traria os mesmos problemas que vimos na demonstração pelo terminal basta clicar na áa em branco com o botão secundário do mouse e escolher tortu svn AD a lista que aparece são só dos arquivos que Realmente devem ser adicionados a configuração rastreada o ícone tá mostrando o estado modificado mas deveria ser adicionado a mais confiável de estado da cópia de

trabalho é o tas svn check for modifications use sempre essa opção a coluna property status indica se houve mudança na propriedade para ver o valor da propriedade US o botão secundário do mouse sobre o item escolho propriedades tudo pronto vamos Consolidar e agora vou aproveitar e corrigir as propriedades que ficaram erradas no Trunk e no arquivo template HTML para corrigir o svn auto props selecion o área em branco da raiz da cópia de trabalho e depois tortu svn propriedades seleciona a propriedade depois editar E é só consertar o valor corrigir o svn props não corrige

as propriedades do template P HTML automaticamente é necessário fazer um Procedimento parecido toas svn propriedades mas ao invés de editar é necessário remover a propriedade de nome errado e criar outra propriedade com o nome certo você pode ver as alterações pelo tortu svn check for modifications e depois consolidar e finalizamos a demonstração pelo tasias VN com isso nós ficamos por aqui na próxima aula Vamos mostrar como desfazer alterações e pendências no diretório de Trabalho até [Música] lá Olá pessoal essa Nossa terceira aula prática de operação básica do subversion nas aulas anteriores nós vimos o funcionamento

de alguns comandos básicos relacionados ao diretório de trabalho e ao repositório e também aprendemos por e como ignorar alguns arquivos do diretório de trabalho nessa aula veremos como desfazer alterações há dois tipos possíveis de Reversão subversion o primeiro tipo é antes de consolidar Isto é enquanto as alterações ainda estão no diretório de trabalho para desfazer as alteraç basta reverter as operações pendentes no segundo tipo as alterações já foram consolidadas e compartilhadas com outras pessoas como você não tem mais controle sobre a configuração a solução é criar uma nova revisão que anule o efeito do Change

set a ser corrigido nessa aula vamos tratar da Reversão do primeiro tipo e algumas reversões do segundo tipo operações mais avançadas de anulação de chend set envolvem mesclagem e por isso serão vistos mais pro fim do curso os tópicos que veremos na aula são desfazendo operações não consolidadas resolvendo pendências no diretório de trabalho revertendo e ressuscitando arquivos vamos ver como fazer iseto nação primeiroo teral e depois pela interface gráfica demonstração pelo Terminal comear um novo repositório de nome revertendo alterações eog em seguida vou criar arquivos para usar depois para não perder muito tempo vou acelerar

esse processo na segunda fase vou realizar algumas operações para serem revertidas antes da consolidação editar a propriedade svn global ignores de Trunk excluir requirements.txt pelo sistema operacional excluir o arquivo license pelo Subversion adicionar o arquivo test.log renomear readme.rst para readmi.md copiar o arquivo base. html no diretório template para m. HTML o estado da cópia de trabalho é esse aí para reverter uma operação deve-se usar o comando svn revert posso especificar cada arquivo a rever ao estado da última revisão ou reverter todo mundo de uma vez com o comando svn revert - r maiúsculo ponto tudo

volta ao Estado Inicial e vamos pra próxima fase Como já foi dito antes com exceção da criação e edição as demais operações sobre arquivos da área de trabalho devem ser feitas pelo controle de versão mas vez ou outra a gente esquece e acaba copiando renomeando ou removendo um arquivo direto pelo sistema operacional Então vamos supor que eu tenha feito isso e o estado da cópia de trabalho ficou assim com arquivos desaparecidos marcados com exclamação e arquivos não Rastreados será que dá para consertar essas ações infelizmente não pelo menos pela linha de comando vai ser preciso

desfazer as operações pelo sistema operacional e refazer pelo subversion só as exclusões podem ser consertadas direto pelo comando USB nrm depois de consertado é só fazer o comit para salvar a configuração no repositório nessa próxima etapa vou fazer umas alterações que serão desfeitas depois de consolidadas o Arquivo requirements ptst vai ser removido e a licença vai mudar de MIT para BSD Imagine que passou um tempo e outras revisões e eu acabei de descobrir que não devia ter apagado nem mudado esses arquivos Então eu preciso ressuscitar o arquivo e voltar à licença antiga o que preciso

fazer é descobrir a revisão em que o arquivo license foi alterado e em que o arquivo requirements P XT Foi removido isso será feito Pesquisando no log mas lembrando aquela peculiaridade do subversion é necessário fazer um svn update para poder acessar o histórico mais recente do projeto Primeiro vou voltar a licença para a versão anterior para ver o histórico do arquivo license Uso o comando svn log license a última alteração foi na revisão 4 então vou obter o conteúdo de license em uma revisão anterior pode ser a revisão dois mas a revisão 3 também serve

porque o Arquivo license na revisão 3 é igual ao arquivo license da revisão 2 o comando svn Cat mostra o conteúdo de um arquivo svn Cat Men R3 license mostra o conteúdo do arquivo license na revisão 3 out mod de especificar o arivo é passando seu endereço no repositório que é composto pelo caminho e pela revisão combinados ou usando o caminho relativo para não ter que especificar parte inicial da URL direcionando a saída para o próprio Arquivo então eu volto o conteúdo de license para revisão 3 e falta ressuscitar o arquivo requirements.txt o comando svn

log requirements.txt não funciona como esperado porque o arquivo não existe na cópia de trabalho então A análise do histórico terá de ser feita indiretamente vou analisar o histórico detalhado e procurar pela linha que indique a exclusão do arquivo requirements pxt essa linha deve começar Com D e conter o nome do arquivo para isso eu vou combinar a saída do comando svn log com opção menos V mins em que V minúsculo é para mostrar os caminhos alterados com comando grap para pesquisar padrões no Tex a op menos bsc most lin contexto linha en E aí égo

most falos positivos se eu melor aão regularão de Bus usando esse padrão Aí volta só a revisão de interesse mostrando que o arquivo Foi removido na revisão 4 Isso quer dizer que ele ainda existia na revisão 3 a ideia então é copiar o arquivo da revisão onde ele ainda existia de volta para cópia de trabalho para ele voltar a ser rastreado dá para fazer isso com comando svn Cat Mas esse requirements.txt não tem relação com o anterior vou desfazer essa ação para mostrar outra solução um jeito melhor é usando comando svnp esse arquivo requir que

é criado continua o histó do arivo queha Sid Removido anteriormente essa operção para ritar é meio desajeitado P linha de comando P interface grfica bem mais fác você vai ver terminamos P linha deando e ficamos por aqui na próxima aula vamos refazer a demonstração pelo tortu svn até lá [Música] Olá pessoal nessa aula vamos refazer a demonstração de reversão de alterações pelo tortu svn primeiro vou começar um novo Repositório de nome revertendo alterações dentro da pasta repositórios o Toto svn já cria a estrutura de diretórios para mim em seguida checkout e a criação dos arquivos

iniciais da demonstração vou usar o terminal para criação dos arquivos para ser mais rápido falta só definir a propriedade svn Global ignores nessa configuração Inicial e depois consolidar na segunda fase vou realizar algumas Operações para serem revertidas antes da consolidação editar a propriedade svn Global ignor Trunk excluir requirements.txt pelo sistema operacional excluir o arquivo license pelo subversion adicionar o arquivo test.log renomear readme.rst para readm.md copiar o arquivo base. HTML para m. HTML para ver o estado usa o comando tortu asias VN check for modifications para reverter escolho um Arquivo e depois clico com o botão

secundário do mouse e depois na opção reverter ou undo L se tiver sido uma adição para reverter todas as alterações de uma vez seleciono todas as linhas e novamente clico com o botão secundário do mouse e escolho revert os arquivos que Ficaram para trás foram criados pela cópia e renomeação podem ser apagados e voltou tudo ao estado Inicial vamos paraa próxima fase agora eu vou Fazer algumas modificações pelo sistema operacional e consertar depois pelo tortu svn vou copiar template.bom para template bar m.ml renomear números P TXT para números primos P TXT e remover a sdf

TXT o estado da cópia de trabalho é esse para confirmar a exclusão do arquivo sdf TXT basta excluir ele novamente para consertar a renomeação Eu escolho os dois arquivos envolvidos e depois Escolho repair Move para consertar a cópia eu também tenho que escolher os dois arquivos ouvidos mas um deles não aparece porque não foi modificado Mas eu posso alterar isso marcando a caixa unmodified aí eu escolho os dois e depois executo repair copy e agora não preciso mais exibir os arquivos não modificados tudo certo só consolidar essa reversão é muito mais Fácil para interface gráfica

e a próxima também mas antes vou fazer as modificações e consolidar para depois serem desfeitas vou remover requirements pxt e alterar a licença para reverter o arquivo license eu Primeiro vou analisar o seu histórico escolha a revisão que quero desfazer e depois executo revert Chang from this revision para ressuscitar o arquivo requerimentos pxt eu vou pesquisar no histórico a Revisão que ele foi removido e depois reverter as mudanças dessa revisão e para finalizar só falta o commit e terminamos a demonstração pelo tortu [Música] svn Olá nessa aula veremos as diferenças entre controle de versão Centralizado

e distribuído o subversion é um exemplo de controle de versão Centralizado enquanto o Git e o Mercurio são exemplos de distribuídos Mas quais as diferenças Existe um tipo mhor que o outro antes de continuar é important um esclarecimento tanto modelo Centralizado quanto distribuído oferecem todos os serviços fundamentais de Cont de versão que são registro da evolução do projeto controle de concorrência e variações de projeto tanto subversion quanto Git e o mercúrio possuem suas particularidades na implementação de um ou outro serviço mas algumas diferenças são inerentes ao modelo usado as diferenças são três Número de repositórios

numeração de revisões e mecanismos de controle de concorrência vamos ver as duas primeiras diferenças agora mas o controle de concorrência ficará para outra aula Primeiro as diferenças em relação ao número de repositórios no controle de versão Centralizado um único repositório Central serve a vários diretórios de trabalho formando uma topologia cliente servidor o repositório fica um servidor próprio e os diretórios de trabalho nas Máquinas de cada desenvolvedor não há comunicação direta entre diretórios de trabalho a sincronização é feita através de operações commit update enviadas ao repositório Central o controle de versão Centralizado existe há décadas e

funciona muito bem para projetos em que as equipes têm até algumas dezenas de desenvolvedores o acesso ao servidor é rápido geralmente por rede local todos têm permissão de leitura escrita no Repositório desse modo o tempo de resposta do Servidor é adequado e todos conseguem participar do projeto os problemas aparecem quando alguma dessas condições muda quando o número de desenvolvedores passa do limite da capacidade de atendimento do Servidor a sobrecarga no processamento do repositório Central torna o tempo de resposta cada vez mais insatisfatório outro problema acontece Se a equipe está distribuída geograficamente nesses casos é comum

haver limitações de conexão com d ou restrições nas permissões de leitura e escrita no repositório controle de versão distribuído surgiu Originalmente para atender exatamente esses casos em que o Centralizado não se sai tão bem ao invés de um único repositório Central há vários repositórios locais autônomos cada desenvolvedor tem seu próprio Repositório individual e cada repositório tem seu próprio diretório de trabalho acoplado a comunicação entre o diretório de trabalho e o repositório continua sendo feita pelas mesmas operações comit e update mas agora há um outro nível de comunicação entre o repositório local e o outro repositório

considerado remoto em que as principais operações são Clone push e pull Clone cria o repositório local e seu diretório de trabalho a partir de um repositório Remoto push significa empurrar essa operação envia as revisões do repositório local para um repositório remoto P significa puxar essa operação traz as revisões de um repositório remoto para o repositório local Tecnicamente um repositório autônomo pode se comunicar livremente com qualquer outro repositório formando a topologia peer topeer Porém esse arranjo não é usado Porque sem uma hierarquia definida de repositórios o Fluxo de trabalho é caótico a topologia cliente servidor continua

sendo a mais usada o repositório Central tem um papel de repositório oficial do projeto e os repositórios individ não se comunicam diretamente a sincronização é feita apenas através de operações push e pull com o repositório oficial no controle de versão distribuído a topologia cliente servidor não tem problema com o número de desenvolvedores porque o processamento é Distribuído entre os repositórios individuais e o tráfico pela rede é reduzido às operações de sincronização entre repositórios porém a questão do acesso externo ainda permanece já que todos os desenvolvedores ainda precisam ter permissão de p no repositório oficial Isso

é um problema principalmente para projetos open source pois a participação externa é necessária e bem-vinda mas colaboradores externos não têm permissão de pus no repositório Oficial do projeto para lidar com essa situação é melhor usar a topologia baseada em fork com requisições de Pool nessa topologia a comunicação entre colaboradores internos e externos é feita através de repositórios públicos e operações de p funciona assim o colab exitado oitões eit aõ Request OB request não é dole de versão poderia feito atra de um e-mail que você Enia para alguém um recado que você Dea no chat ou

algo assim plataformas de hospedagem como github bitbucket gitlab World code etc é que oferecem essa funcionalidade de um jeito mais amigável e automatizado voltando então o colaborador interno com papel de integrador faz um p do repositório Público do fork em seu repositório individual Analisa as modificações e se aprovadas as envia ao repositório oficial Então esse padrão permite que desenvolvedores externos contribu para o projeto meso mes sem permissão descrita no repositório oficial e ficamos por aqui na próxima aula veremos a diferença na numeração de revisões entre controle de versão Centralizado e o distribuído e também veremos

um resumo com os tópicos Principais até [Música] lá olá vamos continuar a aula sobre as diferenças entre o controle de versão centr AD e o distribuído na aula anterior falamos sobre o número de repositórios e as topologias associadas o próximo tópico é a diferença no esquema de numeração de revisões no Centralizado o repositório único atribui um número sequencial a cada nova revisão o histórico é linear e o número Da revisão indica sua posição histórico considerando inteiro de 64 bits o número de revisões que pode ser registrado em um controle de versão Centralizado é esse aí

é mais que suficiente para qualquer projeto mas para você ter uma ideia melhor do tamanho vamos contextualizar esse número a chance de ganhar na mega cena é uma em 50 milhões o que está nessa posição então o número de combinações possíveis é muito maior que Isso no controle de versão distribuído não é possível usar uma numeração sequencial Global porque os repositórios são autônomos o número de revisão precisa ser universalmente único Isto é um número que não se repetirá em nenhuma outra revisão independente do repositório onde foi gerado geralmente esse número é produzido através de uma

função hash sh1 os dados de entrada são informações da revisão tais como data autor mensagem de Consolidação ch setet etc e a saída é um número de 160 bits que equivale a 40 dígitos em ex decimal o número é esse vamos contextualizar para ter uma ideia melhor bom a chance de ganhar na meena fica nessa posição e essa posição é a do número de combinações de um inteiro de 64 bits que vimos um controle de versão Centralizado os números de revisão baseado em hash são universalmente únicos porque revisões com atributos Diferentes produzem hashes diferentes a

chance de colisão em 160 bits é extremamente remota porque o número de combinações possíveis é astronômico aí estão três exemplos de números R é comum especificar só os 12 primeiros dígitos para facilitar a digitação como a numeração não é linear cada revisão tem um apontador pra revisão anterior para estabelecer a sequência no histórico o apontador pra revisão anterior também entra no cálculo Do hash para garantir que a posição no histórico influencie no número da revisão gerado no controle de versão distribuído o histórico de revisões forma um grafo acíclico direcionado em que cada revisão é um

nó e os apontadores para revisões anteriores são Arcos esse conceito será importante quando formos falar de ramificação de projetos antes de terminar a aula vamos ver um resumo da matéria o controle de versão Centralizado tem apenas um Repositório central e usa a topologia cliente servidor no Centralizado a revisão é sequencial controle de versão distribuído tem vários repositórios autônomos a topologia cliente servidor ainda é mais utilizada mas há outras topologias possíveis como a baseada em fork po no distribuído a numeração é baseada No resto dos atributos e no antecessor da revisão para gerar um identificador Único

as principais operações do controle de versão Centralizado são commit e update o controle de versão distribuído também possui comit update além de push pull e clone Clone cria o repositório local a partir de um repositório remoto o diretório de trabalho acoplado também é criado durante a clonagem com a revisão mais recente disponível push envia as novas revisões do repositório local para o Remoto enquanto Pool traz as novas revisões do repositório remoto para o local lembre-se que o repositório ser local ou remoto depende apenas do ponto de vista o seu repositório é o local e outro

repositório qualquer é o remoto principal vantagem no controle de versão Centralizado é sua simplicidade o modelo e os comandos são simples e fáceis de usar a desvantagem do controle de versão Centralizado é que o desempenho do Servidor central cai à Medida que o número de desenvolvedores aumenta para equipes pequenas e médias isso não chega a ser relevante as vantagens do controle de versão distribuído em relação ao Centralizado são várias é mais rápido porque o processamento é local e o tráfego em rede é reduzido o servidor do repositório oficial é mais simples e barato porque o

processamento é distribuído é mais confiável porque cada repositório individual funciona como uma Cópia de segurança já que contém uma réplica do histórico do projeto é mais autônomo porque o trabalho individual pode continuar no repositório local mesmo sem acesso à rede ou ao repositório oficial no distribuído a principal desvantagem é a complexidade h um nível adicional de comunicação vários comandos que vão além do push p e clone h mais topologias padrões de ramificação etc O resultado é que para usar o controle de Versão distribuído é necessário que toda a equipe esteja muito bem preparada e sempre

atenta aos detalhes do processo de controle de versão e ficamos por aqui na próxima aula faremos uma demonstração dessas topologias no controle de versão até lá [Música] Olá pessoal nessa aula vamos ver a topologia cliente servidor usada pelo subversion o objetivo é mostrar como a sincronização das cópias de trabalho Passa pelo repositório Central através das operações svn commit e svn update também veremos conceitos de configuração de um servidor nós vamos precisar de um servidor para disponibilizar um repositório Central de forma mais realista os repositórios do subversion poem ser acessados de diversas formas o método de

acesso determina o esquema da URL usado para acessar o repositório os esquemas e os métodos de acesso existentes para o subversion São file Indica acesso local direto ao repositório foi o método que usamos nas demonstrações anteriores mas não funciona como servidor porque não tem controle de autenticação nem nenhum outro tipo de segurança Só serve para uso pessoal e em casos bem elementares o esquema http indica que o servidor é a parte do https é para parte do com SSL o apart 2 é bem completo como servidor possui várias opções de autenticação tipo ldap e Active

directory e permite Criptografia por SSL mas é o mais difícil de configurar como só preciso de algo simples para demonstração vou usar o próximo método baseado num servidor embutido do subversion que se chama svn serve o o esquema para o svn serve é svn roda sob tcpip mas sem criptografia mas se combinado com SSH então adiciona criptografia conexão via rede antes de continuar quero ressaltar o seguinte a única coisa que realmente muda de um tipo de servidor para outro é O esquema da URL usado em operações de checkout por exemplo não há nenhuma outra influência

nas operações de subversion dito isso a configuração do servidor não é absolutamente necessária paraa demonstração Mas é bom ter pelo menos uma ideia de como isso é feito então vamos ver como disponibilizar repositórios através do usbn server no Linux o diretório recomendado para dados a ser servidos é o bar SRV então para colocar os repositórios Subversion vamos usar o subdiretório bar SRV bar svn o comando svn server - D - rsrv bar svn faz o svn server rodar como demmon servindo repositórios localizados a partir do diretório bar SRV bar svn os arquivos de configuração do

svn server ficam dentro de cada repositório no diretório conf quando um repositório é criado esse diretório e alguns arquivos também são criados automaticamente com exemplos de Configuração o arquivo outz define permissões de acesso a caminhos dentro do projeto o arquivo Hook STR contém definições de variáveis de ambiente para scripts de Hook o arquivo passwd mostra como definir usuários e senhas e o arquivo svn.com contém as definições gerais do svn para o repositório corrente é esse arquivo em anterior que vamos precisar mexer para essa demonstração focando então na demonstração a demonstração usará três Desenvolvedores rut fulano

e beltrano rut é o administrador e vai configurar o repositório e o servidor fulano e beltrano serão os desenvolvedores que trabalharão em paralelo mas não de modo concorrente por enquanto isso significa que cada desenvolvedor vai trabalhar independentemente em sua própria cópia de trabalho mas as ações serão intercaladas ao simultâneas nós veremos concorrência a partir da próxima aula a sequência de Eventos será a seguinte primeiro R cria e configura o repositório e depois inicia o sbn server em seguida Fulano faz o checkout para criar a cópia de trabalho faz algumas inclusões E consolida aí é verz

de beltrano que também faz o checkout mais alterações e o comit depois é vez de fulano novamente que executa um svn update para sincronizar faz mais alterações e um comit para final e a última implementação de botran que Também executa um svn update faz alterações e finaliza com comit daí PR frente o padrão se repete svn update implementação svn commit Vamos ver isso em Ação a tela está dividid em três painéis e cada Pain é de uma pesso da demonstração o r vai comear criando diretório svn dentro de barra SRV em seguida vai criar o

repositório do projeto a que é o nome do projeto dessa demonstração e já aproveita para criar a estrutura de Diretórios com Trunk brins e tags como svn ser ainda não está no ar a URL desse comando usou esquema f a esse comando sed tira o comentário da linha do svn.com que indica Qual o arquivo com usuários e senhas que deve ser usado esse comando Eco inclui duas linhas no arquivo passwd com os usernames de fulano beano usando senhas 1 2 3 4 e para finalizar o r executa comando para p o svn server no ar

o papel do Rot termina aqui e vou fechar esse painel Porque não será mais necessário agora veja Fulano que executa sv checkout usando a URL com o esquema sbn em seguida criação de alguns arquivos números P TXT letras. TXT e requirements.txt adiciona esses arquivos ao projeto nada de novo aqui e a consolidação a novidade que o servidor Pede uma senha como parte do processo de autenticação além da senha é Mostrado um aviso perguntando se também deseja salvar a senha para não ter que ficar digitando toda vez vou escolher sim e o comit tá feito na

vez de beltrano vai acontecer algo bem parecido primeiro checkout Note que a cópia de trabalho já vem atualizada na última revisão depois uma alteração em números pxt com a adição do número quatro um svn dif para ver as diferenças e o comit como éu primeiro comite de beltrano subversion também pede a senha e a Confirmação para guardar a senha a próxima iteração é de fulano para sincronizar a cópia de trabalho ele executa o comando sven update a cópia de trabalho é atualizada com a última revisão Fulano faz outras alterações e consolida o subversion não pede

a senha novamente porque ela já foi gravada a iteração de beltrano Segue o mesmo padrão ven update alterações e commit ao final e daí por diante é sempre assim bom e ficamos por aqui na Próxima aula veremos como funciona o controle de concorrência até [Música] lá olá nessa aula vamos refazer a demonstração da topologia cliente servidor do subversion no Windows usando tortas svn para demonstrar a sincronização de duas cópias de trabalho Independentes através de um repositório Central na demonstração pela linha de comando Você viu a configuração dos Servidores svn server e a simulação de Dois

usuários trabalhando em paralelo o ideal seria fazer o mesmo no Windows mas existem algumas limitações da interface gráfica que impedem isso primeiro não iremos configurar um servidor de repositório no Windows Mas se você quiser tentar depois veja esse link para mais informações de como usar o svn server no Windows vamos apenas manter o repositório um ório local sem servidor mesmo do mesmo jeito que fizemos em demonstrações Anteriores em segundo lugar não vamos conseguir simular dois usuários diferentes ao mesmo tempo porque o Windows Explorer não pode ser iniciado com um usuário diferente que não seja o

administrador a solução para isso Será criar duas cópias de trabalho para simular os dois usuários diferentes não é o ideal porque no fundo o usuário ainda é o mesmo mas serve para demonstração porque as cópias de trabalho são independentes e só se Comunicarão através do Servidor Central Então vamos começar a demonstração primeira a criação do repositório local e da estrutura Inicial padrão com Trunk brands e tags em seguida vamos simular os dois usuários para isso vou criar os subdiretórios Fulano botran cada um terá sua própria cópia de trabalho criada através do toras svn svn checkout

Fulano faz o checkout primeiro e em seguida cria os arquivos números P TXT e Letras. TXT e adicion esses arquivos ao projeto nada de novo até aqui e a consolidação quando Beltran faz o checkout a cópia de trabalho já vem atualizada na última revisão com os arquivos criados por Fulano no Passo anterior depois uma alteração em números pxt Com Adição do número 4 e o comit a próxima iteração é de fulano antes de sincronizar a cópia de trabalho Com svnp datate vamos ver quais as alterações que viram por essa atualização para isso use o Toto

svn check for modifications e depois clique no botão check repository a coluna remote text status mostra que o arquivo foi modificado remotamente para ver quais são essas modificações você pode clicar duas vezes sobre o arquivo ou escolher a primeira opção no menu de contexto depois de examinar as alterações é hora de fazer a Atualização para valer a cópia de trabalho é atualizada com a última revisão Fulano faz outras alterações e consolida a interação de beltrano Segue o mesmo padrão tortu svn check for modifications check repository vias modificações svn update alterações e comit ao final e

daí por diante é sempre assim na próxima aula veremos Como funciona o controle de concorrência até [Música] Lá Olá pessoal vamos a mais uma aula sobre o funcionamento do controle de diversão o assunto agora é controle de concorrência e será dividido em três partes nessa primeira parte veremos o que é controle de concorrência e seu primeiro mecanismo de controle que é o travamento na segunda parte veremos outro mecanismo a mesclagem e na terceira parte Ramos individuais vamos começar Relembrando as três funcionalidades principais do Controle de versão registrar a evolução do projeto possibilitar o trabalho em

equipe Criar e manter variações do projeto o controle de concorrência é a parte do controle de versão que torna o trabalho em equipe possível vamos ver como isso funciona o trabalho em equipe acontece em paralelo com as pessoas alterando simult ente a configuração do projeto sem uma coordenação efetiva uma pessoa acaba sobrescrevendo o trabalho de Outra lembre-se que configuração é o estado do conjunto dos arquivos do projeto em um determinado momento revisão é a configuração registrada no repositório imagine duas pessoas editando o mesmo arquivo a uma produz a configuração a linha e a outra produz

a configuração a Du linhas a combinação correta da configuração a linha com a duas linhas produz a configuração a asterisco que contém todas as Modificações de a linha e de a duas linhas nada é perdido ou sobrescrito a ideia é simples mas a implementação nem tanto vamos ver um exemplo o estudo de caso usa um controle de versão Centralizado já com uma revisão a no repositório e dois diretórios de trabalho também posicionados com a configuração a João e Pedro fazem suas alterações e produzem a linha e a duas linhas em seus Respectivos diretórios de trabalho

João consolida primeiro e gera uma nova revisão à linha em seguida Pedro consolida e gera a revisão a duas linhas a falha acontece porque não houve a combinação de a linha e a duas linhas para gerar a asterisco como esperado Isso significa que se em a linha foi feita uma correção de defeito Por exemplo essa correção não está presente na revisão H duas linhas que é a mais recente esses casos em que um defeito Reaparece no projeto uma funcionalidade que já havia sido implementada some são clássicos da falha no controle de concorrência perceba que o

problema da concorrência não está na alteração dos arquivos porque isso é feito sobre cópias que ficam isoladas em diretórios de trabalho Independentes o problema está na disputa em consolidar e compartilhar as alterações no histórico para coordenar os esforços e garantir que sejam integrados é Necessário usar um mecanismo de controle de concorrência existem apenas dois tipos travamento e mesclagem vamos ver os dois tipos e a variação da mesclagem no controle de versão distribuído na forma de Ramos individuais travamento o travamento estabelece um acesso exclusivo descrito em um arquivo seja para alteração ou mesmo para exclusão um

arquivo travado continua acessível por outras pessas mas apenas Para leitura o travamento É um mecanismo típico do controle de versão Centralizado justamente porque precisa de uma autoridade única para lidar com o travamento e liberação de arquivos vamos refazer o estudo de caso da concorrência usando agora o travamento o ponto de partida é o mesmo revisão a no repositório central e nos diretórios de trabalho de João e Pedro João se antecipa e trava o arquivo a para poder editá-lo o travamento Registrado no repositório um lugar específico que não faz parte do histórico do projeto Pedro também

precisa editar o arquivo a mas quando tenta fazer o travamento recebe um erro indicando que o arquivo já está travado Pedro então precisa esperar João faz suas alterações que resultam na configuração a linha e a consolida no repositório perceba que a consolidação também libera automaticamente Travamento Pedro tenta travar o arquivo novamente mas dessa vez o erro é que o arquivo do seu diretório de trabalho está desatualizado é necessário então fazer o update e só então travamento é bem-sucedido como as alterações de Pedro são feitas sobre a linha a configuração resultante já é a asterisco que

contém tanto o chainset a linha quanto a duas linhas Esse é o resultado final desejado por fim Pedro consolida e o arquivo é Destravado automaticamente o ciclo de edição é trava edita consolida análise do travamento o travamento produz o resultado esperado mas o fluxo de trabalho costuma ser interrompido pela espera nas liberações do travamentos que podem demorar indefinidamente isso leva a atrasos outra situção queer é deadlock Imagine que João e Pedro precis editar os mesmos arquivos A e B mas João ariv a Pedro Ariv bamb ficando outa arivo Fes Limões mado para ariv bos vamos

ISO melhor depois de ver o próximo mecanismo de controle de concorrência a mesclagem que é o assunto da próxima aula até [Música] lá Olá pessoal Essa é a segunda parte da aula sobre controle de concorrência na aula anterior nós vimos que o controle de concorrência que torna possível Trabalhar em equipe vimos o primeiro mecanismo de controle de concorrência o travamento o travamento estabelece um acesso exclusivo descrito em um arquivo e assim evita que uma pessoa sobrescrevendo o travamento funciona mas atrapalha o fluxo de trabalho nessa segunda parte da aula veremos o próximo mecanismo de controle

de concorrência baseado em mesclagem a ideia por trás da mesclagem é que a Edição concorrente de um mesmo arquivo geralmente acontece em intervalos diferentes que podem ser combinados facilmente depois a sobreposição de alterações é um acontecimento raro quando ocorre forma um conflito os intervalos em conflito são Para que sejam resolvidos manualmente depois por exemplo seja H um arquivo texto com os números 1 ao 8 separados em linhas em a linh duas primeiras linhas Foram alteradas para seus valores por extenso em a duas linhas as alterações foram nas duas últimas linhas que puseram os números em

inglês como não há intervalos comuns o controle de versão consegue montar a asterisco automaticamente com essas alterações um aviso importante a existência de conflitos na mesclagem não garante que o código fonte continua funcionando quem verifica isso não é o controle de versão mas sim operações de Construção e teste que você deve fazer Obrigatoriamente antes de cada consolidação retomando o exemplo da mesclagem se as linhas quat e c forem alteradas tanto em a linha quanto em a duas linhas haverá conflito nesse intervalo mas não nos outros os casos de Ito requer intervenção manual as pessoas envolvidas

devem chegar a um acordo sobre a solução e usar ferramentas específicas como cadif 3 por Exemplo a interface para resolução de conflitos pode mudar um pouco de uma ferramenta para outra mas o padrão é sempre o mesmo há três seções A B e C em cima que mostram os estados do arquivo na configuração base local e order a sessão de baixo mostra como ficará o arquivo mesclado essas sessões correspondem iente é o arquivo nas configurações a a linha a duas linhas e a asterisco que usamos no exemplo anterior na São de saída você pode notar

As linhas marcadas com B que indicam que vieram do arquivo local e c as que vieram de oder os intervalos que estão em conflito e que realmente precisam ser reconciliados são marcados Com interrogação para resolver os intervalos em conflito a melhor abordagem é começar escolhendo o intervalo de A B ou C que mais se aproxima do ideal e depois fazer outras mudanças Se necessário para finalizar basta salvar As alterações e fechar o cadif 3 outro aviso importante você pode e deve ajustar a configuração da mesclagem para passar na construção e testes antes de consolidar pode

até criar alguns testes adicionais Mas nenhum outro tipo de alteração deve ser incluído nada de aproveitar a mesclagem e consertar um defeito acrescentar uma funcionalidade ou atorar o código essas coisas devem ser feitas em revisões específicas e resolução de conflitos é Isso mas por que acontecem conflitos há três causas possíveis falha na comunicação falha no processo ou falha no projeto vamos ver cada um desses tipos em detalhes a falha na comunicação acontece porque algum tipo de duplicação envolvida pode ser uma solicitação de mudança duplicada ou um escopo mal definido que dê margem a uma implementação

Redundante outro tipo de duplicação é quando um desenvolvedor vai além do que foi pedido por exemplo ao implementar uma funcionalidade descobre um defeito e aproveita para corrigi-lo no mesmo momento sem saber que já havia outra tarefa e pessoa alocadas para isso problemas desse tipo podem ser minimizados com uma avaliação rigorosa das solicitações de mudança e com revisão de código a falha no processo acontece Quando um desenvolvedor não segue as dir izes ou procedimento recomendado por exemplo não atualizar o diretório de trabalho paraa última revisão antes de começar uma nova implementação trabalhar em cima de uma

revisão antiga pode levar a conflitos porque você pode alterar um trecho que já foi substituído para outro mais recente outro caso comum é quando se adiciona arquivos secundários ou com preferências pessoais à Configuração já explicamos no primeiro módulo do curso porque isso não deve ser feito mas resumindo desses arquivos são binários ou com trechos que sempre mudam de uma pessoa para outra levando a conflitos constantes para eliminar esses problemas Invista na capacitação da sua equipe desse modo os desenvolvedores saberão usar corretamente as ferramentas respeitar as diretrizes e seguir os procedimentos Recomendados quando há falha no

projeto mesmo solicitações distintas acabam levando a mudanças nos mesmos intervalos do código a causa mais comum é devido à Baixa coesão dos módulos afetados Lembrando que coesão é quão relacionad são as operações de uma rotina quanto maior a coesão melhor por exemplo umaa calcular juros e multa que tem coesão comunicacional pode acabar sendo alterado em intervalos comuns por duas solicitações de mudanas distintas Alterar cálculo de juros e nova fómula para cálculo de multa para evitar esses tipos de conflitos é necessário melhorar a coesão dos módulos do projeto outro tipo de mudança que pode levar a

conflitos é a refat feita por uma pessoa enquanto outras pessoas fazem melhorias ou correções nos mesmos arquivos no caso da refação o melhor jeito de Minimizar os conflitos é por travamento ou ramo dedicado que trataremos em um próximo Capítulo Resumindo conflitos sinalizam problemas de comunicação processo ou projeto que precisam ser resolvidos quanto maior a qualidade da comunicação do processo e do projeto mais rara é a ocorrência de conflitos o que você precisa saber sobre o funcionamento da mesclagem é isso agora vamos refazer o estudo de caso de concorrência no controle de versão Centralizado usando a

mesclagem o ponto de partida é o mesmo revisão l No repositório central e nos diretórios de trabalho de João e Pedro tanto João quanto Pedro podem começar a editar o arquivo a simultaneamente produzindo a linha e a duas linhas respectivamente João e Pedro constrói e testam suas configurações mas João consolida Primeiro gerando revisão mal linha quando Pedro tenta fazer o mesmo recebe uma mensagem de erro indicando que suas alterações locais precisam ser Integradas Pedro faz o update e nesse momento que acontece a mesclagem as alterações mais novas presentes no repositório São combinadas com a configuração

pendente no diretório de trabalho gerando a configuração a asterisco se houver conflitos eles precisarão ser resolvidos nesse momento depois de construir e testar a última etapa é consolidar a asterisco para gerar a revisão correspondente antes de fazer uma nova Implementação João deve atualizar sua cópia de trabalho para partir da configuração mais recente disponível e o padrão se repete daí para frente o ciclo de edição é edita mescla consolida análise da concorrência baseada em mesclagem a mesagem funciona bem para arquivos texto porque é um formato simples e conhecido bado em caracteres e linhas é relativamente fácil

juntar automaticamente os intervalos editados Concorrentemente e produz um arivo válido no os conflitos podem ser reconciliados com ajuda de ferramentas específicas como cadif 3 isso não acontece para arquivos binários tais como Zip MP3 png etc porque esses formatos são muito específicos e desconhecidos pelo controle de versão mesmo combinação de intervalos disjuntos pode produz arivo inconsistente deito S ainda piores porque não podem recados Manualmente por exemplo mesmoo editem partes diferentes da foto da monolisa o controle de versão não conseguirá juntar essas partes depois mesmo que conseguisse o arquivo formado provavelmente seria inválido A melhor solução para

edição de arquivos binários é o travamento já para arquivos texto a mesclagem é a operação ideal pontos positivos e negativos a mesclagem possui uma fluidez melhor do que o travamento já que todos podem Editar simultaneamente qualquer arquivo desejado Outro ponto positivo é que funciona muito bem para arquivos texto um ponto negativo é que no controle de versão centr a mesagem acontece antes da consolidação não é o ide porque mistura uma configuração mas não consolidada com a mesem queos Anes outto netiv é que não fun para ariv bos eamos Porim veremos decia baseado em Ramos individuais

também usa mesclagem mas é típico do controle de versão distribuído até [Música] mais Olá pessoal Essa é a terceira parte da aula sobre o controle de concorrência nas aulas anteriores nós vimos que o controle de concorrência é que torna possível trabalhar em equipe e vimos também dois mecanismos travamento e mesclagem Nessa terceira parte da aula veremos out outro mecanismo que também é baseado em mesclagem Mas usa uma estrutura inerente ao controle de versão distribuído os Ramos individuais no controle de versão distribuído o histórico de revisões forma um grafo acíclico direcionado em que as revisões são

os nós e os apontadores dos Arcos um ramo é uma linha formada por uma sequência de revisões no Grafo na figura os três repositórios contêm o mesmo ramo mas à medida que João cria revisões no seu repositório local uma nova sequência formada que só existe ali por enquanto o mesmo acontece com Pedro o ramo individual é a sequência de revisões formada pelas consolidações no repositório local permanece isolado até ser combinado com outros ramos ou compartilhado com outros Repositórios o ramo individual fica mais Evidente no momento da Integração contra o ramo quando aparece a bifurcação característica

a integração de Ramos pode ser feita através de mesclagem ou rebase vamos ver as duas formas primeiro a mesclagem de Ramos individuais o termo mesclagem Nesse contexto significa junção das extremidades de dois ramos Produzindo um resultado inverso ao da bifurcação Independente da complexidade do grafo a mesclagem de Ramos usa apenas Três pontos de referência a revisão que está na contra de cada um dos Ramos envolvidos e o ancestral comum mais próximo que é a revisão a partir da qual os Ramos bifurcar as revisões de cada ponta são conhecidas e o ancestral comum é encontrado automaticamente

pelo controle de versão então o ramo 1 é formado pelas revisões 1 2 e 3 e o ramo dois pelas revisões 1 4 5 e 6 com esses três pontos é possível Calcular o team set equivalente de cada ramo que são todas as alterações feitas desde a primeira até a última revisão do ramo só lembrando que chend 7 é a diferença entre duas configurações a revisão da mesclagem faz a junção dos dois ramos combinando os cham sets equivalentes em um único Ponto Isso significa que a revisão da mesclagem Contém todas as alterações do ramo um

e do vamos ver como isso funciona através De um estudo de caso de controle de concorrência no controle de versão distribuído temos três repositórios o oficial um para João e outro para Pedro todos os repositórios e diretórios de trabalho partem da revisão a João e Pedro fazem suas alterações produzem as configurações a linha e a duas linhas constroem testam e consolidam João faz o p primeiro e envia revisão a linha para o repositório Oficial quando Pedro tenta fazer o mesmo sua operação rejeitada porque seu ramo individual precisa ser integrado com o ramo mais recente antes

de ser aceito Pedro Então faz o pull para trazer as revisões mais recentes o repositório local fica com os dois ramos que precisam ser integrados o comando merge faz a mesclagem resultando na configuração a asterisco que fica pendente no diretório de Trabalho se houver conflitos Pedro Deve conversar com João para chegar a um consenso sobre a solução e reconciliar os conflitos usando uma ferramenta tal como o cadif 3 Independente de ter havido ou não conflitos Você deve sempre verificar se a configuração resultante continua funcionando e passando nos testes antes de consolidar a consolidação cria a

nova revisão a asterisco que tem apontadores Tanto para revisão a linha quanto para a duas linhas Pedro refaz o push e as revisões a duas linhas e a asterisco são enviados ao repositório oficial completando o histórico o desenho do grafo Pode parecer um pouco diferente no repositório oficial mas é equivalente ao do repositório de Pedro as revisões são as mesmas e os apontadores também só estão em ordem diferente e na vez de João fazer uma Nova implementação o melhor a fazer é atualizar seu repositório diretório de trabalho usando pull e update para partir da configuração

mais recente disponível e o padrão não se repete daí por diante o ciclo de trabalho da mesclagem de Ramos é edita consolida mescla Isso significa que a consolidação fica a salva em uma revisão antes da mesclagem em caso de problema é muito mais simples de desfazer as alterações e Refazer a mesclagem do que no controle de versão Centralizado análise da mesclagem de Ramos em termos de dificuldade a mesclagem de Ramos é bastante simples de entender e de usar é só juntar as pontas dos Ramos resolver todos os conflitos de uma vez construir testar e consolidar

Mas nem tudo é perfeito o histórico fica cada vez mais difícil de ser visualizado à medida que cresce o Número de desenvolvedores com um desenvolvedor há uma única linha no histórico com dois desenvolvedores haverá duas linhas e assim por diante uma linha para cada desenvolvedor a partir de certo ponto o grafa do histórico fica ilegível e perde seu valor como informação essa figura ilustra uma situação assim a alternativa é substituir a junção que a mesclagem gera pela Concatenação de Ramos feita pela operação rebase o efeito do rebase é mover um ramo para o final do

outro no entanto não é possível realmente cortar e colar um ramo o que o rebase faz internamente é escrever o histórico cada revisão do ramo de origem é recriada no fim do ramo de destino através de uma operação de mesclagem a revisão C se torna Celinha que é a revisão da mesclagem que usa B e C com Revisões das pontas dos Ramos e a com ancestral comum de modo análogo a revisão D se torna D linha que é a revisão da mesclagem que usa Celinha e d como revisões das pontas dos Ramos e Sec com

ancestral comum se acontecer algum conflito ou rebase em rompido e os conflitos devem ser resolvidos pelo desenvolvedor só então o rebase pode continuar ao final o ramo original é desconsiderado e fica apenas o ramo concatenado no lugar o grafo se torna Linear e perde um pouco da representação histórica mas ganha muito na facilidade de visualização refazendo um estudo de casos usando rebase tudo acontece exatamente da mesma maneira da mesclagem até a integração dos Ramos todos partem da mesma revisão a João e Pedro produzem a linha e h duas linhas e consolidam João faz o push

e quando Pedro tenta fazer o mesmo recebe uma mensagem de erro Pedro Então Faz o pull e traz o ramo de João para o seu repositório local a diferença vem agora ao invés de usar o comando merge o comando usado é rebase o rebase faz a mesclagem dos Ramos individuais que terminam em a linha e a duas linhas gerando a asterisco se não houver conflitos a configuração a asterisco é consolidada automaticamente sem antes poder construir e testar se houver conflito então o rebase é interrompido até que o Conflito seja resolvido e daí por diante volta

o fluxo convencional Pedro faz o push João faz o pull seguido de um update e o padrão se repete daí por diante o ciclo de trabalho é edita consolida rebase análise o rebase mantém um histórico simples e linear O que é muito bom porém é uma operação mais complexa porque envolve manipulação do histórico cada revisão do ramo sendo recolocado é recriada e o processo é Interrompido sempre que acontece um conflito por outro lado se o processo não é interrompido então não é possível construir e testar as revisões antes de serem recriadas Lembrando que a sência

de conflito não garante que a configuração passa na construção e testes o que dá para fazer é construir e testar a última revisão do rebase e em caso de problema emendar a correção nessa revisão Além disso O rebase pode levar a Resultados indesejáveis e inesperados se for feito sobre revisões já compartilhadas porque ocorreria a duplicação de Chang sets em partes diferentes do histórico essas situações são bem difíceis de serem consertadas depois bem mas com todos esses problemas o rebase vale a pena para integrar Ramos individuais sim porque o histórico linear M útil mas quando usar

um ou out a recomendação é a seguinte use sempre Rebase para integrar Ramos individuais e mesclagem para Ramos coletivos o ramo funcional coletivo é um tipo de ramo que a gente vai ver na aula sobre variações de projeto o que posso adiantar é que o ramo coletivo é um ramo compartilhado que tem uma finalidade específica e segue determinadas regras de operação e o que eu tinha para falar sobre controle de concorrência é isso na próxima aula vamos ver uma revisão dos mecanismos de controle de concorrência Até mais [Música] Vamos fazer uma revisão dos mecanismos de

controle de concorrência há dois mecanismos de controle de concorrência travamento e mesclagem travamento cria um acesso exclusivo a escrita e a ideal para arquivos binários a mesclagem permite edição paralela com a combinação dos intervalos alterados depois é indicada para arquivos texto Conflitos são raros indicam alguma falha na comunicação processo ou no projeto que precisa ser resolvida a resolução de conflitos é manual deve-se usar uma ferramenta apropriada como cadif 3 o controle de concorrência no controle de versão distribuído se baseia em Ramos individuais a integração desses Ramos individuais acontece por mesclagem ou rebase E para finalizar

temos essa tabela com as características mais Comuns de cada operação o travamento e a mesclagem São do controle de versão Centralizado enquanto que a mesclagem de Ramos e o rebase são típicos do distribuído como o fluxo de trabalho do travamento é serial então não acontecem conflitos por isso é recomendado para arquivos binários o fluxo de trabalho dos demais é paralelo e podem acontecer conflitos mas conflitos em arquivos texto podem ser reconciliados Depois no controle de versão distribuído a mesclagem de Ramos é indicada para Ramos funcionais e o rebase apenas para Ramos individuais o travamento a

mesclagem e rebase produ um histórico linear fácil de visualizar na mesclagem de Ramos o histórico se torna complexo se usado em Ramos individuais porque gera uma linha para cada desenvolvedor do projeto em termos de dificuldade o rebase é uma operação complexa enquanto As demais são simples e ficamos por aqui na próxima aula veremos a demonstração do controle de concorrência na prática usando uma ferramenta de controle de diversão até [Música] mais nessa aula vamos atualizar o fluxo de trabalho para conter os novos procedimentos relativos ao trabalho em equipe a primeira versão do fluxo de trabalho era

esta o contexto era que você estava trabalhando num projeto Individual e não precisava interagir com mais ninguém mas isso mudou você agora faz parte de uma equipe e precisa sincronizar seu código com de outras pessoas por enquanto todo mundo ainda trabalha em paralelo no ramo principal para isso vamos ter que fazer algumas alterações a primeira alteração é que você sempre deverá atualizar sua cópia de trabalho antes de começar a implementação isso está na linha s a segunda alteração é que a Consolidação nem sempre vai dar certo de primeira pode acontecer de alguém ter consolidado antes

e nesse caso você vai ter que atualizar a cópia de trabalho conciliar a mesclagem construir testar E aí tentar consolidar novamente isso se repete até que você consiga fazer o comit com sucesso e a versão do fluxo de trabalho com as alterações é essa por enquanto esse é o algoritmo que você tem que seguir nos próximos exercícios e Demonstrações e ficamos por aqui então até a próxima aula [Música] Olá pessoal vamos ver como é o travamento no subversion o ponto de partida é o seguinte a topologia cliente servidor o servidor está configurado e rodando haverá

dois desenvolvedores trabalhando concorrentemente fulano e biot cada um já tem sua própria cópia de trabalho e alguns arquivos se você tiver alguma dúvida de Como chegar até esse ponto então é melhor rever a aula sobre topologia cliente servidor no subversion paraa demonstração a gente também vai usar duas propriedades svn Auto props define propriedades automáticas na adição de arquivos e svn needs loock que torna o arquivo read only para indicar necessidade de travamento o roteiro é o seguinte biotron vai começar definindo a propriedade sv props para ajustar todas As imagens que serão criadas em seguida Fulano

biotran criam e adiciona algumas imagens Fulano vai travar todas as imagens e beltrano vai tentar travar um arquivo específico como Fulano trava primeiro biotran não vai conseguir Fulano Então faz alteração na imagem consolida beltrano tenta travar novamente mas o erro dessa vez é que o arquivo está desatualizado botran tem que executar svn update E aí o travamento funciona biotron então faz Sua alteração na imagem os próximos passos vão mostrar como liberar roubar ou quebrar um travamento Então vamos à demonstração botran vai começar a implementação de um novo ticket o primeiro passo é atualizar sua cópia

de trabalho para garantir que está trabalhando na revisão mais recente disponível fica a dica então sempre Execute svn update Antes de iniciar a implementação de um novo ticket depois Beltran define a Propriedade svn Auto props na raiz da cópia de trabalho com valores que atribuem a propriedade SN needs loock para todos os arquivos com são jpg e ppng belron consolida usando a mensagem padrão e agora vamos criar alguns arquivos binários para serem travados depois Fulano botran começa fazendo um svn update padrão e depois usa um comando DD para copiar 256 KB de conteúdo binário aleatório

de bar Def Baru Random para simular arquivos de Imagens os arquivos são adicionados à configuração Note que eles têm a propriedade svn n loock definida mas ainda não estão como read only Isso vai acontecer logo depois do comit com tudo preparado agora é que começa o travamento para valer Fulano trava todos os arquivos pon png e biotran tenta travar imagem.png mas o travamento falha porque já está travado para fulano o comando SN status e SN status menos u mostram Alguns códigos adicionais a letra k indica que o arquivo está travado nessa cópia de trabalho a

letra O indica que o arquivo está travado num repositório e a trava pertence a outra cópia de trabalho Fan então simula a edição de imagem.png reescrevendo o conteúdo do arquivo e consolida note uma coisa Fulano travou vários arquivos editou apenas um mas depois da consolidação não restou nenhum arquivo travado no subversion você não Mantém as travas depois de uma consolidação isso evita que um arquivo fique travado indefinidamente por esquecimento na vez de beltrano o travamento falha novamente mas o erro agora é que o arquivo está desatualizado é necessário atualizar primeiro e só então o travamento

funciona biotran também sobrescreve o conteúdo do arquivo para simular a edição e consolida e travamento é isso mas o subversion ainda tem outros comandos de Manipulação de travamento nessa próxima etapa vamos ver como destravar roubar e quebrar travas Fulano faz o svn update e trava novamente todos os arquivos.png aí ele descobre que não precisa de um deles e destrava manualmente esse arquivo usando o comando svn unlock biotran quer editar o arquivo imagem quanto png e decide roubar a trava de fulano a força para isso usa o comando svn Lock com a opção Menos menos Force

para quebrar do Mat trava mas sem roubá-la basta usar svn unlock menos menos Force o estado da cópia de trabalho de fulano agora mostra dois novos códigos a letra T indica que o arquivo está travado na cópia de trabalho mas a trava está registrada para outro no repositório Isto é foi roubada a letra B indica que o arquivo está travado na cópia de trabalho mas não há registro Dessa trava no repositório Isto é a trava foi quebrada para acertar a situação da cópia de trabalho de fulano basta executar um svn update você pode estar se

perguntando para que que serve o travamento se é tão e sub meis sees de uma equipe não essiz então iso é um deha não do subversion porém há situações válidas em Que realmente é necessário roubar ou quebrar uma trava Por exemplo quando um desenvolvedor sai de férias e deixa alguns arquivos travados e o que você precisa saber sobre travamento é isso ficamos por aqui nessa aula faça os exercícios e na próxima aula veremos mesclagem até [Música] lá olá vamos refazer a demonstração do travamento do subversion Windows usando tortu Sbn Primeiro vamos começar um novo repositório

de nome projeto travamento na pasta repositórios crie uma nova pasta de nome projeto travamento e pelo menu de contexto escolha a opção tortas svn Create repository here e depois clica no botão para criar a estrutura inicial de diretórios Trunk brands e tags em seguida vamos criar duas novas cópias de trabalho uma para fulano e outra para beltrano no diretório de de Fulano pelo menu de contexto escolha a opção sbn checkout e especifica o RL do novo repositório projeto travamento usando ramo Trunk e depois faço o mesmo para beltrano criad as copas de trabalho Vamos começar

com beltrano para definir a propriedade svn Auto props na raiz da cópia de trabalho para criar essa propriedade Clique na raiz da cópia de trabalho com o botão secundário do mouse e no menu de Contexto escolha a opção tortu svn propriedades note que não é opção propriedades e sim tortu svn propriedades na janela que aparece escolha opção New para criar uma nova propriedade no entanto não é nenhuma dessas primeiras opções que aparecem você precisa escolher Order para que abra uma nova janela e apareçam todas as opções aí você escolhe svn apris e define valores que

atribuem a propriedade svn needs loock para todos Os arquivos com extensão pon jpg e ppng um por linha Como aparece aí e agora consolida a próxima ação é de fulano antes de fazer Qualquer mudança é importante sempre atualizar a cópia de trabalho vou adicionar agora algumas imagens ao projeto primeiro Copi as imagens para cópia de trabalho em seguida adiciona através do menu tortu svn add você pode ver que os icones indicam Que os arquivos estão Marcados para adição vou adicionar as imagens restantes através da cópia de trabalho de beltrano usando o mesmo procedimento e agora

vou consolidar nas duas cópias de trabalho duas coisas para reparar aqui primeiro é que as copas de trabalho ficaram diferentes depois da consolidação isso porque a consolidação só envia a configuração pro repositório mas não atualiza cópia de trabalho quem Faz isso é usbn update e a segunda é que mesmo com as propriedades definidas corretamente paraas imagens o ícone de estado não está correto deveria aparecer um ícone cinza indicando que o arquivo é read only e precisa ser travado para ser editado o problema é que o Windows Tem um limite muito baixo em relação ao número

de ícones de estado disponíveis e às vezes nem todos aparecem mas vamos continuar para isso vamos atualizar as Duas cobas de trabalho Fulano agora vai travar todas as imagens usando o menu tortu svn get loock não é necessário fornecer nenhuma mensagem na janela que abre basta clicar em Ok e pronto mais uma vez Note que os ícones deveriam ter mudado para um adado não aconteceu mas os arquivos estão travados isso pode ser confirmado pelo tortu svn check for modifications na coluna Lock está aparecendo o usuário user Porque não estamos realmente simulando dois usuários é o

usuário e user com duas cópias de trabalho Independentes mas tá valendo no próximo passo Beltran vai travar um dos arquivos e vai receber um erro porque o arquivo já está travado por outro usu o que na verdade é a outra cópia de trabalho Fulano Então vai aditar a figura da garota com brinco de pérola e pôr um bigode Nela e agora consolidar Note que a lista de arquivos alterados contém todos os arquivos travados mesmo que apenas um deles tenha sido efetivamente alterado o subversion não mantém automaticamente a trava e isso significa que todas as travas

serão liberadas automaticamente após a consolidação isso é uma coisa boa porque você não esquece um arquivo travado por Acidente se quiser manter a trava você precisa tirar o arquivo da Lista e agora botran vai tentar travar a mesma imagem para poder editar usando tortuosas VN get loock a mensagem de erro agora diz que o travamento falhou Porque é necessário atualizar minha recomendação é para não atualizar um arquivo isolado atualize sempre a cópia de trabalho inteira sendo assim vou Fechar essa janela e aplicar o svn update na raiz da cópia de trabalho e agora sim Bean

consegue travar a imagem a edição agora parte da Imagem já alterada e vai pôr um cavanhaque na almoça e a consolidação na próxima etapa vamos ver como destravar roubar e quebrar uma trava Fulano atualiza a cópia de trabalho e trava novamente todo as imagens para destravar explicitamente um arquivo basta clicar no arquivo com botão secundário do mouse e escolher a opção tortu svn release Lock outra forma é através do tortu VN Check for modifications na lista que aparece você escolhe o arquivo ou o arquivo que quer destravar e no menu de contexto seleciona a opção

release Lock vamos ver como roubar uma trava Primeiro beltrano vai tentar travar uma das imagens mas vai dar errado porque já está travada para roubar a trava você usa a mesma opção tortu svn get loock mas marca a caixa STE Delox e pronto a trava agora é de me TR a cópia de trabalho de fulano agora tem uma trava inválida é possível ver isso através do tortu svn check for modifications e depois clicando em check repository na coluna Lock aparece que a trava foi roubado por outra pessoa Lembrando que o n do usuário não está

correto porque não estamos realmente simulando dois usuários para limpar essa trava quebrada basta atualizar a cópia de trabalho Agora vamos ver como quebrar uma trava Execute tortu svn check for modifications check repository depois selecione os arquivos e no menu de contexto escolha Break Lock nesse caso a trava original é quebrada mas não passa para Bean E mais uma vez para concertar a situação na cópia de trabalho de fulano basta atualizar a cópia de trabalho e o que é para serviço de travamento é isto ten em mente que o Travamento no subversion É um mecanismo de

sinalização se os desenvolvedores de uma equipe não respeitam essa sinalização Então isso é um sinal de uma falha cultural que precisa ser tratada e não o problema do subversion porém H situações válidas em que realmente necessá roubar ou quebrar uma trava Por exemplo quando um desenvolvedor sai de férias e deixa alguns arquivos travados e ficamos por aqui nessa aula Faça os exercícios e na próxima aula veremos mesclagem até [Música] lá olá vamos L mostrar como funciona a concorrência por mesclagem no subversion roteiro da demonstração no primeiro exemplo fulano e beltrano editaram concorrentemente o mesmo arquivo

mas em intervalos diferentes por isso não haverá conflitos no segundo exemplo a edição concorrente será intervalos comuns e por Isso haverá conflitos durante a mesclagem vamos ver como resolver essa situação e no último exemplo vou mostrar como cancelar a conciliação de um conflito vamos partir pra demonstração então o servidor está configurado e rodando cada desenvolvedor tem sua própria cópia de trabalho com alguns arquivos já criados Fulano biotran vão editar o arquivo letras pxt a mesmo tempo mas em partes diferentes Isto é sem intervalos comuns fano vai editar as Primeiras linhas e beltrano as últimas linhas

Fulano consolida primeiro ação de belano Então não é aceita porque o arquivo letras pxt está desatualizado em relação à revisão mais recente no repositório o asterisco apresentado pelo comando svn status menos u indica que existe uma revisão mais recente no repositório biotron então executa svn update e a mesclagem acontece indicada pela letra g na mensagem o svn dif mostra que o Arquivo letras. TXT agora contém as letras A e B maiúsculas mais as alterações que estavam pendentes lembre-se de que um caso real não é porque não houve conflito que está tudo bem você ainda tem

que compilar e testar antes de consolidar E para finalizar beltrano repete o último comando sven commit e agora funciona na próxima etapa fulano e beltrano editam concorrentemente o arquivo números P TXT Fulano escreve os Números 1 2 4 e 5 por extenso e Beltran nos números 4 5 7 e 8 em inglês então as linhas dos números 4 e 5 vão formar um intervalo em conflito Fulano consolida primeiro quando beltrano tenta consolidar o comit falha indicando o conflito perceba porém que o svn commit não gera o conflito apenas aponta o problema o conflito mesmo só

acontece com o sbn update que pede para o desenvolvedor escolher uma opção para Solucionar a situação eu sugiro que quando isso acontecer você não tome nenhuma decisão agora escolha a opção postpone que significa adiar a cópia de trabalho agora contém um arquivo em conflito marcado com c e três outros arquivos auxiliar que serão usados na resolução do conflito não adianta tentar consolidar sem resolver o conflito antes não funciona o arquivo em conflito possui várias marcações para indicar os Intervalos sobrepostos Eu particularmente acho que editar esse arquivo diretamente é complicado e sujeito a erros você pode

facilmente acabar deixando alguma marcação para trás ou um intervalo sem conciliar o melhor mesmo é usar uma ferramenta gráfica mais apropriada como cadif 3 por exemplo a ordem dos argumentos é a seguinte cadif 3 base local remoto menos o arquivo conciliado base é o arquivo na revisão De onde partiram as edições concorrentes local é o arquivo que Você alterou e tentou consolidar remoto é a revisão mais recente do arquivo que está no repositório menos ó para mesclar e arquivo conciliado é o destino da mesclagem entre os arquivos auxiliares o arquivo com número menor é sempre

base o de número maior é o remoto e o com extensão pon mine é o arquivo local o comando Para chamar o cadif 3 Fica assim então e o processo de conciliação é o mesmo que vimos na aula anterior Lembrando que é necessário conversar antes com a outra pessoa envolvida e chegar em um acordo depois escolha o intervalo que mais se aproxima do desejado edite o que faltar e salve o resultado depois da conciliação os arquivos auxiliares ainda continuam lá é necessário avisar o sub vero que o conflito foi resolvido com o comando sbn Resolved

e mais uma vez deve ser construir e testar o projeto e só depois disso consolidar na próxima etapa vamos ver como cancelar a mesclagem primeiro fulano e biotran vão provocar outro conflito editando concorrentemente o mesmo intervalo de um arquivo depois que biotran executa o svn update sua cópia de trabalho está em conflito para cancelar a mesclagem Execute comando sbn revert pode ser Passando o nome do arquivo em conflito ou com opção menos r maiúsculo para ser recursivo e reverter todas as alterações veja que a reversão leva o arquivo ao estado da revisão da última atualização

e não ao estado das alterações locais antes do svn update essas alterações já eram e ficamos por aqui nessa aula até a próxima [Música] Olá vamos refazer a demonstração de como Funciona a concorrência por mesclagem do subversion usando tortu as sbm o roteiro da demonstração é o seguinte no primeiro exemplo fulano e beltrano editaram concorrentemente o mesmo arquivo mas em intervalos diferentes por isso não haverá conflitos no segundo exemplo a edição concorrente será intervalos comuns e por isso haverá conflitos durante a mesclagem vamos ver como resolver essa situação e no último exemplo vou mostrar como

cancelar a Conciliação de um conflito vamos começar a demonstração então o repositório já tá criado e cada desenvolvedor tem sua própria cópia de trabalho com alguns arquivos já incluídos antes de começar qualquer alteração vamos atualizar as cópias de trabalho Fulano biotran vão editar o arquivo letras. TX ao mesmo tempo mas em partes diferentes Isto é sem intervalos comuns Fulano vai editar as primeiras linhas e beltrano as últimas Linhas Fulano consolida primeiro para consolida não é aceita porque o arquivo letras está desatualizado em relação revisão mais recente no reposit nesses antes deiz euo que você simonte

atualiz para não pego depres Então vamos cancelar atualiz e oit e fazer simulação at do svn check modification check repository a janela mostra que o arquivo letras foi modificado localmente e Remotamente para ver as alterações locais e remotas e como elas vão se combinar basta clicar duas vezes no arquivo essa outra janela é o toas merge a São do topo do lado esquerdo contém o arquivo letras pxt como está no repositório indicada por Dars a São do lado direito contém o arquivo como está na cópia de trabalho indicado por mine e a São de baixo

mostra como vai ficar a combinação dessas duas versões nesse caso não há conflito Porque não Houve intervalos comuns as alterações puderam ser combinadas automaticamente pelo controle de versão Mas essa é só uma simulação Então vamos fechar as janelas e executar o sv update para valer e a mesclagem aconteceu como esperado lse de que em caso real não é porque não houve conflito que tá tudo bem você ainda tem que construir e testar antes de consolidar como não é o caso aqui beltrano vai Apenas consolidar na próxima etapa fulano e beltrano editam concorrentemente o arquivo números

P TXT Fulano escreve os números 1 2 4 e 5 em inglês Fulano consolida primeiro e Beltran nos números 4 5 7 e 8 Pro extenso Então as linhas dos números 4 e 5 vão formar um intervalo em conflito quando biotran tenta consolidar o comit falha indicando que o arquivo Está desatualizado E mais uma vez antes de atualizar vamos simular a mesclagem para ver o que acontece biotran vai acionar o tortu svn cheque para modifique e depois clicar duas vezes no arquivo os trechos em amarelo e laranja indicam intervalos que foram combinados automaticamente mas os

intervalos em conflito estão marcados em vermelho para serem resolvidos manualmente na seção de baixo clicando Com o botão secundário do mouse sobre as linhas em conflito aparece o menu de contexto com opções para escolher trechos de intervalos de uma versão ou de outra você pode começar por aí e continuar editando como for necessário depois para resolver o conflito vou escolher a versão mine e depois alterar a linha de qu para for para chegar ao meio termo entre as duas alterações se não fosse uma simulação biotran iria salvar e fechar a janela Mas como é só

simulação basta fechar a janela e atualizar a cópia de trabal e agora o conflito é para valer o arquivo em conflito e os arquivos auxiliares estão presentes na cópia de trabalho o arquivo em conflito possui várias marcações para indicar os intervalos sobrepostos editar esse arquivo diretamente é complicado e sujeito a erros você pode facilmente acabar deixando alguma marcação para trás ou um Intervalo sem conciliar o melhor a fazer é editar pelo tortu merge tal como fizemos na simulação para isso clique no arquivo com botão secundário do mouse e escolha a opção tortu svn Edit conflicts

o tar smge abre e é só fazer o mesmo procedimento foi feito na simulação mas salvando ao final e marcando o conflito como resolvido os arquivos auxiliares somem e fica só o arquivo alterado vou só Consertar aqui o número oito que ficou para trás e agora é consolidar a mensagem de consolidação é um pouco diferente porque chegamos a um meio termo e o número qu permaneceu em inglês e agora na última etapa da demonstração vamos ver como abandonar as alterações locais sempre antes de começar uma alteração você deve atualizar a cópia de trabalho então fulano

e beltrano fazem Isso em seguida Fulano muda o número um que estava em inglês de volto para algarismo biotran muda a mesma linha trocando um para Uno Fulano consolida primeiro e tudo bem Bel não consegue consolidar porque a cópia de trabalho vai estar desatualizada em relação à revisão do repositório e antes de atualizar Beltran fará simulação no check for modifications check repository E clicando duas vezes sobre o arquivo Biotran percebe que é melhor abandonar suas alterações se a cópia de trabalho ainda não foi atualizada basta reverter o arquivo para o estado original antes da alteração

e depois atualizar a cópia de trabalho mas e se você já tiver feito a atualização procedimento é o mesmo ao invés de editar o conflito você escolhe a opção para reverter o arquivo e assim chegará ao mesmo resultado e a demonstração da mesclagem termina aqui Até a próxima [Música] aula Olá essa é a primeira de uma série de aula sobre o último conceito que falta sobre o funcionamento do controle de versão variações de projeto nós veremos por variações de projeto são necessárias como controle de versão fornece variações de projeto Como organizar o projeto em diferentes

Ramos e como trabalhar com esses Ramos durante o desenvolvimento de software há Várias atividades que precisam ser feitas ao mesmo tempo implementação de novas funcionalidades correção de defeitos encontrados em produção testes da próxima versão a ser lançada experimentação tecnológica que pode se mostrar viável ou não o problema é que essas atividades são incompatíveis por exemplo não é possível fazer certos tipos de testes se o conjunto de funcionalidades fica mudando o tempo todo Mas o desenvolvimento de novas funcionalidades também não pode ficar parado enquanto os testes são executados a questão portanto é como fazer tudo isso

ao mesmo tempo mas de maneira isolada e independente a solução do controle de versão é a ramificação um ramo é uma linha distinta no histórico que cria uma variação do projeto com uma evolução própria há dois ramos na figura o primeiro é formado pelas revisões 0 1 do E TR vamos chamar esse ramo de a o segundo é uma bifurcação que começa na revisão um e continua pelas revisões 4 5 e 6 esse será o ramo B Ramos são independentes mas existem situações em que é necessário levar as alterações de um ramo para outro isso

é feito através da mesclagem a mesclagem é feita a partir de três pontos de referência a revisão da extremidade do ramo a a revisão da extremidade do ramo B e o ancestral Comum mais próximo que é a revisão a partir do qual os Ramos A e B B fcaram as revisões das extremidades são conhecidas e o ancestral comum é encontrado automaticamente pelo controle de versão o t set equivalente de cada ramo é calculado pela diferença entre a revisão acenal comum e a de extremidade do ramo no exemplo a revisão s é a revisão gerada pela

mesclagem essa revisão junta Os ch sets equivalentes dos dois Ramos envolvidos desde a bifurcação na revisão um um conceito importante é que a mesclagem leva as alterações de um ramo para outro mas isso depende de Qual ramo contém a revisão da mesclagem se a revisão 7 pertencer ao ramo b então as alterações do ramo a são levados ao ramo B de modo análogo se a revisão 7 pertencer ao ramo a o resultado será o oposto as alterações do ramo B que serão levadas ao ramo a para que fique Claro o Ramo da mesclagem é aquele

em que o diretório de trabalho está posicionado durante a execução da mesclagem antes de continuar vamos simplificar a representação do histórico para destacar apenas os Ramos e as mesclagem ao invés de mostrar todas as revisões do histórico vamos usar setas para representar um ramo a criação de um ramo ou uma mesclagem Note que o sentido das setas é o oposto dos apontadores do grafo a origem da Seta é o ramo de origem e a ponta da seta o destino qual a importância da ramificação e da mesclagem no desenvolvimento se usado corretamente a ramificação e a

mesclagem produzem uma estrutura que consegue absorver todas as mudanças do projeto de maneira ordenada desde as emergenciais que precisam ser atendidas com urgência e postas em produção até as alterações incertas que podem se mostrar viáveis ou Não com o tempo mas isso não acontece por acaso existem certos padrões de ramificação e regras de mesclagem que precisam ser seguidos há quatro tipos de Ramos principal dedicado de manutenção e o ramo individual todos os Ramos tem a mesma estrutura o que muda de um tipo do Rama para outro são as regras de funcionamento na próxima aula vamos

ver os dois primeiros tipos o ramo principal E o ramo dedicado até lá [Música] Olá pessoal nessa segunda aula sobre variações de projeto veremos o funcionamento do ramo principal e do ramo dedicado na aula anterior nós vimos porque variações de projeto são necessárias como o controle de versão implementa variações de projeto e vimos também que há quatro tipos de Ramos principal dedicado de manutenção e o ramo individual todos os Ramos têm a Mesma estrutura Isto é São sequências de revisões que formam linhas Independentes de desenvolvimento o que muda de um tipo para outro são as

regras de funcionamento o ramo principal é o primeiro e o mais importante de um projeto no subversion é chamado de Trunk no Git de Master e no Mercúrio de Def seu objetivo é concentrar todas as funcionalidades melhorias correções etc que serão disponibilizadas na próxima grande versão a ser lançada em produção Abre um parêntese aqui grandes versões contém novas funcionalidades e Versões menores contém apenas correções de defeitos Vamos ver isso melhor quando tratarmos de etiquetas e Ramos de manutenção na próxima aula fecha parênteses o ramo principal existe por todo o tempo de vida do projeto e

serve de base para todos os demais Ramos do projeto também é muito importante que seja mantido tão estável quanto possível com tendo apenas revisões completas e Funcionais por isso o que deve ser desenvolvido diretamente no ramo principal são apenas mudanças que sejam simples e rápidas e garantidamente necessárias pra próxima versão Qualquer mudança que não se encaixar nessa categoria isto é uma implementação complexa ou demorada ou incerta deve ser feita em um ramo dedicado por exemplo um subsistema um módulo precisa estar completo para ser incluído na próxima versão e isso pode Ser complicado ou demorar se

a implementação for feita diretamente no ROM principal pode atrasar o lançamento de uma nova versão outro caso comum é de experimentação tecnológica aparece uma nova arquitetura ou tecnologia que pode ser boa pro projeto mas precisa ser avaliada antes de ser incorporada é muito arriscado fazer isso diretamente no ramo principal porque não tem como separar depois se não der certo Você deve fazer qualquer experimentação em um ramo dedicado para manter o risco isolado o padrão de funcionamento de um ramo dedicado é o seguinte primeiro ele é criado sempre a partir do ramo principal o ramo dedicado

costuma ser usado por uma parte da equipe do projeto geralmente mais de uma pessoa se o resultado da implementação feita no ramo dedicado for satisfatório o ramo é então mesclado de volta no ramo principal senão ele é apenas Abandonado o tempo entre a criação do ramo dedicado e a mesclagem de Reintegração no rama principal costuma variar de alguns dias a algumas semanas se o tempo for muito longo a mesclagem final acaba sendo grande e complicada porque o ramo principal fica muito divergente do ramo dedicado esse problema pode ser minimizado com mesclagem periódicas vindas do ramo

principal para manter o ramo dedicado sempre próximo desse modo ao invés de Uma grande mesclagem no final você tem várias mesclagem menores e mais simples outra regra importante um ramo dedicado só conhece o ramo principal não existe mesclagem entre Ramos dedicados nem com qualquer outro ramo que não seja o ramo principal isso evita a contaminação de riscos de um ramo para outro e ficamos por aqui na próxima aula veremos etiquetas o ramo de manutenção e a sua variação o ramo estável até lá [Música] Olá pessoal nessa terceira aula sobre variações de projeto veremos etiquetas ramo

de manutenção e o ramo estável o objetivo do ramo de manutenção é corrigir defeitos de uma versão em produção mas sem alterar o conjunto de funcionalidades porque isso descaracterizaria a versão para entender quando e por o ramo de manutenção aparece precisamos antes conhecer os estágios de um projeto do ponto de vista Do lançamento em produção durante seu ciclo de vida o projeto passa por vários estágios pré alfa alfa beta release candidate e versão em produção pré Alfa ainda é o começo do projeto nesse ponto o sistema ainda não está operacional porque suas partes ainda não

se integram podem existir alguns testes unitários mas ainda não há outros níveis ou tipos de testes automatizados disponíveis no estágio alfa o software Está operacional mas está incompleto e possivelmente estável aumenta o número de tipos de testes automatizados como os de integração e de sistema na fase beta o software está pronto para homologação o conjunto de funcionalidades é congelado O que significa que adições de novas funcionalidades estão suspensas o foco passa a ser na correção defeitos e nos detalhes de acabamento principalmente em Termos de usabilidade testes não automatizados são executados por uma equipe específica release

Cand datate indica que a versão ainda está so análise mas está adequada para ser lançada se nenhum outro problema for identificado durante os testes que Ainda faltam a diferenciação entre uma versão Beta e um elase cdate Nem sempre é usada muitos projetos preferem passar da fase Alfa diretamente para RC versão em produção a última RC renomeada pra versão que será disponibilizada para os usuários a partir de então outras menores com correções de defeitos podem ser lançadas para registrar no histórico que o projeto Chegou a um desses estágios marca-se a revisão correspondente como uma etiqueta que

em inglês é tag a etiqueta contém um nome mais significativo do que a numeração sequencial ou hash que são fáceis de Esquecer ou confundir existem vários esquemas de nomeação de etiquetas a escolha de um ou outro esquema é uma decisão gerencial não tem nada a ver com a ferramenta de controle de versão usada os esquemas mais comuns são numeração sequencial e data de lançamento a numeração sequencial é composta por um ou mais grupos de números que indicam o nível das alterações realizadas em relação à versão anterior por exemplo em um Esquema com os grupos x

p y o número X é incrementado quando novas funcionalidades são incorporadas e o número Y quando há correções de defeitos mas sem mudanças nas funcionalidades além dos grupos numéricos também é comum acrescentar letras a b ou RC para indicar as fases alfa beta e release candidate um exemplo de sequência ordenada de versões é 1.0 a é menor que 1.0b que é menor que 1.0 rc1 e assim por Diante a numeração por data de lançamento geralmente segue formato ISO Isto é ano mês e dia com ou sem ifin para facilitar a ordenação o bunton Linux por

exemplo segue formato ano pon mês para marcar seus lançamentos semestrais tal como em 18.10 que indica outubro de 2018 ou 19.04 que indica abril de 2019 e assim por diante voltando então ao ramo principal e como surge o ramo de manutenção Imagina um projeto de software que começou agora como ainda está na fase pré Alfa não é necessário criar nenhuma etiqueta mas mas quando chega no estágio Alfa é interessante marcar a revisão correspondente depois de mais um tempo o projeto chega no estágio Beta e o conjunto de funcionalidades precisa ser congelado a partir desse ponto

como o ramo principal não deve ficar parado Vamos criar um ramo de manutenção para fazer a homologação da versão que Entrará em produção o nome apropriado para um ramo de manutenção depende do esquema de numeração da versão sendo usado o ideal é usar um nome que generalize a variação do número menos significativo correspondente às correções o nome 1x ou versão 1 são adequados para manter as sequência de versões 1.0 1.1 1.2 etc o intervalo entre a versão Beta e a primeira versão oficial em produção corresponde a fase de homologação quando se fazem os Últimos testes

e acabamentos na usabilidade do software a última versão RC vira versão em produção 1.0 e a fase passa a ser de manutenção alguns projetos lançam versões Com pequenas correções periodicamente no caso de correções emergenciais de defeitos graves de segurança por exemplo o lanamento é feito logo após a correção do defeito Contendo a correção emergencial e todas as demais correções acumuladas até o Momento Umo ter um ou mais Ramos de manutenção dependendo do tipo do software sistemas operacion por exemplo possuem várias versões diferentes em uso que precisam ser mantidas simultaneamente por um longo tempo esses Samos

de manutenção costumam durar anos recebendo pelo menos correções de segurança até a versão ser descontinuada e o ramo abandonado vamos estender o exemplo até o aparecimento de um novo ramo de Manutenção enquanto a versão 1 está em produção o ramo principal tá preparando a versão 2 quando chega a versão 2.0 Beta outro ramo de manutenção é criado e o processo de homologação e manutenção se repete o ramo principal passa do Futuro lançamento da versão 3 perceba que na representação dos Ramos o ramo 1.xic acima do ramo 2.xci do ramo principal essa convenção é importante no

entendimento das regras de mesclagem para propagação de correções Vamos entender como funciona a propagação de correções de modo geral as correções são feitas em um Ramo e depois repassada a outros através de mesclagem nesse estudo de caso o projeto tem três Ramos o ramo 1x é o ramo de manutenção mais antigo em seguida vem o ramo 2.xd as funcionalidades de 1 PX e mais outras o ramo principal contém todas as funcionalidades dos Ramos 1 PX e 2 PX além de outras que faram parte da versão 3 que ainda será lançada se um defeito Identificado na

versão do é possível que ele também exista na versão um e no ramo principal você poderia corrigir manualmente o defeito em em cada ramo mas é muito mais simples e eficiente corrigir em um único Ramo e depois repassar as alterações aos demais através de mesclagem porém existe uma ordem correta para fazer isso lembre-se que a mesclagem leva tudo que um ramo contém de diferente para outro ramo se a correção for feita no ramo 2.xml no ramo Principal então só a correção enviada porque esse ramo é um subconjunto das funcionalidades do ramo principal e a única

diferença a mais é a correção em si Mas se a mesclagem for do ramo 2.xx então a correção e também todo o conjunto de funcionalidades da versão 2 serão enviados ao ramo da versão 1 o que tornaria ele igual ao ramo 2.xe o objetivo a gente precisa que apenas as correções sejam Levadas procedimento correto portanto é começar a correção pelo ramo mais antigo que contém um defeito e depois ir mesclando consecutivamente com o próximo ramo de manutenção até chegar ao ramo principal vamos formalizar melhor esse procedimento de propagação de correções o primeiro passo é identificar

o ramo de manutenção mais antigo que contém um defeito tem em mente o seguinte Nem sempre a correção começa pelo ramo em Que o defeito foi relatado você precisa testar em outros ramos mais antigos para confirmar essa informação o segundo passo é implementar a correção como qualquer alteração isso envolve construir testar e depois consolidar usando mensagem padrão resolve # númerodo ticket bar título ticket os passos seguintes repassam as correções por mesclagem de um ramo de manutenção para o próximo até chegar ao ramo Principal os SOS dedicados não precisam receber as correções nesse momento porque possuem

políticas próprias de atualização periódica com o ramo principal algumas considerações adicionais o procedimento de propagação de correções deve ser seguido mesmo no caso de uma correção emergencial as mesagens de propagação devem ser feitas imediatamente após a correção do defeito e pela mesma pessoa porque ainda faz parte da mesma tarefa De correção Nem sempre a mesclagem com a correção se encaixará perfeitamente porque os Ramos TM evolução diferentes às vezes são necessários alguns ajustes e outras vezes a mesclagem nem é necessária porque a parte com defeito foi substituída em uma versão mais nova o próximo ramo é

o ramo estável o ramo estável é uma variação do ramo de manutenção ele aparece porque nem todos os projetos precisam ou desejam manter Várias versões em produção ao mesmo tempo uma aplicação web por exemplo só tem uma versão em produção quando uma nova versão é lançada o servidor é atualizado e a migração de todos os usuários é automática outros tipos de projeto escolhem essa política porque torna o desenvolvimento mais simples e não há interesse ou necessidade se manter mais de uma versão em produção C nova versão substitu as antigas tant em número de funcionalides como

em correção Defeitos em projetos open source verão em produção um únic deut é suficiente vamos de porque não está atrelado fam espí de versões a difença é que o estável é reiniciado a cada lanamento de uma grande versão funciona assim até o início da homologação da versão do o funcionamento é igual ao caso anterior a diferença começa a partir da versão 2.0 Beta ao invés de criar um Novo ramo para congelar as funcionalidades o ramo estável é reiniciado com uma mesclagem que sobe do ramo principal tornando o ramo estável igual ao ramo principal naquele momento

a partir daí o processo se repete o que você precisa saber sobre etiquetas e Ramos de manutenção é isso na próxima aula veremos como o ramo individual se encaixa no contexto de variações de projeto e também uma recomendação de fluxo de trabalho Envolvendo ramificação até [Música] mais Olá nessa aula vamos ver como o ramo individual usado no controle de concorrência se encaixa no contexto de de variações de projeto sobre o ramo individual e sua relação com outros tipos de Ramos então em primeiro lugar é importante perceber que há dois níveis de paralelismo o paralelismo entre

atividades de desenvolvimento Isto é codificação teste manutenção etc e o Paralelismo dos desenvolvedores trabalhando simultaneamente dentro de cada uma dessas atividades o primeiro tipo é resolvido pelos Ramos principal dedicado e o de manutenção vamos classificar esses Ramos como tivos o segundo tipo de paralelismo é resolvido pelos mecanismos de controle de concorrência que são o travamento a mesclagem e os Ramos individuais no controle de versão Distribuído não se trabalha diretamente em um ramo coletivo você começa com um ramo individual que depois é combinado com outros através de mesclagem ou rebase E aí acabam formando os Ramos

coletivos em termos de tempo de vida a duração do ramo individual é curta variando de minutos a algumas horas é claro que isso depende do bom dimensionamento do Ticket ao qual está associado se o Ticket for mal dimensionado o que deveria durar horas Pode durar dias e o ramo individual começará a se parecer cada vez mais com o ramo dedicado e isso conclui a matéria sobre variações de projeto foi um tópico bem extenso então na próxima aula Vamos fazer uma revisão geral até lá [Música] Olá nessa aula Vamos fazer uma revisão dos conceitos de variação

de projeto um ramo é uma linha distinta e isolada de evolução do projeto todos os tipos de Ramos tem a mesma estrutura interna o que muda de um ramo para outro são as regras que definem os tipos de alteração e os padrões de mesclagem permitidos há dois níveis de paralelismo no desenvolvimento de software paralelismo de atividades e paralelismo dentro de cada atividade o paralelismo entre atividades é obtido através de Ramos coletivos cujos tipos são principal dedicado e de manutenção o paralelismo dentro de cada Atividade o que também significa dentro de cada ramo coletivo é obtido

através do controle de concorrência cujos mecanismos são o travamento mesclagem ou Ramos individuais o ramo principal tem como finalidade manter a figuração que se tornará a próxima grande versão do projeto a ser lançada em produção o ramo principal recebe diretamente todas as implementações que sejam simples e rápidas e garantidamente Necessárias é um ramo de longa duração é o primeiro ramo que aparece e dura por toda a vida do projeto no subversion esse ramo é chamado de Trunk no Git é chamado de Master e no Mercúrio é chamado de Def o ramo dedicado também é conhecido

como feature Branch ou Topic Branch sua finalidade é manter a instabilidade longe do ramo principal é indicado para implementações complexas ou demoradas ou incertas tem duração que varia de alguns Dias a semanas uma restrição de operação do ramo dedicado é que ele só se comunica com o ramo principal e deve ser mantido atualizado com mesclagem periódicas para não ficar muito divergente os nomes de Ramos dedicados são relacionados com o módulo subsistema ou experim ação que será implementada por exemplo caso de uso 1 23 funcionalidade x módulo Y etc a finalidade do ramo de manutenção É

Permitir correções de defeitos sem alterar o conjunto de funcionalidades deve ser usado para manter uma versão em produção e dura Enquanto existir versões a serem mantidas O que leva geralmente anos uma correção deve ser feita no ramo mais antigo que contém o defeito e depois repassado consecutivamente por mesclagem ao próximo ramo de manutenção mais antigo até chegar ao ramo principal os nomes dos Ramos de manutenção variam conforme o conjunto de Versões menores sendo mantidas tais como 1 PX e versão 2 o ramo estável é uma variação do ramo de manutenção é usado por projetos que

só precisam ou desejam manter correções na última versão em produção o ramo stel é de longa duração existe a partir do lançamento da primeira versão e dura Enquanto existir o projeto o o Ram stav é um ramo de manutenção único que é reiniciado a cada lançamento de uma grande versão com uma mesclagem que sobe Do ramo principal o nome comum para esse ramo geralmente é stable por último temos o ramo individual que funciona como mecanismo de controle de concorrência e é inerente ao controle de versão distribuído tem curta duração variando de minutos a horas apenas

o tempo suficiente para implementar um ticket depois ele é combinado com outros ramos individuais através de re clagem ou rebase e passa a fazer parte de um Ramo coletivo a recomendação é usar o rebase para que o histórico do ramo coletivo permaneça linear lembre-se que o rebase não deve ser usado entre Ramos coletivos porque esses Ramos já foram compartilhados e o rebase geraria uma duplicação do histórico muito difícil de consertar entre Ramos coletivos usa apenas a mesclagem um último detalhe Ramos individuais não precisam ter nomes específicos eles Aparecem naturalmente no controle de versão distribuído e

ficamos por aqui na próxima aula começaremos a parte prática até [Música] mais vamos pra última atualização do fluxo de trabalho para incluir os procedimentos relativos a variações de projeto a versão que estamos usando é essa aí que trata do trabalho em equipe mas não lida com trabalho em diferentes Ramos do projeto ainda antes de continuar vamos contrair esses espaços já conhecidos para ficar mais simples ao invés de escrever os passos em detalhes como tá agora eles vão virar chamadas para funções é uma mudança apenas cosmética agora vamos incorporar novos passos para lidar com diferentes Ramos

do projeto a primeira sessão é para definir qual o ramo da Implementação se o tipo do Ticket for um feito é necessário descobrir qual o ramo mais antigo que contém um defeito senão se a mudança solicitada tiver de ser entregue na próxima versão Então significa que a alteração deve ser feita diretamente no ramo principal se não for Nem um nem outro então só pode ser um ramo dedicado Cabe a você descobrir se esse ramo dedicado já existe ou não isso não tá explícito aí no procedimento em seguida é necessário Verificar se o diretório de trabalho

está posicionado no ramo correto se não estiver Então você deve posicionar o diretório de trabalho nesse ramo os passos seguintes são os mesmos que vimos antes para implementar construir e testar e depois conciliar e consolidar os passos finais do procedimento são para propagar a correção de um defeito se tiver sido o caso o procedimento define que a mesclagem é passada de um ramo de Manutenção a outro até chegar ao ramo principal e o fluxo de trabalho Fica dessa forma então depois que você se acostumar com esses novos Passos Você pode passar para uma versão totalmente

resumida que mostra apenas o procedimento Em um nível mais alto de abstração só com chamada funções eu vou deixar em anexo essa aula tanto a versão resumida quanto a completa do fluxo para você imprimir e usar no dia a dia e mais uma vez é muito Importante que você sempre Siga essa procedimento e não só você todos da equipe e ficamos por aqui então até a próxima [Música] aula Olá nessa aula vamos ver como funcionam variações de projeto no subversion através de um exemplo que segue o padrão de comportamento de Ramos principal e dedicado o

roteiro do exemplo é o seguinte teremos três desenvolvedores Fulano beltrano e cicrano Fulano vai trabalhar no ramo principal e beltrano e cicrano em Ramos dedicados lembre-se que geralmente uma parte da equipe que trabalha em cada ramo dedicado Mas vamos manter uma pessoa só para simplificar no evento um beltrano cria o ramo dedicado de nome em módulo X no evento dois Fulano edita um arquivo no ramo principal enquanto beltrano cria um arquivo no ramo módulo X no evento TR beltrano faz uma mesclagem de Atualização vinda do ramo principal no evento 4 cicrano cria um novo ramo

de nome subsistema Y no evento 5 cicrano cria um novo arquivo no evento se Fulano biotran Edit o mesmo arquivo cada um no seu ramo preparando um conflito que acontecerá na mesclagem de atualização do evento 7 no evento o beltrano faz uma alteração em nove acontece a mesclagem de Reintegração em que todas as alterações do ramo módulo x são incorporadas no ramo principal como a Implementação do módulo x está concluída o ramo dedicado não é mais necessário e pode ser excluído é o que acontece em 10 e no evento 11 h a mesclagem de atualização

do ramo subsistema Y esse diagrama mostra uma representação gráfica dos eventos e dos Ramos no controle de versão distribuído os Ramos seriam representados naturalmente por linhas Independentes no grafo acíclico direcionado porém o histórico do subversion é linear e por isso não é Capaz de registrar automaticamente os Samos do projeto a ramificação precisa ser feita de outra forma e a escolhida foi através de diretórios no repositório essa foi uma decisão de implementação do subversion logo no começo do projeto a convenção usada é dividir a raiz do repositório em três diretórios Trunk brands e tags o diretório

Trunk é o rama principal os subdiretórios dentro de brands serão os Ramos secundários e os Subdiretórios de tags representarão etiquetas etiquetas e Ramos São criados a partir de cópias de diretórios usando o comando svn copy Vamos ver isso na demonstração daqui a pouco a versão 1.0b Por exemplo quando R principal chega na versão Beta copiando Trunk para subet 1.0b em tags eet são diretos comuns mas convenção queis você eob queis de uma pequena correção Então Vai precisar lançar uma nova etiqueta ao invés de alterar a etiqueta existente o ramo 1x é criado copiando Trunk para

o subdiretório 1. em brins as etiquetas 1.0 a 1.2 são criados copiando 1 PX para dentro de tags e assim por diante internamente o subversion usa link sempre que possível para evitar duplicação de dados portanto independente do tamanho do ramo sendo criado o tempo e o espaço ocupado são pequenos e Constantes saber como funciona internamente até que interessante mas o único detalhe de implementação que você realmente precisa saber é que para criar um ramo ou uma etiqueta tem que copiar um diretório para outro lugar apropriado nas próximas aulas você verá demonstrações de como implementar o

exemplo apresentado usando linha de comando e o tortu svn como interface gráfica Eu recomendo que você veja e refaça as duas demonstrações até mais [Música] Olá nessa aula vou demonstrar como lidar com Ramos dedicados no subversion usando a linha de comando e o roteiro que foi apresentado na aula anterior então vamos comear o servidor já está configurado e rodando e cada desenvolvedor tem sua própria cópia de trabalho com alguns arquivos já criados no evento um belan cria o ramo dedicado de nome em módulo X mas antes é importante atualizar a cópia de trabalho para partir

da revisão mais Recente o comando svn info mostra que a cópia de trabalho está posicionada atualmente em Trunk o comando sncp circumflex bar Trunk circumflex bar brants bar mulo x copia o diretório Trunk para o subdiretório módulo x dentro de brants note que os diretórios referenciados no comando do exemplo usam caminhos relativos representados pelo assento circunflexo isso significa que o comando é executado diretamente no repositório sem passar por uma cópia de Trabalho e gera uma revisão como resultado no mundo real o servidor provavelmente estará configurado para só aceitar consolidações associadas a tickets então é necessário

passar uma mensagem de log e a mensagem padrão referenciando o ticket associado o próximo passo é providenciar uma cópia de trabalho posicionada nesse ramo uma opção é criar uma nova cópia de trabalho com com comando sven checkout a segunda opção é reposicionar a cópia de Trabalho atual usando o comando sven Switch que troca o ramo corrente pelo ramo especificado como parâmetro no evento dois Fulano biotran farão edições concorrentes mas em Ramos distintos Fulano vai editar o arquivo letras pxt e biotran vai criar um novo arquivo para o módulo x a consolidação de ambos ocorre sem

problemas no evento três beltrano executa mesclagem de atualização periódica vinda do um ramo Principal o comando para mesclagem US svn merge e o parâmetro é o ramo de origem o ramo de destino sempre é aquele em que a cópia de trabalho está posicionada no caso é o ramo módulo x a mesclagem ocorreu sem conflitos nesse caso agora é hora de construir e testar tal como deve ser feito em antes de cada consolidação só tô destacando isso agora porque estamos vendo uma nova operação mas isso está registrado no procedimento recomendado que você deve seguir sempre Passando

a construção e testes vamos consolidar a mesclagem a mensagem de consolidação desse svn comit é diferente porque não está está associada a nenhum ticket como apenas as alterações de um ramo foram repassadas a outro e nenhuma nova implementação foi feita basta usar a palavra merge para descrever a revisão o comando svn log com a opção menos menos limit 1 mostra apenas a última revisão e com a opção menos menos dif mostra o Change Set a propriedade svn merge info guarda o histório das mesclagem no momento ela indica que o ramo principal foi mesclado e o

intervalo usado foi das revisões 5 a 7 vamos passar para evento quatro é a vez de cicrano que vai criar mais um ramo dedicado com o nome subsistema y o comando para isso é o mesmo que vimos antes svn cop ramo de origem que é o Trunk e o ramo de destino que é o brins bar subsistema y e a mensagem de consolidação referenciando um Ticket depois o comando sven Switch para reposicionar a cópia de trabalho em outro URL do mesmo repositório no evento 5 cicrano cria um novo arquivo que representa a parte da implementação

da funcionalidade Y no evento se fulano e beltrano farão uma edição concorrente no mesmo arquivo números pxt mas cada um no seu ramo por isso a consolidação de cada um ocorre normalmente O conflito aparece agora no evento 7ete quando Beltran vai fazer uma nova mesclagem de atualização periódica não há mais nada de novo sobre resolução de conflitos A única diferença é que os nomes dos arquivos envolvidos no conflito são um pouco diferentes mas a chamada do cadif 3 serue mesma ordem o arquivo com extensão com número de revisão menor que é o R7 e representa

o ancestral comum mais próximo o arquivo local que no caso tem extensão pon Working o arquivo de revisão maior que é o R12 e o arquivo de saída com a mesclagem que é números P TXT vou pular a edição do conflito no cadif 3 e continuar é necessário indicar que o conflito foi resolvido com o comando svn resolved depois construir testar e por fim consolidar usando merge como mensagem de consolidação no evento oito beltrano faz uma alteração em nove acontece a mesclagem De Reintegração em que todas as alterações do ramo módulo x são incorporadas no

ramo principal como o ramo de destino é Trunk biotran precisa executar o svn Switch circumflex bar Trunk para mudar o posicionamento da cópia de trabalho Note que a configuração da cópia de trabalho é transformada para ficar igual ao do ramo de destino Depois executo comando sven merge circumflex bar brins bar mulo X Para fazer a mesclagem de Reintegração constrói testa e consolida como a implementação do módulo x está concluida o ramo dedicado não é mais necessáo e pode excluo é o que acontece em 10 botran vai apagar o diretório com comando sbnm passando no caminho

relativo o que gera uma nova revisão e portanto precisa de um ticket associado biotran executa o comando sven list para mostrar o conteúdo do diretório brands Só aparece agora o diretório subsistema Y no último evento sran vai fazer uma mesclagem de atualização periódica depois o desenvolvimento da funcionalidade Y continua e a demonstração termina aqui na próxima aula veremos essa mesma demonstração pelo tortas svn até [Música] lá nessa aula vou demonstrar como lidar com Ramos dedicados no subversion usando tortu svn o roteiro da demonstração foi Apresentado na aula anterior mas Haverá uma m ao invés de

três usuários Vamos trabalhar apenas com Fulano beltrano as cópias de trabalho de fulano belano já estão criadas e apontados Trunk noan criou R dedicado de nome módulo x isso é feito através do menu de contexto tortu svn BR tag aí abre essa janela Vas opões É bom lembrar aquele princípio de interface gráfica no controle de versão não sabe Não mexe mexa só nos campos e opções que você tem certeza para que servem no campo to paath altere barra Trunk para o ramo que será criado que é barra Brains bar módulo x sem acento evite ao

máximo usar acento espaço ou maiúsculas em nomes de arquivos e diretórios isso evitará Problema se você tiver parte da equipe trabalhando em sistemas operacionais diferentes em seguida preenche a mensagem de log ela é obrigatória porque Essa operação gera uma nova revisão repositório se o controle de mudança e o repositório estiverem configurados corretamente eles exigirão essa mensagem de consolidação a um ticket associado uma sessão com opções importantes mas que você não deve mexer é a que especifica o número de revisão que serve de referência para criação do ramo Mantenha sempre a opção que determina a revisão

específica para garantir que a revisão que foi planejada é que Realmente será usada na criação do ramo uma opção que você pode marcar é a última caixa que onde está escrito Switch working copy to New Branch tag desse modo a operação cria o ramo e já posiciona a cópia de trabalho em um passo só mas vamos fazer isso separadamente para mostrar esse segundo passo e agora é só clicar em Ok para criar o ramo a caixa de aviso informa que a cópia de trabalho permanece no ramo anterior falta reposicionar a cópia De trabalho no novo

ramo Clique na raiz da cópia de trabalho com o botão secundário do mouse e Escolhe a opção toas svn Switch antes de continuar outro aviso sempre escolha a raiz da cópia de trabalho para executar operações tais como commit update merge e Switch caso contrário você corre o risco de modificar apenas parte da cópia de trabalho na janela que abre no campo to path escreva o caminho de destino que é Barraband bar módulo x ignora todos os outros Campos e opções Basta apenas clicar em Ok a cópia de trabalho agora está em outro ramo isso pode

ser confirmado pela opção propriedades no menu de contexto Note que nesse caso não é tortu svn propriedades e sim propriedades e acesse a aba do subversion você pode notar na URL que o caminho é oo ramo módulo x e isso encerra o evento um no evento dois Fulano editará um Arquivo no principal enquanto Beltran criará um arquivo no ramo módulo x Fulano atualiza sua cópia de trabalho antes de começar depois altera as letras a e b para maiúsculo ao mesmo tempo Beltran cria uma nova passa pro módulo x adiciona a Passa ao controle de versão

e depois cria um arquivo e também adiciona fulão consolida e depois Beltran no evento três Beltran fará uma Mesclagem de atualização vinda do ramo principal na raiz da cópia de trabalho aciona o menu de contexto Escolhe a opção tortas svn merge há duas opções de mesclagem vamos usar sempre a primeira opção a segunda opção é para casos muito específicos que você provavelmente nunca vai encontrar se trabalhar corretamente com controle de versão e mais uma interface com várias opções a única informação que você Precisa alterar é o caminho do ramo de origem da mesclagem que deve

ser barra Trunk Não mexa em mais nada e clique em next A Próxima janela tem ainda mais opções e mais uma vez você não deve mexerem nada apenas clique em test merge para simular o resultado da mesclagem o uma mesclagem bem-sucedida deve ter essa cara em alguns casos pode aparecer conflitos e isso será normal mas qualquer coisa fora desse padrão é sinal de que você está fazendo a mesclagem Errada se isso acontecer Verifique o ramo de origem da mesclagem e se você está fazendo a mesclagem a partir da raiz da cópia de trabalho a simulação

da mesclagem está correta então vamos fazer a mesclagem para valer clicando em merge lembre-se que o objetivo da mesclagem é apenas trazer as modificações de um ramo a outro não inclua nenhuma outra alteração que não seja resolução de Conflito após fazer a mesclagem ainda é necessário consolidar a mesclagem de log pode ser apenas merge porque não há um ticket relacionado para isso Note que a raiz do diretório da cópia de trabalho relativa ao ramo módulo x consta como alterado isso é o resultado da mesclagem que é registrada na propriedade svn merge info que armazena os

caminhos e revisões já usados nas mesagens essa forma de registrar mesclagem é uma particularidade do subversion não é Ideal mas funciona no exemplo está sendo registrado que a mesclagem contém um intervalo entre as revisões 3 a 5 de Trunk você não precisa se preocupar com isso e nem deve mexer manualmente nessa propriedade Apenas ignore biotran Então consolida mas recebe a mensagem que a cópia de trabalho está desatualizada então é necessário atualizar e fazer o commit novamente no evento 4 Fulano criará um novo ramo de nome subsistema Y a cópia de trabalho de fulano está posicionada

no Trunk para criar o ramo Fulano aciona o menu de contexto escolhe tortu svn Brain tag preenche o caminho com barra Brains bar subsistema Y preenche a mensagem de consolidação e consolida um parênteses aqui faltou atualizar a cópia de trabalho de fulano antes de criar o ramo não vai mudar o resultado porque não aconteceu nada no Trunk desde a última alteração de fulano mas faz parte do procedimento recomendado e esse passo deve ser seguido E para finalizar o evento Fulano usa o tortu sv sutch para reposicionar a cópia de trabalho no ramo subsistema Y no

evento 5 Fulano criará um novo arquivo para o subsistema y primeiro cria a pasta e o arquivo dentro da pasta depois adici na pasta e o arquivo vai Junto e para finalizar a consolidação no evento se Fulano e biotran editaram o mesmo arquivo cada um no seu ramo preparando o conflito que acontecerá na mesclagem de atualização no evento s a cópia de trabalho de fulano precisa voltar para Trunk então ele usa um tortu svn suit para isso em seguida Fulano muda os números dois e qu para seu valor extenso e Consolida beltrano atualiza sua cópia

de trabalho altera os números quatro e se para inglês e consolida não há conflito ainda porque as alterações aconteceram em Ramos diferentes o conflito vai acontecer agora no evento sete Quando houver a mesclagem de atualização vinda do ramo principal biotran seleciona o toas sven merge e escolha a primeira opção o ramo de origem é Trunk Então Está certo e clique em next a próxima ação é simular a mesclagem através do test merge a janela informa que é provável que haja um conflito mas não há como prever o que realmente vai acontecer como eu disse antes

conflitos nessa situação são normais porque os S evoluíram por caminhos diferentes e agora precisam ser combinados a simulação da mesclagem serve para verificar se não há resultados inesperados que não sejam Mesclagem sem ou com conflitos e agora mesclagem para valer E aí o conflito aparece Apesar desse monte de opções eu aconselho você escolher a primeira ou a última opção a primeira opção deixa a resolução do conflito para depois e a última é dito conflito agora as opções intermediárias não devem ser escolhidas porque não dá para tomar nenhuma decisão agora sem analisar o conflito vou escolher

a primeira opção e postar a resolução do conflito os arquivos Auxiliares e o de conflito aparecem na cópia de trabalho já vimos como resolver conflitos em outra aula anterior e é o mesmo procedimento clique sobre o arquivo e no menu de contexto escolha a opção tortu VN resolve se não aparecer a opção para editar o conflito na outra janela que aparece você escolhe o arquivo e novamente pelo menu de contexto escolhe editar os Conflitos a resolução vai ser por 04 na linha em conflito e depois disso marcar como resolvido e consolidar usando merge como mensagem

de consolidação o comite falhou porque a cópia de trabalho não está atualizada vamos atualizar então e refazer a consolidação da mesclagem no evento 8 biotran faz uma última alteração no ramo módulo X no caso vai mudar o nome do arquivo e Consolida no evento nve acontecerá a mesclagem de Reintegração em que todas as alterações do ramo módulo x serão incorporadas ao ramo principal o alvo da mesclagem é Trunk por isso a trabalho deve estar posicionada lá biotran usa tortu fvn sut para fazer o reposicionamento e agora mesclagem escolha Toto sv merge selecione o primeiro tipo

preenche o ramo de origem da Mesclagem que é barra BRS bar mulo x next e test merge a janela informa que poderá haver um conflito mas não é possível confirmar e o merge para valer para finalizar é necessário consolidar a mesclagem a mensagem de consolidação é apenas merge como a implementação do módulo x está concluída o ramo dedicado não é mais necessário e pode ser excluído é o que acontecerá no evento 10 uma forma de apagar o ramo pelo tortu svn é pelo repo browser que se parece com Explorer do Windows mas para o repositório

selecione o caminho bar brands bar módulo x e através do menu de contexto escolha a opção delete essa é uma operação que exige uma mensagem de consolidação e deve ter um ticket associado e o ramo Foi removido e no evento 11 há uma mesclagem de atualização do ramo subsistema Y Fulano tá tratando disso mas sua CPA de trabalho ainda está em Trunk é precisam antes então reposicionar usando tortu VN Suit depois Executar a mesclagem usando o ramo barra Trunk como origem e consolida e a demonstração termina aqui na próxima aula veremos a demonstração do funcionamento

de Ramos de manutenção e etiquetas no subversion até lá [Música] Nessa aula Vamos fazer uma demonstração de como trabalhar com etiquetas Ramos de manutenção e propagação de correções no subversion usando a linha de comando não há nenhum novo comando para aprender como já vimos antes criação de Ramos ou etiquetas no subversion São cópias de diretórios que você cria usando svn copy pela linha de comando ou usando totois svn Branch tag no Windows propagação de alterações entre um Ram e outro é feita através de mesclagem usando svn merge ou Tortu VN merge nada de novo aqui

o que tem de diferente é que agora vamos simular um projeto com dois ramos de manutenção para mostrar todo o processo de criação de etiquetas de Ramos de manutenção e a propagação de correções o roteiro é o seguinte o servidor já tá configurado e rodando e cada desenvolvedor tem sua própria cópia de trabalho com alguns arquivos já criados logo de cara vamos começar criando uma etiqueta para marcar a revisão 1.0 a Depois haverá algumas consolid ações e o projeto passa para o estágio Beta a etiqueta 1.0b e o ramo de manutenção 1.xx não no ramo

1 p x que deverá ser repassada ao ramo principal por mesclagem depois mais revisões do ramo principal e o projeto chega ao estágio 2.0 Alfa uma nova etiqueta criada e depois mais revisões o projeto chega ao estágio 2.0 Beta e uma etiqueta e um novo ramo de manutenção são criados em seguida há uma correção em 2. x que é Repassado ao ramo principal e por último haverá uma correção no ramo 1.xx e principal em paralelo acontecerá o lançamento da versão 1.0 Vamos então começar a demonstração pelo terminal Fulano cria etiqueta para registrar a fase 1.0

Alfa enquanto Beltran continua implementando novas funcionalidades a criação da etiqueta é feita copiando o diretório Trunk na revisão 3 indicado pelo @3k para o diretório tags bar 1.0 a se Fulano não tivesse especificado a revisão a etiqueta usaria a revisão 4 que é a mais recente do repositório e não a revisão três que havia sido planejada porque Beltran criou uma revisão logo antes fixar a revisão na criação de etiquetas e Ramos de manutenção é importante para garantir que a revisão certa será usada em seguida biotran faz mais uma alteração no projeto Fulano então cria etiqueta

1.0b e o ramo 1x enquanto isso botran continua trabalhando no ramo principal Fulano Verifica que a revisão atual é se E cria tanto a etiqueta quanto o ramo a partir de Trunk nessa revisão nesse meio tempo botran faz outra implementação no ramo principal que fará parte da versão do que ainda será lançada agora é necessário fazer uma correção no ramo 1. X ao invés de usar o sv Switch para trocar o ramo da cópia de trabalho fulan vai criar uma nova cópia de trabalho para o ramo 1x e a correção é feita nessa nova cópia

de trabalho depois Fulano volta a cópia de trabalho de Trunk e faz a mesclagem vinda do ramo 1x e consolida com a mensagem merge biotran faz outra consolidação e o projeto chega ao estágio 2.0 Alfa e Fulano cria a etiqueta 2.0 A sempre referenciando uma revisão específica mais uma consolidação de beltrano e agora chegamos ao está 2.0 Beta biotran vai criar a etiqueta correspondente e o ramo 2x Fulano enquanto isso continua trabalhando em uma nova funcionalidade que fará parte da versão 3 que ainda será lançada agora há um defeito encontrado na versão 2 que deve

ser corrigido no ramo 2x e repassado a ramo Principal quem vai fazer essa correção é Fulano ao invés de criar nova cópia de tralho fulano vai apenas fazer um sv suit para o ramo 2x consertar voltar a cópia de trabalho para Trunk e fazer o merge o Ram 1x não é alterado porque é de uma versão anterior que não contém a funcionalidade nem o defeito nessa última sequência de eventos Beltran fará uma correção no ramo 1x e depois vai repassar essa Correção até chegar ao ramo principal enquanto isso Fulano vai criar a etiqueta para versão

1.0 usará só uma cópia de trabalho que será reposicionada através de comos sv Switch até chegar ao ramo principal important tomar cuidado para não usar cópia de trabal AP para lugar errado e assim termina a demonstração de variações de projeto Y [Música]