CVS - Slides Parte 4 - Avançado

629 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
629
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Este módulo final terá como foco o gestor de configuração e o gestor de projeto. Falaremos sobre tópicos avançados envolvendo o CVS e a disciplina de gestão de configuração em geral. A maioria dos temas abordados nesta parte do treinamento diz respeito ao gerenciamento do projeto, enquanto que o módulo de administração se preocupava mais com o repositório e o módulo básico, com arquivos e diretórios. Veremos como utilizar etiquetas para marcar liberações do projeto, como e por que criar e trabalhar em ramos diferentes. Também aprenderemos como e quando realizar mesclas de um ramo para outro. Conheceremos o comando para exportação de projetos e o comando que permite a realização de tarefas avançadas sobre os históricos. Aprenderemos técnicas de acompanhamento da atividade em projetos, observando arquivos e inspecionando o histórico de operações sobre o repositório.
  • Este slide mostra nossa agenda para este módulo do treinamento, voltado para funções avançadas do CVS e atividades de responsabilidade dos gestores (de configuração e de projeto).
  • Dificilmente será necessário conhecer o formato interno dos arquivos de controle da área de trabalho, a não ser que se queira implementar uma ferramenta de auxílio ao CVS, tal como um cliente gráfico. Mas é interessante ao menos inspecioná-los e saber que funções cada um desempenha. Este slide lista os principais arquivos da área de trabalho. O CVS guarda um conjunto de arquivos de controle para cada diretório na cópia local. Eles ficam armazenados no subdiretório chamado CVS. Como vimos ao estudar o comando add , um diretório local não é considerado visível pelo CVS até que contenha esse subdiretório. O arquivo Root contém a string de especificação do repositório, isto é, a localização da raiz da forma como ela é especificada para a opção global –d ou para a variável $CVSROOT . Uma situação em que seria interessante editá-lo diretamente é para trocar o repositório em uso, sem a necessidade de faz um novo check-out. Mas, em geral, é mais seguro optar pelo novo check-out. O arquivo Repository indica o caminho no repositório ao qual o diretório da cópia local corresponde. Ele acelera a execução de comandos locais, pois permite que o cliente CVS encontre diretamente o diretório correspondente no servidor. Talvez o arquivo mais importante da área de trabalho seja Entries , que lista todos os arquivos e subdiretórios dentro do diretório de trabalho. Cada linha de Entries tem o seguinte formato: / nome / revisão / timestamp [+ conflito ]/ opções / etiq-data Ela indica o nome do arquivo, a revisão que foi obtida na última atualização, a data ( timestamp ) dessa última atualização, se houve ou não um conflito na última atualização (os colchetes indicam que essa parte é opcional), eventuais opções aderentes em vigor e seus valores (dados por etiq-data ). Outro arquivo de controle é Tag , que registra etiquetas e datas aderentes especificadas ao diretório como um todo.
  • Os comandos checkout e update permitem que qualquer revisão de qualquer arquivo seja obtida do repositório. A opção que especifica revisões é –r . Vimos que isso pode ser útil, por exemplo, para se reverter uma alteração incorreta em um arquivo. Por outro lado, também vimos na introdução do curso que é muito mais útil obter do repositório revisões que, juntas, formem um conjunto coeso (que compile, teste e atenda os requisitos de um projeto). O conceito de liberação representa um conjunto de revisões com essa característica. Etiquetas são o mecanismo usado para marcar revisões de arquivos de um projeto, definindo liberações. Portanto, o cenário mais comum é aplicar uma etiqueta sobre uma revisão de cada arquivo de um projeto. Eventualmente, também é útil marcar revisões de arquivos individuais, para se identificá-las com um nome mais significativo. Veremos a partir de agora como lidar com etiquetas no CVS.
  • Esta ilustração mostra como seria uma liberação antes de sua marcação: as revisões coerentes encontram-se espalhadas nos históricos dos arquivos, desorganizadas.
  • Esta ilustração, já vista no módulo inicial, mostra a marcação de uma liberação: as revisões coerentes foram “alinhadas” e marcadas com a etiqueta “2.1 Final”. Imagine que a etiqueta define uma “linha virtual” amarrando as revisões e, ao obter as revisões especificando a etiqueta, estamos puxando a linha a deixando reta.
  • Como vimos na intriodução, dado um arquivo sob controle do CVS e uma área de trabalho, o CVS oferece duas etiquetas “virtuais” para esse arquivo. A etiqueta BASE marca a revisão base ( base revision ) do arquivo, aquela na qual a cópia na área de trabalho é baseada, isto é a revisão obtida pela última sincronização com o repositório. A etiqueta HEAD marca a revisão cabeça ( head revision ), a última revisão do arquivo na linha de código usada pela área de trabalho, que pode ou não estar sincronizada com a cópia local. Esses nomes de etiqueta são reservados pelo CVS e não podem ser aplicados por usuários. As etiquetas BASE e HEAD podem ser usadas em qualquer opção que espera um número de revisão ou um nome de uma etiqueta, como a opção –r dos comandos checkout e update .
  • Os comandos tag e rtag são oferecidos pelo CVS para se gerenciar etiquetas em um projeto. O comando tag trabalha sobre uma cópia local, etiquetando as revisões presentes na cópia, isto é, aquelas identificadas pela etiqueta virtual BASE . O formato e as opções de tag são mostrados neste slide. Como argumentos, tag recebe em primeiro lugar o nome da etiqueta e, em seguida, zero ou mais nomes de arquivos e diretórios sobre os quais a etiqueta será aplicada. O comportamento recursivo funciona por default. Dentre as opções reconhecidas por tag , estão as opções normais de especificação de revisões –D data , -r revisão e –f . Além destas, -b faz com que a etiqueta criada seja um ramo, -c não permite que a etiqueta seja aplicada se algum arquivo local estiver modificado, -F move a etiqueta se ela já existe em outra revisão de um arquivo especificado (o default é retornar um erro nesse caso) e –d apaga a etiqueta dos arquivos especificados. Já rtag tem praticamente as mesmas opções e o mesmo comportamento, com a diferença que atua diretamente no repositório, não demandando uma cópia local e, por isso, marca as últimas revisões no repositório (dadas pela etiqueta virtual HEAD ). Há mais uma pequena diferença entre tag e rtag . O comando tag dispara a execução dos comandos especificados no arquivo administrativo taginfo , mas não do programa especificado pela opção –t no arquivo modules . Já rtag dispara ambas execuções.
  • A primeira regra para nomear etiquetas é usar nomes simples, claros e significativos, que permitam no futuro lembrar para que foi criada a etiqueta. É interessante também adotar uma convenção de nomes de etiquetas dentro de um projeto ou de uma organização. O CVS por si já impõe algumas restrições, como mostrado neste slide. Uma convenção sugerida é usar letras maiúsculas em nomes de etiquetas normais (para etiquetas que definem ramos, a sugestão é usar minúsculas, como visto adiante). Os separadores de palavras e dígitos é o hífen, enquanto que o sublinhado substitui o ponto, rejeitado pelo CVS em nomes de etiquetas. É ainda comum usar indicadores da qualidade da liberação no nome da etiqueta. Por exemplo, CVS-1_12_14-BETA , PLACES-1_0-FINAL .
  • Uma pergunta quase tão freqüente quanto “Quando fazer check-ins?” é “Quando aplicar etiquetas?” A resposta mais fácil é: “Depende”. Realmente, as regras mais detalhadas de aplicação de etiquetas dependem da política de gestão de configuração do projeto e da empresa. Como regra geral, pode-se dizer que uma etiqueta deve ser aplicada a cada estágio importante do projeto. No mínimo, cada liberação deve ser marcada. Outras situações onde é recomendável aplicar etiquetas são listadas no slide. Destaco a sugestão de aplicar uma etiqueta antes de remover uma funcionalidade ou voltar atrás com uma grande alteração. Também é uma excelente idéia aplicar uma etiqueta antes de se fazer uma mescla propagando as alterações feitas em um ramo.
  • Este lab exercita o gerenciamento de etiquetas, o mecanismo que o CVS oferece para a marcação de liberações. Veja os materiais do aluno para instruções.
  • Os conceitos de ramo e linha de código já são conhecidos. Um ramo é uma derivação da linha de código principal de um projeto, o chamado tronco. Ramos são usados para permitir que alterações possam ser armazenadas no repositório sem afetar a linha principal. Para o CVS, um ramo é uma etiqueta especial. Portanto, todas as observações feitas para etiquetas aplicam-se a ramos. O detalhe é que as revisões marcadas pela etiqueta passarão a ser o marco zero para o ramo e são chamadas de “base” do ramo. As nova revisões criadas no ramo são derivadas da base e, inclusive a numeração das revisões é formada sobre o número da base, como veremos logo adiante. Como foi citado nas boas práticas de etiquetas, é conveniente marcar as revisões-base de um ramo com uma etiqueta normal. Uma diferença interessante com relação a etiquetas de ramos (criadas com a opção –b ) é que, se fizermos o check-out de uma revisão especificando uma etiqueta normal com a opção –r , não é possível realizar check-ins, pois a revisão está “travada”. Porém, uma etiqueta criada com –b é diferente. Se submetemos uma alteração sobre um arquivo obtido com uma etiqueta desse tipo, uma nova revisão é criada no repositório, sob o ramo representado por essa etiqueta. Para facilitar a diferenciação de ramos para etiquetas, adotamos uma convenção: nomes de ramos usam letras minúsculas. As demais convenções são as mesmas adotadas para etiquetas. Por fim, assim como ocorre com etiquetas normais, é possível criar um ramo sobre apenas alguns arquivos de um módulo, mas isso não é recomendado, pois cria dificuldades ao se utilizar o ramo e controlar propagações.
  • Este slide mostra como ramos podem ser criados a partir do tronco. A figura usa a numeração de ramos do CVS. Os círculos denotam revisões de um arquivo, enquanto que os retângulos são ramos. O tronco é formado pelas revisões com dois números (1.1, 1.2, 1.3, etc.) Os ramos 1.2.2 e 1.2.4 são baseados na revisão 1.2. Isso quer dizer que as revisões desses ramos são derivações da revisão 1.2. Já o tronco 1.3.2 é baseado na revisão 1.3, o que significa que a revisão 1.3.2.1 é uma modificação de 1.3. A numeração dos ramos é sempre formada pela revisão na qual o ramo é baseada, seguida de um número par. Esse número começa em 2, no primeiro ramo criado sobre uma revisão, depois passa para 4, 6, etc. tantos quantos forem os ramos criados sobre a revisão. Observe também que, assim como números de revisão, números de ramos são controles internos do CVS. Cada arquivo tem o seu e, portanto, não são úteis para nós os guardarmos. Como ramos são criados como etiquetas, é do nome da etiqueta que precisamos nos lembrar.
  • Um ramo é a estrutura usada por sistema de controle de versões para implementar uma linha de código distinta. Pela definição de área de trabalho, sabemos que cada área aponta para uma e somente uma linha de código. Portanto, cada área de trabalho está associada a um ramo. Até agora, vimos somente áreas de trabalho associadas com o tronco. Mas é possível fazer o check-out de um ramo diferente do tronco, usando a opção –r para checkout e update . O parâmetro para a opção –r é o nome da etiqueta especial criada para representar o ramo. Como é de se esperar, a opção é aderente, de forma que futuras execuções de comandos sobre a cópia local respeitarão o uso do ramo. Por exemplo, futuros update s olharão somente para revisões no ramo (a não ser que as opções aderentes sejam “limpas” com –A ). A diferença de ramos para outras opções aderentes é que ramos permitem check-ins, pelo comando commit . As novas revisões são criadas dentro do ramo usado. É possível também adicionar ou remover arquivos quando se trabalha em um ramo. Essas operações, como é de se esperar, não afetam o tronco.
  • É possível trabalhar normalmente nas linhas de código distintas, mas por vezes é preciso mesclar alterações feitas em duas linhas distintas. Por exemplo, uma correção de defeito pode ser feita em um ramo criado para uma nova liberação, e é preciso propagá-la para o tronco principal, para que ela fique disponível na liberação atual do produto. Outro caso é quando a nova liberação for finalizada; as modificações devem ser propagadas para o tronco. É importante identificar a direção da mescla: há sempre um ramo origem e um ramo destino. O ramo origem contém as alterações a serem propagadas e ficará inalterado. O ramo destino será modificado, recebendo as alterações. O comando update é usado para mesclas entre ramos, com a opção –j . Veremos o funcionamento dessa opção adiante. Algumas boas práticas relacionadas a mesclas de ramos: uma etiqueta deve ser aplicada sobre o ramo destino antes da mescla. Já o ramo origem pode ser abandonado após a mescla, mas, para preservar o histórico do projeto, não se removem troncos abandonados.
  • A opção –j do comando update realiza a junção de revisões quaisquer: já vimos ela sendo usada para reverter alterações na cópia local. Mas o seu uso mais comum é para mesclar ramos inteiros. Em qualquer caso, é interessante usar a opção –k k , para fazer com que as palavras-chave não expandam para seus valores (mantenham somente o nome da palavra-chave). Este slide procura explicar o que é uma mescla e como a opção –j funciona.
  • Este slide mostra o funcionamento de uma mescla tendo um ramo como origem e o tronco como destino. Este é o cenário mais comum de mescla.
  • Este slide mostra o funcionamento de uma mescla do tronco para um ramo. Este cenário acontece com freqüência quando se usa o modelo de promoção de linhas.
  • Este slide mostra o procedimento para se mesclar um ramo com outro ramo.
  • Há duas formas principais de trabalho com ramos. Uma delas é ter uma linha principal de código, na qual o tronco sempre evolui. Os ramos contém novas liberações e correções de defeitos, mas acabam propagando suas alterações para o tronco e se tornando obsoletos. A outra forma é chamada promoção de linhas, pois as linhas se sucedem na posição de quem é a principal. À medida que as liberações evoluem, elas não são propagadas para o tronco principal, mas o ramo se torna (é promovido) a linha principal. Os ramos usados para liberações anteriores (inclusive o tronco) tornam-se obsoletos.
  • Este slide lista algumas das regras sobre quando se deve usar ramos. Prefira sempre criar um ramo do que copiar arquivos para um novo diretório e fazer nele as alterações. Isso inviabiliza mesclas automáticas, dificulta o processo de compilação e deixa os programadores na dúvida sobre qual cópia utilizar. Cuidado também para não criar ramos de forma desnecessária. Tenha em mente que um ramo a mais significa trabalho a mais: use-o somente para lhe poupar dores de cabeça maiores.
  • Neste lab, treinaremos a criação e uso de ramos. Consulte o material do aluno para mais informações.
  • Pode ser preciso extrair revisões do CVS para distribuição. Por exemplo, a empresa que utiliza o CVS pode atuar como um fornecedor e deve enviar uma liberação para um cliente. (O CVS também dá suporte ao cliente, com a funcionalidade de ramos para fornecedores.) Enquanto os comandos checkout e update obtém revisões do repositório, eles na verdade são usados para criar áreas de trabalho, que têm o inconveniente dos subdiretórios CVS presentes nelas. O comando export é muito similar a checkout , pois obtém arquivos do repositório, mas não cria uma área de trabalho. O formato desse comando é mostrado no slide. Como export atua diretamente no repositório, a opção global –d raiz é usada para especificar a raiz do repositório. Dentre as opções de comando, as já conhecidas –D data , -r revisão e –k opção-k são as mais usadas. A opção-k normalmente usada com export é –kv , que exporta somente os valores das palavras-chave. A opção –P , tão útil com checkout , já é automaticamente ligada com export : diretórios vazios não são exportados. Como argumento, export recebe o nome de um ou mais módulos, para cada um, ele cria um diretório onde o comando foi chamado.
  • Neste lab, exportaremos uma liberação de um projeto. Consulte os materiais do aluno.
  • Como o próprio nome diz, o CVS foi criado para viabilizar o desenvolvimento concorrente de projetos, isto é, projetos com vários usuários envolvidos. Já vimos diversas capacidades que auxiliam esse comportamento, tais como mesclas automáticas, ramos, etc. O funcionamento básico por trás do comportamento do CVS é o modelo copia-modifica-mescla, no qual cada autor copia os arquivos do repositório e os modifica independentemente, sem exclusividade. Ao submeter suas modificações, ele pode enfrentar uma mescla, caso outro autor já tenha submetido suas próprias modificações. Algumas capacidades avançadas do CVS para auxiliar o uso concorrente são listadas neste slide. Uma das mais interessantes é a capacidade de funcionar com edição exclusiva de arquivos, seguindo o modelo trava-modifica-destrava. Também é possível divulgar operações relevantes a vários usuários, tais como check-ins em arquivos importantes ou aplicações de etiquetas sobre módulos. Existe também um comando que pode ser usado por gestores de projeto para acompanhar as atividades dos diversos autores sobre o repositório.
  • O modelo padrão de funcionamento do CVS é permitir que usuários alterem simultaneamente um mesmo arquivo. É possível também que usuários escolham ser avisados sobre quem está editando certos arquivos, para que eles possam se comunicar e evitar conflitos no momento do check-in. Isso é feito através do comando watch . Com a execução desse comando, o arquivo passa a ser observado por um ou mais usuários. Com isso, a capacidade de alteração simultânea do CVS é mantida, mas os usuários têm que explicitamente informar que irão editar um arquivo observado, através do comando edit . Os usuários observadores são notificados (por exemplo, por e-mail) sobre eventos relativos a arquivos observados.
  • Este slide explica a mecânica do processo de observação de arquivos no CVS. Após criar uma área de trabalho, um usuário pode marcar arquivos para sua observação, pelo comando watch . Este comando configura a observação de um ou mais arquivos. O comando watch deve sempre ser invocado com um sub-comando, que define a configuração a ser feita. São eles: on : Declara que os arquivos especificados serão observados. Como conseqüência, eles serão criados com permissão somente de leitura pelo comando checkout e os usuários terão que usar o comando edit para alterar qualquer um deles, logo, notificando os observadores do arquivo de que ele está sendo editado. Deve-se notar que quando um usuário ativa a observação em um arquivo ele não é automaticamente adicionado à lista de observadores daquele arquivo. Para isso, usa-se o sub-comando watch add . off : Realiza a configuração contrária a watch on . Declara que os arquivos não são mais observados. add : Adiciona o usuário que invoca o comando à lista de observadores dos arquivos especificados. Por default, o usuário será notificado quando alguém executa um dos comandos commit , edit ou unedit sobre o arquivo. remove : Realiza a configuração contrária a watch add . Remove o usuário que invoca o comando da lista de observadores dos arquivos especificados. Um arquivo observado é criado com permissão de somente leitura nas cópias de trabalho dos usuários. O comando edit é usado para editar um arquivo observado, deixando-o com permissão de escrita. Os observadores serão informados sobre esse evento. Ao realizar um commit , a edição é finalizada. Caso queira descartas as alterações, o usuários deve executar o comando unedit , que descarta as mudanças, avisa os demais que o arquivo está liberado e o devolve para somente leitura. Existem também os comandos editors , que lista os editores de um ou mais arquivos, e watchers , que lista os observadores de arquivos. Para que as notificações cheguem corretamente aos usuários, os arquivos administrativos notify e users devem ser configurados corretamente. Eles especificam que comandos usar para o envio das notificações e permitem que sejam associados endereços de e-mail aos usuários. Consulte um guia para aprender como usar esses arquivos.
  • Em algumas situações pode ser preciso modificar o modelo de funcionamento do CVS, para que ele deixe de ser o copia-modifica-mescla e passe a ser o trava-modifica-destrava. Por exemplo, com um projeto onde a maioria dos arquivos é binária (criada com alguma ferramenta especializada, como um CAD), a mescla não é possível. Portanto, nesses casos, pode ser preferível travar arquivos para edição. Com o auxílio de um script avulso, o CVS permite que esse modelo seja usado. Este slide explica como realizar essa configuração. O comando admin , usado com as opções –l e –u também envia notificações para usuários. Para isso funcionar corretamente, configure os arquivos notify e users , conforme comentado no último slide.
  • Também é possível auxiliar o desenvolvimento paralelo divulgando operações relevantes para os vários usuários. Além dos cenários envolvendo arquivos observados e travas já descritos, as operações mais importantes para divulgação são check-ins e aplicação de etiquetas (que indicam a marcação de liberações). Para divulgar check-ins, configura-se o arquivo administrativo loginfo (há também a opção –i em modules , que não é recomendada). Para a divulgação da aplicação de etiquetas, usa-se a opção –t no arquivo modules . Porém, o programa só é executado se a etiqueta for aplicada com o comando rtag . Para a marcação de liberações, é realmente mais recomendado usar rtag , pois isso evita que sejam marcadas revisões antigas que possam estar presentes em cópias locais.
  • O comando history exibe o histórico de atividade no repositório. O CVS pode registrar o uso dos comandos checkout , commit , rtag , update e release . Para isso, o arquivo administrativo history deve existir e estar disponível para escrita pelo usuário. O comando history somente funcionará se esse arquivo existir. É preciso destacar que o comando history se comporta de forma diferente da maioria dos comandos do CVS. Várias opções, como -f , -l , -n e -p , têm significados diferentes dos demais comandos. Ao contrário da maioria dos comandos, history precisa receber opções para produzir algum resultado útil. Os argumentos esperados por history não são nomes de arquivos existentes, mas sim nomes parciais, de forma que o comando se aplica a todos os arquivos que casam com os nomes parciais. Por fim, a saída de history não é intuitiva como a maioria dos outros comandos e demanda uma explicação mais detalhada. As opções do comando history podem ser separadas em dois categorias. A primeira categoria especifica que tipo de atividade será relatada no histórico. No máximo uma opção dessa categoria pode ser informada. Caso nenhuma opção seja informada, o default é -o , que produz um relatório de check-out. A segunda categoria de opções para history impõe restrições ao histórico considerado. Por exemplo, as opções –m e –D citadas no slide estão nessa categoria. Essas opções restringem a saída produzida pelo comando, limitando os registros listados no histórico. O formato de saída de history é complexo. Cada linha da saída tem o formato: x data usuário [ rev | [ tag_data ] ] [ arq ] módulo =[ dir_local ]= caminho A linha é iniciada por uma letra x que indica o tipo da operação. Em seguida vem a data e o usuário . Se a operação envolve uma revisão (check-out ou check-in), o número rev vem depois; senão, se uma etiqueta ou data, tag_data , está envolvida, ela é exibida entre colchetes “[” e “]”. Se a operação envolveu um arquivo específico, seu nome, arq , vem na seqüência, seguido pelo nome do módulo usado. Se o evento foi um check-out, o nome do diretório criado para armazenar a cópia local, dir_local , é exibido entre “=”. Ao final vem o nome do caminho sob o qual a cópia local foi criada (para repositórios remotos é exibida a string <remote> ).
  • O comando admin realiza diversas tarefas administrativas no repositório, a maioria relacionada à alteração dos arquivos de histórico. Assim como a maioria dos comandos CVS, admin tem comportamento recursivo, apesar das operações administrativas geralmente se aplicarem a apenas um ou poucos arquivos. Logo, deve-se tomar cuidado com admin e procurar sempre especificar diretamente os arquivos como argumento. Muitas das tarefas realizadas por admin são obsoletas e possuem hoje formas melhores de serem feitas. Outras não produzem mais efeito e são mantidas apenas por compatibilidade. Além das opções –l e –u , usadas com o modelo trava-modifica-destrava, as opções mais comuns são: – k opção-k , para redefinir o modo de substituição de palavras-chave de um arquivo, útil quando se esquece de usar –kb e se adiciona um arquivo binário como texto; – m rev : msg , para redefinir a mensagem de log da revisão rev de um arquivo, trocando-a por msg .
  • Antes de falar sobre ferramentas para o CVS, é bom deixar claro que “conhecer o CVS” significa saber seus fundamentos, entender seu comportamento e, antes de tudo, saber usar seus recursos para implementar um modelo efetivo de controle de versões. Espero que tenhamos adquirido esse conhecimento ao longo deste treinamento! Usar clientes gráficos não significa conhecer o CVS e não capacita a pessoa plenamente no uso do CVS. Por outro lado, conhecendo o CVS como conhecemos agora, usar tais ferramentas é trivial, pois entendemos os conceitos e as operações feitas por elas. Entretanto, não se pode negar que as ferramentas auxiliares são úteis para se executar algumas atividades de forma mais eficiente e podem auxiliar bastante ao evitar a necessidade de uso constante da linha de comando. O principal tipo de ferramenta para o CVS são os clientes gráficos, que facilitam o uso básico e avançado da ferramenta, oferecendo uma interface amigável. Algumas atividades de administração também são possíveis com esses clientes. Os clientes gráficos mais conhecidos são os desenvolvidos pelo projeto CVSGUI (cvsgui.sourceforge.net ou www.wincvs.org) e incluem o WinCVS (o carro-chefe do projeto, para Windows), o gCVS (Linux) e o MacCVS (Macintosh). Eles são open-source, têm interfaces similares e permitem a realização da grande maioria dos comandos. Em um cenário com usuários em diversas plataformas, essas 3 ferramentas são fortes candidatas. Existem clientes mutliplataforma, feitos na linguagem Java: jCVS (www.jcvs.org), open-source e SmartCVS (www.smartcvs.com), que disponibiliza uma versão gratuita e outra comercial. Para o Linux (e a plataforma UNIX em geral), existe o Cervisia (cervisia.sourceforge.net), cliente gráfico que permite a configuração dos repositórios mais utilizados, suporta boa parte dos comandos e oferece facilidades para o uso do comando edit. Outra ferramenta é o LinCVS (www.lincvs.org), que oferece uma visão consolidada de todas as áreas de trabalho do usuário. Ambos são escritos no toolkit gráfico Qt. Ainda no Linux existe o Pharmacy (pharmacy.sourceforge.net), que usa o ambiente gráfico Gnome. Ele exibe os repositórios em uma visão de árvore e possui um console que mostra os comandos executados. O tkCVS é um front-end para os comandos CVS, escrito em Tcl/Tk. É um cliente gráfico bastante antigo. Outro cliente para Windows que merece destaque é o TortoiseCVS. Ele se integra ao shell do Windows (o Windows Explorer) e disponibiliza comandos sobre arquivos e diretórios ao se clicar com o botão direito do mouse. Ele também exibe os arquivos sob controle do CVS com cores diferentes, facilitando a identificação de seu status. Para quem desenvolve na linguagem Java, os principais IDEs têm excelentes integrações nativas com o CVS: Eclipse, JBuilder e NetBeans funcionam como clientes CVS muito bem integrados e cheios de funcionalidades. Várias ferramentas existem para o acesso remoto e a replicação de dados: CVSUp (www.cvsup.org), Chora (www.horde.org/chora), CVSviaFTP (www.siber.org/cvs-via-ftp), CVSweb (www.freebsd.org/projects/cvsweb.html), jCVS Servlet (www.jcvs.org), e, um dos mais conhecidos clientes Web, ViewCVS (viewcvs.sourceforge.net). Alguns conversores para o CVS: rcs-to-cvs, sccs2rcs e pvcs2rcs (presentes no diretório contrib da distribuição do GNU CVS) e VSS2CVS (conversor do Visual SourceSafe, www.laine.org/cvs/vss2cvs).
  • Os próximos slides mostrarão boas práticas gerais para a disciplina de Gestão de Configuração de Software. Muitas delas foram mostradas ao longo do treinamento, aplicadas ao CVS. Este slide recorda algumas delas. Com as recomendações a seguir, fechamos este treinamento. Esperamos que elas ajudem a tornar o uso do CVS mais efetivo em sua empresa ou seu grupo de trabalho.
  • A área de trabalho é o local onde os autores editam arquivos, compilam os componentes de software, testam e depuram seus sistemas. As mudanças feitas em uma área de trabalho são propagadas para o repositório. Este slide lista as boas práticas com relação a áreas de trabalho.
  • Uma linha de código é a evolução dos arquivos de um projeto ou sistema. Um projeto pode contar com mais de uma linha de código, como já vimos. Este slide lista as melhores práticas para o uso e a gestão de linhas de código.
  • Ramos são variações de linhas de código. Este slide mostra algumas boas práticas para a criação e o uso de ramos. Cada ferramenta oferece a funcionalidade de ramos de uma forma diferente. Vimos que o CVS trata um ramo como uma etiqueta especial, à qual é possível submeter novas revisões. O sistema de controle de versões ClearCase, hoje da IBM, oferece um mecanismo um pouco diferente. Ramos são criados, mas não são marcados sobre os arquivos até que alguém faça um check-in sobre o ramo. Aí o ramo é marcado sobre a revisão-base da alteração e a nova revisão já é criada dentro do ramo. Com isso, o sistema emprega a prática “Postergue a criação de ramos”, o que ajuda a diminuir as distâncias entre revisões mescladas.
  • Mesclas são processos muitas vezes complicados, tanto que merecem um conjunto de boas práticas exclusivas. Este slide lista recomendações ao se propagar alterações entre ramos, executando mesclas.
  • A compilação, apesar de não fazer parte do controle de versões em si, está intimamente relacionada a ele. Este slide mostra algumas boas práticas para relacionar a compilação aos arquivos mantidos sob o controle de versões.
  • O processo de gestão de mudanças está dentro da disciplina de Gestão de Configuração de Software, muito relacionada ao controle de versões. Este slide lista boas práticas envolvendo gestão de mudanças e controle de versões.
  • Com isto terminamos nosso treinamento sobre CVS. Obrigado pela sua participação! Fique à vontade para usar esta apostila para sua consulta no futuro?
  • CVS - Slides Parte 4 - Avançado

    1. 1. Uso Avançado do CVS Módulo 4 Foco: Gestor de Configuração e Projeto
    2. 2. Agenda <ul><li>Os arquivos de controle da área de trabalho </li></ul><ul><li>Trabalhando com etiquetas </li></ul><ul><li>Utilizando ramos e múltiplas linhas de código </li></ul><ul><li>Exportando projetos </li></ul><ul><li>Recursos para projetos com vários usuários </li></ul><ul><li>Editando o repositório com o comando admin </li></ul><ul><li>Ferramentas de auxílio ao CVS </li></ul><ul><li>Boas práticas em Gestão de Configuração de Software </li></ul>
    3. 3. Os Arquivos de Controle da Área de Trabalho <ul><li>No módulo de administração vimos um pouco de como o CVS guarda informações no repositório </li></ul><ul><ul><li>Veremos agora o que o CVS armazena na cópia local </li></ul></ul><ul><li>Os arquivos de controle estão sob os diretórios CVS </li></ul><ul><ul><li>Eles são armazenados em formato texto, seguindo a convenção de fins-de-linha do sistema operacional cliente </li></ul></ul><ul><li>Os principais arquivos da área de trabalho são: </li></ul><ul><ul><li>Root : Contém a localização da raiz do repositório </li></ul></ul><ul><ul><li>Repository : Tem o caminho no repositório ao qual o diretório da cópia local corresponde </li></ul></ul><ul><ul><li>Entries : Lista arquivos e diretórios sob o diretório de trabalho </li></ul></ul><ul><ul><ul><li>Indica nome, revisão em uso, data da atualização, presença de conflitos e opções aderentes a arquivos (opção-k, etiqueta ou data) </li></ul></ul></ul><ul><ul><li>Tag : Registra etiquetas e datas aderentes ao diretório todo </li></ul></ul>
    4. 4. Gerenciando Etiquetas <ul><li>O CVS permite a obtenção de qualquer revisão de arquivos mantidos sob o controle de versões </li></ul><ul><ul><li>Vimos que é útil obter uma revisão específica de um arquivo, por exemplo, para se reverter uma alteração </li></ul></ul><ul><li>Porém, é muito mais útil recuperar as revisões de arquivos que, juntas, formam um conjunto coeso </li></ul><ul><ul><li>O conceito que representa um conjunto coerente de revisões dentro de um projeto é a liberação </li></ul></ul><ul><li>Etiquetas são usadas para marcar liberações </li></ul><ul><ul><li>Também são usadas para marcar revisões individuais </li></ul></ul><ul><ul><ul><li>Um nome é muito mais significativo que um número de revisão </li></ul></ul></ul>
    5. 5. Uma Liberação Antes da Etiqueta
    6. 6. A Liberação Após a Etiqueta
    7. 7. As Etiquetas Virtuais BASE e HEAD <ul><li>O CVS disponibiliza duas etiquetas “virtuais” </li></ul><ul><li>Revisão base: BASE </li></ul><ul><ul><li>A revisão na qual a cópia de trabalho está baseada </li></ul></ul><ul><ul><li>É a revisão obtida pela última atualização da área </li></ul></ul><ul><li>Revisão cabeça: HEAD </li></ul><ul><ul><li>A última revisão do arquivo no repositório </li></ul></ul><ul><ul><li>Leva em consideração a linha de código em uso </li></ul></ul><ul><li>Podem ser usadas como qualquer outra etiqueta </li></ul>
    8. 8. O Comando tag <ul><li>O comando tag aplica uma etiqueta sobre revisões de arquivos, por default, as revisões na cópia local ( BASE ) </li></ul><ul><li>cvs [ op_glob ] tag [ op_cmd ] etiqueta [ arquivos ...] </li></ul><ul><ul><li>op_glob são opções globais, op_cmd são opções do comando </li></ul></ul><ul><ul><li>Os argumentos são: o nome da etiqueta a ser criada e zero ou mais arquivos (e diretórios) sobre os quais ela será aplicada </li></ul></ul><ul><li>As opções de comando mais úteis com tag são: </li></ul><ul><ul><li>-b : Faz com que etiqueta seja um ramo ( branch ) </li></ul></ul><ul><ul><li>-c : Não aplica a etiqueta se algum arquivo local estiver modificado </li></ul></ul><ul><ul><li>-D data , -r revisão e -f : permitem especificar outras revisões </li></ul></ul><ul><ul><li>-F : Move a etiqueta se ela já existe em outra revisão do arquivo </li></ul></ul><ul><ul><li>-d : Apaga a etiqueta dos arquivos especificados </li></ul></ul><ul><li>O comando rtag é similar, porém atua só no repositório e, por default, marca as últimas revisões ( HEAD ) </li></ul>
    9. 9. Nomes de Etiquetas <ul><li>Use nomes significativos e claros para etiquetas </li></ul><ul><li>O CVS impõe restrições aos nomes de etiquetas </li></ul><ul><ul><li>Devem começar com letra (maiúscula ou minúscula) </li></ul></ul><ul><ul><li>Podem conter letras, dígitos, hífen “-” e sublinhado “_” </li></ul></ul><ul><li>Sugestão de convenção para nomes de etiquetas: </li></ul><ul><ul><li>Todas as letras maiúsculas </li></ul></ul><ul><ul><li>Separar nomes e dígitos por hífen “-” </li></ul></ul><ul><ul><li>Usar sublinhado “_” no lugar de ponto “.” </li></ul></ul><ul><li>Exemplos: </li></ul><ul><ul><li>O módulo places-1.0 ganhou a etiqueta PLACES-1_0 </li></ul></ul><ul><ul><li>O cvs-1.12.13 seria etiquetado CVS-1_12_13 </li></ul></ul>
    10. 10. Quando Aplicar Etiquetas <ul><li>A freqüência de aplicação de etiquetas faz parte da política de gestão de configuração do projeto </li></ul><ul><ul><li>Assim como as convenções de nomenclatura de etiquetas </li></ul></ul><ul><li>Regra geral: aplique uma etiqueta a cada estágio importante do projeto </li></ul><ul><ul><li>No mínimo, cada liberação deve ser marcada </li></ul></ul><ul><li>Outras situações onde é recomendado aplicar etiquetas: </li></ul><ul><ul><li>Logo após finalizar um requisito importante </li></ul></ul><ul><ul><li>Logo antes de remover um recurso a pedido do cliente </li></ul></ul><ul><ul><li>Logo antes de iniciar uma bateria de testes </li></ul></ul><ul><ul><li>Logo antes de criar um novo ramo (veremos adiante) </li></ul></ul><ul><ul><li>Logo antes de fazer a mescla de um ramo (veremos adiante) </li></ul></ul>
    11. 11. Lab4-1: Aplicando Etiquetas <ul><li>Aplicar uma etiqueta sobre as revisões presentes em uma cópia local </li></ul><ul><li>Verificar o comportamento da opção –c </li></ul><ul><li>Mover uma etiqueta </li></ul><ul><li>Aplicar uma etiqueta diretamente sobre o repositório </li></ul><ul><li>Desafio: renomear uma etiqueta </li></ul>
    12. 12. Múltiplas Linhas de Código <ul><li>Um ramo é uma derivação da linha de código principal de um projeto, o tronco </li></ul><ul><ul><li>Permite que alterações sejam feitas em uma cópia à parte dos arquivos, sem afetar a linha principal </li></ul></ul><ul><li>O CVS implementa um ramo como uma etiqueta especial </li></ul><ul><ul><li>Um ramo é criado pelo comando tag , com a opção –b </li></ul></ul><ul><ul><li>As revisões marcadas pela etiqueta formam a base do ramo </li></ul></ul><ul><ul><li>É boa prática marcar as revisões-base com uma etiqueta normal </li></ul></ul><ul><ul><li>A partir da base, alterações feitas sobre o ramo são armazenadas separadas das alterações feitas sobre o tronco </li></ul></ul><ul><ul><li>A numeração das revisões no ramo é derivada das revisões-base </li></ul></ul><ul><li>Nomes de ramos seguem as mesmas regras que etiquetas </li></ul><ul><ul><li>Para diferenciar, convencionamos usar letras minúsculas </li></ul></ul><ul><li>Como etiquetas, é possível criar ramos sobre apenas alguns arquivos de um projeto, mas não é recomendado </li></ul>
    13. 13. Tronco Principal e Ramos
    14. 14. Trabalhando em um Ramo <ul><li>Um ramo define uma linha de código distinta </li></ul><ul><li>Cada área de trabalho está associada a uma linha </li></ul><ul><li>Portanto, para se trabalhar em um ramo, cria-se uma área de trabalho voltada para aquele ramo </li></ul><ul><li>A opção –r para checkout e update permite a associação de uma cópia local a um ramo </li></ul><ul><ul><li>Basta especificar o nome de um ramo para a opção </li></ul></ul><ul><ul><li>A opção é aderente, futuras execuções de comandos na mesma cópia local se aplicarão ao ramo </li></ul></ul><ul><ul><li>Ao contrário de etiquetas comuns, ramos permitem a execução do comando commit </li></ul></ul><ul><ul><ul><li>Novas revisões serão criadas dentro do ramo utilizado </li></ul></ul></ul>
    15. 15. Mesclas de Ramos <ul><li>É útil ter linhas distintas de código, mas por vezes é preciso mesclar alterações entre duas linhas. Exemplos: </li></ul><ul><ul><li>Quando uma nova liberação está sendo desenvolvida em um ramo e se deseja propagar a correção de um defeito para o tronco </li></ul></ul><ul><ul><li>Quando a nova liberação está pronta e deve se tornar a principal </li></ul></ul><ul><li>Uma mescla de ramos tem uma direção: o ramo origem (inalterado) e o ramo destino (conterá as modificações) </li></ul><ul><ul><li>Tanto o ramo origem quanto o destino podem ser o tronco </li></ul></ul><ul><li>Mesclas de ramos são feitas com o comando update , usando-se a opção –j ( join ou junção) </li></ul><ul><li>Boas práticas: </li></ul><ul><ul><li>Aplicar uma etiqueta sobre o ramo destino antes da mescla </li></ul></ul><ul><ul><li>Um ramo pode ser abandonado após uma mescla, mas não é possível nem desejável remover troncos abandonados </li></ul></ul>
    16. 16. A Opção –j para update <ul><li>A opção –j para o comando update realiza a junção de revisões, geralmente em ramos distintos </li></ul><ul><ul><li>Use também –k k , para evitar expansões de palavras-chave </li></ul></ul><ul><li>É possível usar uma ou duas opções –j em update </li></ul><ul><li>Com duas opções: update –j rev1 –j rev2 </li></ul><ul><ul><li>Toma as diferenças de rev1 para rev2 = Delta( rev1 , rev2 ) </li></ul></ul><ul><ul><li>Aplica Delta( rev1 , rev2 ) sobre a revisão na cópia local, loc </li></ul></ul><ul><ul><li>Pode ocorrer conflito entre Delta( rev1 , rev2 ) e Delta( rev1 , loc ) </li></ul></ul><ul><li>Com uma opção: update –j rev </li></ul><ul><ul><li>Obtém a revisão ancestral entre rev e a cópia local: anc </li></ul></ul><ul><ul><li>Calcula as diferenças de anc para rev = Delta( anc , rev ) </li></ul></ul><ul><ul><li>Aplica Delta( anc , rev ) sobre a revisão na cópia local, loc </li></ul></ul><ul><ul><li>Pode ocorrer conflito entre Delta( anc , rev ) e Delta( anc , loc ) </li></ul></ul>
    17. 17. Mesclando de Ramo para Tronco <ul><li>Queremos tomar as diferenças entre a base do ramo e a ponta do ramo e aplicá-las sobre a ponta do tronco </li></ul><ul><li>Faça um check-out do tronco </li></ul><ul><li>Execute update –j ETIQ-BASE –j ramo </li></ul><ul><li>Na figura, ETIQ-BASE é REL-2_0 e ramo é rel-2_0 </li></ul>
    18. 18. Mesclando de Tronco para Ramo <ul><li>Queremos tomar as diferenças entre a base do ramo e a ponta do tronco e aplicá-las sobre a ponta do ramo </li></ul><ul><li>Faça um check-out do ramo </li></ul><ul><li>Execute update –j ETIQ-BASE –j HEAD </li></ul><ul><li>Na figura, ETIQ-BASE é REL-2_0 e HEAD é 1.5 </li></ul>
    19. 19. Mesclando de Ramo para Ramo <ul><li>Queremos tomar as diferenças entre a base e a ponta do ramo origem e aplicá-las sobre a ponta do ramo destino </li></ul><ul><li>Faça um check-out do ramo destino </li></ul><ul><li>Execute update –j ETIQ-BASE-ORIG –j ramo-dest </li></ul><ul><li>Abaixo, ETIQ-BASE é REL-2_0 e ramo-dest é rel-2_1 </li></ul>
    20. 20. Modelos de Funcionamento <ul><li>Há dois modelos de funcionamento para ramos </li></ul><ul><li>Com a linha principal </li></ul><ul><ul><li>Tronco evolui sempre </li></ul></ul><ul><ul><li>Ramos propagam para o tronco </li></ul></ul><ul><ul><li>Ramos tornam-se obsoletos em algum ponto </li></ul></ul><ul><li>Com a promoção de linhas </li></ul><ul><ul><li>Ramos são “promovidos” à medida que evoluem </li></ul></ul><ul><ul><li>Propagação é sempre para o ramo promovido </li></ul></ul><ul><ul><li>Tronco e ramos antigos tornam-se obsoletos </li></ul></ul>
    21. 21. Quando Criar Ramos <ul><li>Variações sobre um mesmo tema </li></ul><ul><ul><li>Crie ramos para armazenar variantes de um mesmo sistema para clientes diferentes </li></ul></ul><ul><ul><li>Use ramos para guardar diferentes configurações de um mesmo sistema para servidores distintos </li></ul></ul><ul><li>Correção de defeitos </li></ul><ul><ul><li>Crie ramos para corrigir defeitos em liberações anteriores de um sistema, enquanto ele evolui </li></ul></ul><ul><li>Alterações experimentais </li></ul><ul><ul><li>Use ramos para realizar mudanças experimentais, que podem ser descartadas ou parcialmente incorporadas </li></ul></ul><ul><li>Grandes mudanças </li></ul><ul><ul><li>Crie ramos para implementar mudanças profundas no sistema, que o deixarão instável por um período longo </li></ul></ul>
    22. 22. Lab4-2: Trabalhando com Ramos <ul><li>Criar um ramo sobre uma liberação existente </li></ul><ul><li>Criar uma nova área de trabalho, sobre o ramo </li></ul><ul><li>Submeter alterações no ramo </li></ul><ul><li>Fazer uma mescla do ramo para o tronco </li></ul>
    23. 23. Exportando Projetos <ul><li>Em algumas situações, é necessário distribuir os arquivos mantidos sob controle de versões </li></ul><ul><ul><li>Se a empresa atua como fornecedor, pode ser preciso enviar arquivos para um cliente </li></ul></ul><ul><li>Os comandos checkout e update criam áreas de trabalho, com subdiretórios de controle CVS </li></ul><ul><ul><li>Ao exportar, queremos somente os fontes </li></ul></ul><ul><li>O comando export extrai arquivos para distribuição </li></ul><ul><ul><li>Atua diretamente no repositório </li></ul></ul><ul><li>cvs [ op_glob ] export [ op_cmd ] módulo ... </li></ul><ul><ul><li>op_glob são opções globais ( -d é a mais usada) </li></ul></ul><ul><ul><li>op_cmd são opções de comando, similares a checkout </li></ul></ul><ul><ul><ul><li>As mais usadas são –D data , –r revisão e –k opção-k (p.e., -kv ) </li></ul></ul></ul><ul><ul><ul><li>A opção –d diretório também é usada, como em checkout </li></ul></ul></ul><ul><ul><li>O argumento é o nome de um ou mais módulos </li></ul></ul>
    24. 24. Lab4-3: Exportando uma Liberação <ul><li>Exportar uma liberação de um projeto </li></ul><ul><li>Usar as revisões marcadas por uma etiqueta </li></ul><ul><li>Controlar a substituição de palavras-chave na exportação </li></ul>
    25. 25. Recursos para Projetos com Vários Usuários <ul><li>Criado para o uso concorrente, o CVS oferece recursos para projetos com muitos usuários </li></ul><ul><li>Além das capacidades já conhecidas e do modelo copia-modifica-mescla, o CVS oferece: </li></ul><ul><ul><li>A capacidade para funcionar em um modelo de edição exclusiva de arquivos, com uma dentre duas formas: </li></ul></ul><ul><ul><ul><li>Observando arquivos, é possível sugerir, mas não forçar, a edição exclusiva de arquivos </li></ul></ul></ul><ul><ul><ul><li>Com o comando admin , pode-se implementar o modelo trava-modifica-destrava, para garantir a edição exclusiva </li></ul></ul></ul><ul><ul><li>A divulgação de operações como check-ins e aplicações de etiquetas, por programas configurados em modules </li></ul></ul><ul><ul><li>Um comando para acompanhar a atividade dos autores </li></ul></ul>
    26. 26. Observando Arquivos <ul><li>O CVS oferece comandos para avisar usuários quando arquivos são editados ou submetidos </li></ul><ul><li>Esses comandos são úteis para: </li></ul><ul><ul><li>Monitorar as atividades de membros da equipe </li></ul></ul><ul><ul><li>Acompanhar a edição de certos arquivos, diminuindo a probabilidade de mesclas </li></ul></ul><ul><ul><li>Sugerir, mas não garantir, um modelo de edição exclusiva </li></ul></ul><ul><li>Comandos envolvidos: watch , edit e unedit </li></ul><ul><ul><li>Para seu funcionamento correto, é preciso configurar os arquivos administrativos notify e users </li></ul></ul>
    27. 27. Mecânica da Observação <ul><li>Um usuário cria sua área de trabalho </li></ul><ul><li>Ele marca alguns arquivos para observação </li></ul><ul><ul><li>Isso é feito com o comando cvs watch on arquivos ... </li></ul></ul><ul><ul><li>A operação avisa o CVS que o arquivo será observado </li></ul></ul><ul><ul><li>O gestor do projeto é em geral quem define isso </li></ul></ul><ul><li>O usuário se inclui na lista de observadores dos arquivos nos quais ele está interessado </li></ul><ul><ul><li>Ele usa o comando cvs watch add sobre os arquivos </li></ul></ul><ul><li>Ele e outros usuários devem usar o comando edit antes de editar um arquivo observado </li></ul><ul><ul><li>Os observadores serão notificados sobre a edição </li></ul></ul><ul><li>Ao terminar as alterações, o autor as submete ( commit ) </li></ul><ul><ul><li>Caso queira descartá-las, usa unedit , que reverte as mudanças e avisa os demais que o arquivo não está mais sendo editado </li></ul></ul>
    28. 28. Reservando Arquivos para Edição <ul><li>O modelo copia-modifica-mescla é bastante efetivo para a maioria dos projetos </li></ul><ul><li>Porém, em alguns casos, pode ser preciso usar o modelo trava-modifica-destrava </li></ul><ul><ul><li>Por exemplo, quando os arquivos sob o controle do CVS são binários, criados com uma ferramenta e a mescla é impossível </li></ul></ul><ul><li>Para implementar edição exclusiva com o CVS: </li></ul><ul><ul><li>Instale e configure o script rcslock , disponível na maioria das distribuições do CVS </li></ul></ul><ul><ul><ul><li>Ele deve ficar em um diretório acessível por todos os usuários e o arquivo commitinfo deve ser configurado para chamá-lo </li></ul></ul></ul><ul><ul><li>Para reservar um arquivo, use o comando admin com a opção –l </li></ul></ul><ul><ul><li>Ao submeter alterações com commit , a trava será removida </li></ul></ul><ul><ul><li>Para desistir da reserva sem check-in, use admin com a opção –u </li></ul></ul>
    29. 29. Divulgando Operações <ul><li>Outra forma de auxiliar projetos com vários usuários é divulgar operações relevantes </li></ul><ul><ul><li>Por exemplo, check-ins e marcações de liberações </li></ul></ul><ul><li>Para divulgar check-ins: </li></ul><ul><ul><li>Configure o arquivo loginfo para enviar e-mail para uma lista, contendo a mensagem de log do check-in </li></ul></ul><ul><li>Para divulgar a aplicação de etiquetas: </li></ul><ul><ul><li>Configure o arquivo modules , usando a opção –t para especificar um programa para o envio de e-mail </li></ul></ul><ul><ul><li>O programa só será invocado quando a etiqueta for aplicada com o comando rtag </li></ul></ul>
    30. 30. Acompanhando a Atividade do Repositório <ul><li>O CVS registra a atividade sobre o repositório no arquivo administrativo history </li></ul><ul><ul><li>Para isso, esse arquivo deve existir e disponível para escrita pelos usuários do CVS </li></ul></ul><ul><li>O comando history lista a atividade do CVS </li></ul><ul><li>cvs [ op_glob ] history [ op_cmd ] [ arquivos ...] </li></ul><ul><ul><li>op_glob são opções globais e op_cmd , opções de comando. As mais usadas são: </li></ul></ul><ul><ul><ul><li>-m módulo : relata o histórico somente de módulo </li></ul></ul></ul><ul><ul><ul><li>-D data : mostra somente o histórico a partir de data </li></ul></ul></ul><ul><ul><li>O argumento são zero ou mais arquivos (ou módulos) </li></ul></ul><ul><li>A saída de history pode ser configurada </li></ul><ul><ul><li>Sua forma geral é uma tabela com tipos de operações, datas usuários e arquivos afetados </li></ul></ul>
    31. 31. O Comando admin <ul><li>O comando admin disponibiliza várias operações administrativas sobre o repositório </li></ul><ul><ul><li>Algumas são perigosas, mantidas por razões históricas </li></ul></ul><ul><li>cvs [ op_glob ] admin [ op_cmd ] [ arquivos ...] </li></ul><ul><ul><li>op_glob são opções globais, op_cmd são opções do comando, as mais usadas são: </li></ul></ul><ul><ul><ul><li>-k opção-k : Redefine o modo de substituição de palavras-chave; útil quando um arquivo binário é adicionado como texto </li></ul></ul></ul><ul><ul><ul><li>– l rev e –u rev : Trava e destrava revisões de arquivos </li></ul></ul></ul><ul><ul><ul><li>– m rev : msg : Redefine a mensagem de log da revisão </li></ul></ul></ul><ul><ul><li>O argumento são zero ou mais arquivos ou diretórios </li></ul></ul><ul><ul><ul><li>Cuidado: admin tem comportamento recursivo por default! </li></ul></ul></ul>
    32. 32. Ferramentas para o CVS <ul><li>Com os conhecimentos adquiridos neste curso, é possível usar plenamente o CVS em qualquer projeto </li></ul><ul><li>Porém, ferramentas auxiliares podem ser úteis: </li></ul><ul><ul><li>Para tornar as atividades mais eficientes, com interfaces gráficas </li></ul></ul><ul><ul><li>Para ajudar usuários sem prática com a linha de comando </li></ul></ul><ul><li>Clientes gráficos: </li></ul><ul><ul><li>CVSGUI: WinCVS (Windows), gCVS (UNIX), MacCVS (Macintosh) </li></ul></ul><ul><ul><li>Multi-plataforma, escritos em Java: jCVS e SmartCVS </li></ul></ul><ul><ul><li>Linux: Cervisia e LinCVS (Qt), Pharmacy (Gnome), tkCVS (Tcl/Tk) </li></ul></ul><ul><ul><li>Cliente integrado ao shell do Windows: TortoiseCVS </li></ul></ul><ul><ul><li>IDEs Java com cliente CVS integrado: Eclipse, JBuilder, NetBeans </li></ul></ul><ul><li>Ferramentas para distribuição e acesso remoto: </li></ul><ul><ul><li>CVSUp, Chora, CVSviaFTP, CVSweb, jCVS Servlet, ViewCVS </li></ul></ul><ul><li>Conversores: rcs-to-cvs, sccs2rcs, VSS2CVS, pvcs2rcs </li></ul>
    33. 33. Boas Práticas em GCS <ul><li>Como o tema de Gestão de Configuração é amplo, há várias boas práticas e padrões para a área </li></ul><ul><ul><li>Livro: Software Configuration Management Patterns (Berczuk) </li></ul></ul><ul><li>Muitas boas práticas aplicadas ao CVS foram citadas ao longo do treinamento </li></ul><ul><ul><li>Manter a área de trabalho atualizada com update </li></ul></ul><ul><ul><li>Usar commit de acordo com a política em vigor </li></ul></ul><ul><ul><li>Aplicar etiquetas com tag : </li></ul></ul><ul><ul><ul><li>Para marcar liberações relevantes para o projeto </li></ul></ul></ul><ul><ul><ul><li>Antes de criar um ramo e antes de uma mescla de outro ramo </li></ul></ul></ul><ul><ul><li>Criar ramos ( tag –b ) quando uma nova linha de código for necessária: versão experimental, correção de defeitos, etc. </li></ul></ul><ul><li>Boas práticas gerais serão vistas nos próximos slides </li></ul>
    34. 34. Boas Práticas: Área de Trabalho <ul><li>Não compartilhe áreas de trabalho </li></ul><ul><ul><li>Cada autor deve ter sua área de trabalho exclusiva </li></ul></ul><ul><li>Não altere arquivos fora das áreas de trabalho </li></ul><ul><li>Controle a atualização de sua área de trabalho </li></ul><ul><ul><li>Não deixe que processos automáticos ou eventos externos atualizem a área sem a sua intervenção </li></ul></ul><ul><li>Mantenha a sincronia com a linha de código </li></ul><ul><ul><li>Atualize a área com freqüência </li></ul></ul><ul><li>Faça check-ins com freqüência </li></ul><ul><ul><li>Mas procure seguir a política da linha de código </li></ul></ul>
    35. 35. Boas Práticas: Linha de Código <ul><li>Atribua uma política a cada linha de código </li></ul><ul><ul><li>Linhas mais experimentais podem ter um nível de exigência menor quando à qualidade do código </li></ul></ul><ul><ul><li>Linhas mais maduras e estáveis devem ser severas </li></ul></ul><ul><li>Defina um dono para cada linha de código </li></ul><ul><ul><li>As políticas podem ser ambíguas ou pode haver uma exceção: o dono é quem resolve </li></ul></ul><ul><li>Tenha uma linha principal </li></ul><ul><ul><li>Entre linha principal e promoção de linhas, a melhor abordagem é ter uma linha principal </li></ul></ul><ul><ul><li>Mantenha sempre a evolução dessa linha </li></ul></ul>
    36. 36. Boas Práticas: Ramos <ul><li>Crie ramos só quando necessário </li></ul><ul><ul><li>Um ramo significa trabalho extra – tenha isso em mente e só crie ramos quando realmente necessário </li></ul></ul><ul><li>Não crie cópias quando se deve criar ramos </li></ul><ul><ul><li>Quando um ramo for necessário, use-o; não copie os arquivos para outro diretório para evoluí-los </li></ul></ul><ul><li>Crie ramos diante de políticas incompatíveis </li></ul><ul><ul><li>Versões experimentais, novos recursos, defeitos </li></ul></ul><ul><li>Postergue a criação de ramos </li></ul><ul><ul><li>Deixe a criação do ramo para o último momento: quanto menor a distância para uma mescla, melhor </li></ul></ul><ul><li>Crie ramos em vez de congelar a linha de código </li></ul>
    37. 37. Boas Práticas: Mesclas de Ramos <ul><li>Faça as alterações que devem ser propagadas na linha que mudou menos desde a criação do ramo </li></ul><ul><ul><li>Imagine uma alteração que terá que ser propagada para diversos ramos (a correção de um defeito grave) </li></ul></ul><ul><ul><li>Faça essa alteração na linha que menos mudou desde que o ramo foi criado – será mais fácil propagá-la </li></ul></ul><ul><li>Propague as mudanças cedo e com freqüência </li></ul><ul><ul><li>Quanto menor a diferença entre as revisões, melhor: é maior a probabilidade de se ter uma mescla automática </li></ul></ul><ul><li>Peça à pessoa certa para fazer a mescla </li></ul><ul><ul><li>Escolha quem fez a alteração a ser propagada (origem) ou quem conhece o código que irá recebê-la (destino) </li></ul></ul>
    38. 38. Boas Práticas: Compilação <ul><li>Código-fonte + Ferramentas = Produto </li></ul><ul><ul><li>Não há lugar para passos manuais </li></ul></ul><ul><li>Faça o check-in do código original </li></ul><ul><li>Separe artefatos derivados do código original </li></ul><ul><li>Use ferramentas padrão na compilação </li></ul><ul><ul><li>Não use ferramentas esotéricas, elas podem não existir amanhã </li></ul></ul><ul><li>Se possível, integre o CVS à compilação </li></ul><ul><ul><li>Os sistemas mais importantes podem ser integrados com o CVS: </li></ul></ul><ul><ul><ul><li>Ant: disponibiliza uma tarefa chamada cvs </li></ul></ul></ul><ul><ul><ul><li>make: comandos CVS podem estar em regras no Makefile </li></ul></ul></ul><ul><li>Compile com freqüência </li></ul><ul><li>Guarde os logs e a saída da compilação </li></ul>
    39. 39. Boas Práticas: Gestão de Mudanças <ul><li>Acompanhe pacotes de mudanças </li></ul><ul><ul><li>Saiba quais arquivos mudaram em conjunto para atender uma demanda (novo recurso, correção de defeito) </li></ul></ul><ul><ul><li>O CVS não oferece grande auxílio aqui, só mensagens de log </li></ul></ul><ul><li>Acompanhe propagações de pacotes de mudanças </li></ul><ul><ul><li>Saiba como os pacotes são aplicados a outras linhas de código </li></ul></ul><ul><li>Diferencie requisições de mudanças de pacotes de mudanças </li></ul><ul><ul><li>Separe o que foi pedido daquilo que foi feito para atender o pedido </li></ul></ul><ul><li>Atribua um dono a tudo </li></ul><ul><ul><li>Linha de código, documento, produto, tarefa devem ter um dono </li></ul></ul><ul><li>Mantenha a documentação atualizada </li></ul><ul><ul><li>Crie documentos só quando necessário, isso ajudará! </li></ul></ul>
    40. 40. Encerramento <ul><li>Obrigado por participar deste treinamento! </li></ul><ul><li>Cobrimos praticamente todos os aspectos do CVS: </li></ul><ul><ul><li>Dimensionamento, instalação, configuração, uso </li></ul></ul><ul><ul><li>Todos os comandos (sim, vimos todos eles!) </li></ul></ul><ul><ul><li>Arquivos administrativos e variáveis de ambiente </li></ul></ul><ul><li>Agora é um bom momento para: </li></ul><ul><ul><li>Tirar dúvidas </li></ul></ul><ul><ul><li>Compartilhas experiências </li></ul></ul><ul><ul><li>Fazer comentários, elogios e críticas </li></ul></ul><ul><li>Por favor, preencham os formulários de avaliação </li></ul><ul><li>Meu contato: marden@mardenneubert.com </li></ul>

    ×