Avançado CVS Módulo 4: Gestão de Configuração e Projetos
•Transferir como PPT, PDF•
0 gostou•443 visualizações
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (8)
Semelhante a Avançado CVS Módulo 4: Gestão de Configuração e Projetos
Semelhante a Avançado CVS Módulo 4: Gestão de Configuração e Projetos (20)
Avançado CVS Módulo 4: Gestão de Configuração e Projetos
- 1. Uso Avançado do CVS Módulo 4 Foco: Gestor de Configuração e Projeto
- 5. Uma Liberação Antes da Etiqueta
- 6. A Liberação Após a Etiqueta
- 13. Tronco Principal e Ramos
Notas do Editor
- 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?