Curso de CVS - Parte 1 - Introdução

Copyright© 2005, Marden Neubert

1-1

CVS

www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert

Introdução a Gestão de Configuração e CVS

Módulo 1

Foco: Geral

Neste módulo, introduzimos a disciplina de gestão de configuração, a área da Engenharia de Software na qual o emprego do CVS se encaixa. O foco deste módulo é geral, isto é, engloba todos os perfis envolvidos na implantação e uso do CVS.

Explicamos os principais conceitos da área, de forma independente de ferramental. Apresentamos então o CVS, contando brevemente seu histórico e como ele evoluiu até o estágio atual. Por fim, associamos os conceitos de gestão de configuração aos recursos do CVS e apresentamos algumas características especiais do CVS, que ajudarão no entendimento da sua operação como um todo.


1-2


Agenda

• O que o CVS é, o que ele não é• Sistemas de controle de versões, alternativas• A disciplina de Gestão de Configuração• Histórico e arquitetura geral do CVS• Cenários de funcionamento do CVS• Visita guiada ao CVS• Conceitos básicos• Outros conceitos• Conceitos gerais do CVS

Este slide mostra nossa agenda para este primeiro módulo do treinamento.


1-3


O Que É o CVS?

• CVS significa Concurrent Versions System– Em bom português: Sistema de Versões Concorrentes

• É um sistema de controle de versões open-source• Um sistema de controle de versões é usado para:

– Registrar versões de arquivos ao longo de sua evolução– Recuperar qualquer versão armazenada de um arquivo– Permitir a evolução concorrente de várias versões

• Daí a ênfase em “versões concorrentes”

• Além disso, o CVS facilita o trabalho simultâneo de vários autores em um mesmo arquivo– Evitando, por exemplo, que um autor sobrescreva as

modificações feitas por outro

Em um treinamento sobre CVS, nada mais apropriado do que responder esta pergunta em primeiro lugar. Afinal, de que adianta iniciarmos uma discussão sobre gestão de configuração sem antes entender o que é o CVS e por que ele se encaixa em toda uma teoria?

Colocando de forma simples, o CVS é um sistema de controle de versões. Esse tipo de sistema foi criado armazenar as diversas versões de arquivos ao longo de sua evolução. Apesar dessa ser uma função bastante genérica, ela surgiu a partir da necessidade de programadores recuperarem uma versão anterior de um código-fonte. Quem conhece programação sabe que isso pode ser preciso por uma série de razões, tais como: um defeito introduzido que precisa ser removido, a necessidade de executar uma versão anterior do sistema para comparar resultados, ou ainda alguma alteração que foi pedida pelo cliente, que depois mudou de idéia.

Se pode ser difícil controlar o histórico de versões de alguns arquivos, imaginem quando um projeto passa a ter centenas, até milhares deles. Um sistema automatizado para não só armazenar todos esses históricos, mas também deixá-los sincronizados, é essencial. Outro desafio é permitir que um sistema tenha diferentes liberações independentes, por exemplo, uma para cada cliente.

Por fim, mais uma vantagem que um sistema como este pode oferecer é organizar o trabalho de vários programadores em um mesmo sistema, permitindo que eles compartilhem seu trabalho e, sobretudo, impedindo que um sobrescreva as modificações feitas por outro. Neste aspecto, o sistema pode ser visto (de forma bastante simplista) como uma alternativa superior a armazenar o código em um sistema de arquivos compartilhado.

Outra informação relevante sobre o CVS: ele é um software livre, ou open-source. Isso quer dizer que seu código-fonte pode ser redistribuído e até alterado livremente, desde que se mantenha essa condição em qualquer trabalho derivado. Existem várias licenças open-source e o CVS utiliza uma das mais conhecidas, a GPL (GNU Public License). Outra conseqüência dessa licença é que o CVS pode ser implantado, utilizado e redistribuído sem custo algum.


1-4


O Que o CVS Não É

• Um sistema de compilação de código• Um sistema de acompanhamento de defeitos• Um sistema de controle de mudanças• Um sistema de automatização de testes• Um sistema de gestão de conteúdo• Um substituto para a gestão• Um substituto para a comunicação• Um substituto para a disciplina• Um processo de desenvolvimento

Esta é a lista de algumas das coisas que pessoas já me perguntaram se o CVS é ou fazia. Certamente existem outros mal-entendidos, mas estes me chamaram mais a atenção.

Um sistema de compilação de código é um mecanismo para gerenciar as dependências entre módulos, componentes e conduzir a compilação dos mesmos na ordem correta. Quem trabalha com Java conhece Ant, quem trabalha com C conhece make, que são feitos para isso. Mas o CVS não é. O CVS pode armazenar código e seus arquivos build.xml e Makefile, mas ele não influencia de forma alguma o processo de compilação. O contrário pode ser verdade: seu build.xml ou seu Makefile podem incluir diretivas para obter o código do CVS e conduzir a compilação e até marcar automaticamente liberações no CVS.

O CVS não é um sistema de acompanhamento de defeitos como o Bugzilla. Ele não permite que defeitos sejam cadastrados, consultados, alterados. De forma similar, um sistema de controle de mudanças, como o Rational ClearQuest permite que requisições de evolução sejam cadastradas e gerenciadas. O CVS também não realiza a gestão e o acompanhamento desse tipo de requisição. Por outro lado, o CVS armazena modificações que podem ter sido produzidas para corrigir defeitos e permite que desenvolvedores comentem o que cada modificação implementa: arquivos administrativos como rcsinfo e verifymsg podem ser úteis nesse processo.

Outra confusão curiosa que surgiu foi tomar o CVS como um sistema de gestão de conteúdo. Um sistema desta categoria é responsável por organizar a edição de documentos (por exemplo, para a atualização de um site na Web) e gerenciar sua implantação (geralmente em um servidor Web). O CVS pode ser usado, porém, como repositório para o armazenamento dos históricos de modificações das páginas.

O CVS também não é substituto para nenhuma tarefa de gestão, mas sim uma ferramenta. Ele não dispensa a comunicação entre desenvolvedores, apesar de facilitar o trabalho em conjunto. Ele também não funciona se seus usuários não tiverem algum método ou disciplina. Por fim, ele não dita ou força um processo de desenvolvimento, apesar de ser um elemento essencial para processos como RUP e eXtreme Programming.


1-5


Sistemas de Controle de Versões

• Controle de Versões é definido como “o processo de armazenar e recuperar as modificações em um projeto”

• Funcionalidades típicas de um sistema de controle de versões:– É possível autenticar e controlar o acesso de usuários (autores)– Qualquer revisão armazenada pode ser recuperada para

modificação ou apenas visualização– Diferenças entre quaisquer duas revisões podem ser visualizadas– Vários autores podem trabalhar em um mesmo arquivo, sem riscos– É possível marcar estágios relevantes na evolução do trabalho– Um projeto pode ser ramificado em linhas alternativas de trabalho– Alterações em linhas alternativas podem ser propagadas– O trabalho pode ser distribuído através de redes de qualquer porte

A definição de Controle de Versões dentro da Engenharia de Software é “O processo de armazenar e recuperar as modificações de um projeto”. Porém, sistema de controle de versões oferecem recursos que vão muito além da capacidade de registrar e consultar alterações. As funcionalidades mais comuns encontram-se listadas neste slide.

A autenticação é um recurso comum a sistemas de controle de versões pois, em ambientes corporativos e distribuídos, é importante restringir o acesso a usuários identificados. Alguns sistemas também permitem a configuração refinada da autorização, isto é, das permissões que um usuário tem a cada arquivo. Cada modificação registrada é chamada “revisão”. Os históricos de revisões não teriam grande utilidade se não pudessem ser recuperados, consultados e processados. Portanto, é possível obter qualquer revisão e modificá-la (a modificação sempre cria uma nova revisão), bem como compará-la com outra revisão.

Sistemas de controle de versões também viabilizam que diversos autores trabalhem em um mesmo arquivo, modificando-o independentemente, sem que corram risco de perda de trabalho (eliminando, por exemplo, a possibilidade de um autor sobrescrever as modificações feitas por outro). As alterações feitas por cada um são registradas separadamente e existe um controle que evita que um autor realize modificações feitas sobre uma revisão antiga de um arquivo. Deve-se lembrar que nenhum sistema é “à prova de besteiras”: é possível perder trabalho mesmo usando o CVS, por exemplo, se dois autores compartilharem a mesma área de trabalho. Boas práticas e regras básicas para evitar esses problemas serão vistos neste treinamento.

Capacidades mais avançadas incluem a possibilidade de marcar estágios coerentes (e relevantes) na evolução do trabalho. Isso é necessário porque qualquer projeto não-trivial será formado por mais de um (geralmente, vários) arquivos. Cada arquivo tem seu próprio histórico, sua evolução ao longo do tempo. Portanto, é importante a capacidade de se “marcar” quais revisões formam juntas um conjunto coerente. Outra capacidade avançada é a possibilidade de criar linhas alternativas de trabalho, permitindo o desenvolvimento concorrente de versões.


1-6


O Que Deixar sob oControle de Versões?

• Sempre ficam sob o controle de versões:– Qualquer arquivo produzido por atividades desenvolvidas no

decorrer de um projeto• Código-fonte, modelos UML, requisitos, scripts de teste

– Arquivos auxiliares que não gerados automaticamente ou necessários para compilar/transformar os fontes• Arquivos de compilação (build.xml, Makefile), configurações

• Ficam fora do controle de versões:– Arquivos facilmente gerados por compilação ou transformação

• Binários (executáveis, bibliotecas), documentação automática

• Podem ficar sob o controle de versões:– Arquivos que não poderiam ser gerados de forma simples

• Bibliotecas de terceiros, código gerado por ferramentas inacessíveis– Regra geral: qualquer arquivo que não puder ser gerado

facilmente às vésperas de uma liberação deve ser versionado

Uma questão que logo surge com relação a sistemas de controle de versões é o que devemos deixar sob o controle desses sistemas. Existem algumas regras gerais, mas sempre encontramos exceções e situações que podem gerar dúvidas.

Como regra geral, qualquer artefato (arquivo) produzido pelo trabalho criativo dos participantes de um projeto deve ficar sobre o controle de versões. Em projetos de software, isso não inclui somente o código-fonte, mas também modelos (UML ou modelos E/R produzidos por ferramentas como o Erwin) , scripts para carga de bancos de dados, scripts e roteiros de teste de QA e, um dos mais importantes e mais esquecidos artefatos, a documentação do projeto: Visão, Casos de Uso e requisitos em geral. Outro tipo de arquivo a ser versionado é aquele que funciona como suporte para o código-fonte: scripts de compilação, sejam arquivos build.xml do Ant, Makefiles ou shellscripts. Arquivos de configuração para a compilação ou a implantação do sistema (configurações em XML ou arquivos .properties de Java) também se encaixam nessa categoria.

Já arquivos que certamente não devem ficar sob o controle de versões são aqueles facilmente gerados pela compilação ou alguma transformação sobre o código-fonte do sistema. Os exemplos típicos são arquivos binários executáveis (.class para Java, .o e .exe para C) e bibliotecas de binários (.jar para Java e .a e .so para C). Esses arquivos devem ser gerados de forma simples e automática. Outros arquivos gerados incluem documentação gerada automaticamente (como Javadocs), configurações extraídas do próprio código-fonte (tais como arquivos de implantação gerados pelas ferramentas XDoclet e EJBGen) e até mesmo código-fonte gerado (usando, por exemplo, um gerador de compiladores como JavaCC para Java, lex e yacc/bison para C).

A questão é dúbia para arquivos que podem ser gerados, mas não de forma tão simples ou rápida ou automática. Um exemplo são bibliotecas de terceiros que raramente mudam e que, mesmo tendo seu código-fonte, seriam difíceis ou lentas para se compilar. Também é conveniente versionar arquivos gerados por ferramentas restritas (caras, com poucas licenças) às quais nem todos têm acesso. Enfim, qualquer arquivo que não puder ser facilmente gerado às vésperas de um liberação importante deve ser considerado como candidato ao controle de versões.


1-7


Alternativas ao CVS

• Open-source– RCS (Revision Control System)– SCCS (Source Code Control System)– Subversion

• Comerciais– Microsoft Visual SourceSafe– Rational ClearCase– Borland StarTeam– Perforce

Para conhecer bem um software é preciso saber situá-lo diante da concorrência. No caso de um sistema open-source como o CVS, a palavra “concorrência” tem um significado um pouco diferente, pois não há exatamente uma competição pelo mercado. Mas podemos falar em alternativas.

Separamos as alternativas em outros sistemas open-source e sistemas comerciais.

Entre os sistemas open-source, o mais antigo é o RCS. Ele é um sistema bem simples, que controla apenas mudanças em arquivos e não tem o conceito de módulo ou projeto. Ele éadequado apenas para usuários individuais e pequenos projetos, pois não permite modificações concorrentes em um arquivo. Os históricos são armazenados em subdiretórios na própria área de trabalho do usuário. Apesar de limitado, ele tem o mérito de ter sido o primeiro sistema de controle de versões a ser usado de forma ampla. O CVS e o sistema comercial Perforce ainda hoje usam o formato do arquivo de histórico do RCS.

O SCCS é outro sistema open-source mais antigo, que trouxe a vantagem de permitir a modificações simultâneas em um mesmo arquivo. As revisões são armazenadas não como arquivos individuais, mas como diferenças, chamadas “deltas”, em relação à revisão anterior. Apesar de contar com recursos mais avançados que o RCS, o SCCS perdeu espaço com o surgimento do CVS.

O Subversion já encontra-se do outro lado na lista de comparações com o CVS: ele é tido como o sucessor do CVS. Ele foi desenhado para aproveitar as qualidades do CVS e eliminar os seus inconvenientes. Entretanto, o Subversion ainda é considerado imaturo quando comparado ao CVS e tem uma base de usuários muito pequena. Falaremos sobre o Subversion ao fim deste treinamento.

Entre os softwares comerciais, o VSS é o mais simples e com menos recursos. O ClearCase e o StarTeam estão entre os mais poderosos e mais caros. O Perforce é um sistema comercial, mas que guarda similaridades com o CVS, sobretudo no formato dos arquivos de histórico.


1-8


Gestão de Configuração de Software

• A configuração de um sistema são as características de hardware e software que levam a um produto final

• Gestão de configuração é o processo de acompanhar a configuração de um sistema ao longo do tempo para: – Controlar mudanças à configuração de forma sistemática– Manter a integridade da configuração ao longo da vida do sistema

• É uma disciplina de suporte ao ciclo de vida do software• De forma geral, define como uma organização:

– Constrói e libera produtos– Identifica e acompanha mudanças

• Encontra-se formalmente definida em padrões como:– IEEE Std 828-1998 e ISO/IEC TR 15846:1998

• É parte integrante do SWEBOK

É interessante saber que o CVS dá suporte a uma importante disciplina da Engenharia de Software. Realmente, a Gestão de Configuração de Software é formalmente definida nos padrões mais respeitados da Engenharia de Software, como IEEE e ISO/IEC. Grande empresas têm o cargo de “gestor de configuração”, o profissional, geralmente ligado à área de Garantia da Qualidade (Quality Assurance, QA), responsável por definir e assegurar a aplicação das práticas de gestão de configuração da organização.

A definição formal de Gestão de Configuração de Software de acordo com o IEEE é:

“A disciplina que aplica diretivas e revisões técnicas e administrativas para: identificar e documentar as características físicas e funcionais de um item de configuração, controlar mudanças àquelas características, registrar e relatar o processamento de mudanças e o status da implementação, bem como verificar a aderência aos requisitos especificados.”


1-9


Melhores Práticas deEngenharia de Software

• Abordagens conhecidas e testadas– Observadas em projetos que tiveram sucesso

Usarcomponentes

Verificar aqualidade

Desenvolver iterativamente

Controlar mudanças

Desenvolver iterativamente

Controlar mudanças

Usarcomponentes

Modelarvisualmente

Verificar aqualidade

Gerenciarrequisitos

Na área de Engenharia de Software, é comum se conduzirem pesquisas regularmente para identificar características comuns a projetos que deram certo (entregaram o que era desejado no prazo e sem estourar o orçamento). Um dos mais famosos estudos é o CHAOS Report, gerado a cada 2 anos. As pesquisas buscam identificar quais práticas que foram responsáveis ou colaboraram para o sucesso. As 6 práticas mostradas neste slide são resultado desses estudos e foram consideradas essenciais e são encontradas em equipes e empresas vitoriosas.

No topo é listada a prática de “Desenvolver iterativamente”. Ela é justificada pelo fato de que, no início de qualquer projeto, os requisitos não são completamente conhecidos, os desafios tecnológicos não foram todos listados ou ainda a situação econômica/política pode alterar ao longo do projeto e mudar algumas premissas. A abordagem “tradicional” de desenvolvimento éconhecida como “cascata”, onde o sistema é feito como um todo, fase a fase. Isto é, todos os requisitos são definidos, depois toda a análise é feita, depois todo o desenho, depois toda a implementação e só depois todo o teste. Por outro lado, esta prática diz que projetos de software devem ser conduzidos em “mini-projetos”, cada um realizando todas as atividades de desenvolvimento (desde requisitos, desenho, codificação e testes), entregando um incremento do sistema final.

As práticas de “Gerenciar requisitos”, “Usar componentes”, “Modelar visualmente” e “Verificar a qualidade” são as chaves para mitigar riscos e acelerar o desenvolvimento com qualidade.

Como atividade de suporte a todas as outras, está “Controlar mudanças”. Se o desenvolvimento éiterativo, se temos diversas pessoas trabalhando ao mesmo tempo em tarefas relacionadas e se não existe um controle explícito das mudanças, o projeto pode virar um caos. Além disso, dizemos o seguinte: “só uma coisa é certa durante um projeto de software: os requisitos vão mudar”. A única forma de impor alguma ordem a esta caos é controlar os diversos estágios de evolução do sistema ao longo de seu ciclo de vida.


1-10


Fases, Disciplinas e Iterações

Este slide explica melhor o que é um processo iterativo, usando um diagrama do “RationalUnified Process”, um dos processos mais conhecidos na atualidade.

O processo define fases para um projeto. Observem quais são elas no topo: Inception (Iniciação), Elaboração, Construção e Transição. Cada uma tem um foco:

Iniciação: identificar o problema a ser atacado e conceber o sistema que deve ser criado para solucioná-lo.

Elaboração: detalhar o problema, evoluir na modelagem da solução, iniciar a implementação de aspectos-chave.

Construção: implementar a solução, testá-la.

Transição: implantar a solução, corrigir defeitos, planejar sua evolução.

No eixo da esquerda, encontram-se as disciplinas. Notem que a intensidade de cada disciplina emcada fase varia, mas uma disciplina não é estanque a uma determinada fase, como acontece com a metodologia em cascata. Por exemplo, de Análise & Desenho começa na fase de Iniciação, tem seu auge na Elaboração, ainda é forte na Construção e tem reminiscências na Transição.

Agora observem as iterações na barra do diagrama. Em cada fase, estão previstas iterações, dentro das quais as disciplinas são exercitadas, como em um mini-projeto. Por exemplo, a Elaboração émostrada com duas iterações. Notem que em cada iteração é desempenhado um pouco de cada disciplina, com a intensidade variando de acordo com o duração da iteração.

Vamos observar com atenção a disciplina de “Gestão de Configuração e Mudança”. Ela e as outras duas últimas disciplinas são as disciplinas de suporte do RUP. Notem que ela começa a ser notada ao fim da Iniciação, quando já existem documentos a serem versionados. Sua intensidade aumenta e tem seu auge na fase de Construção, quando o desenvolvimento é mais intenso, e na Transição, quando os testes estão sendo finalizados e há defeitos se corrigir.


1-11


Breve História do CVS

• O RCS foi desenvolvido por Walter Tichy, da Purdue University, no início dos anos 80

• Em 1986, Dick Grune postou alguns shell scripts no comp.sources.unix para melhorar o RCS– Os scripts permitiam a edição concorrente de arquivos,

sem o uso de travas, daí surgindo o nome CVS

• Brian Berliner em 1989 reescreveu todo o CVS em C, mantendo as idéias de Tichy e Grune– Entre as contribuições da nova versão estão o suporte

a ramos e o uso de um repositório central

• O código-fonte do CVS foi publicado sob a licença GPL e hoje é software livre, mantido pela FSF

O RCS é o início da história do CVS. Ele surgiu no ínicio dos anos 80 na Universidade Purdue. Seu criador, Walter Tichy, criou o mecanismo de armazenamento de diferenças que ainda é usado pelo CVS. Por ser uma criação acadêmica, existem artigos que descrevem o funcionamento desse mecanismo, tais como:

Tichy, Walter F. “Design, Implementation, and Evaluation of a Revision Control System.”Proceedings of the 6th International Conference on Software Engineering, IEEE, Tokyo, September 1982.

Uma das principais limitações do RCS era forçar que apenas um autor pudesse trabalhar em um arquivo por vez, o que era feito por travas (locks). Em julho de 1986, Dick Grune, da VrijeUniversiteit, de Amsterdã, postou no newsgroup comp.source.unix alguns shell scripts para contornar essa limitação e permitir que vários autores trabalhassem com um mesmo arquivo ao mesmo tempo. Nesta época surgiu o nome CVS. A principal contribuição do trabalho de Grune foi o algoritmo para a resolução de conflitos – uma forma de combinar alterações conflitantes em um mesmo arquivo. Esse algoritmo é utilizado até hoje no CVS.

Em 1989, Brian Berliner recodificou completamente o CVS, substituindo os scripts por código C, mas mantendo as heranças do RCS e dos scripts de Grune. Como a empresa onde Berlinertrabalhava, a Prisma Software, precisava integrar código vindo de diferentes fornecedores, ele e seu colega Jeff Polk adicionaram um suporte a “ramos de código” (code branches). Dessa forma, o código produzido por cada fornecedor (vendor) podia ser armazenado em um ramo separado e posteriormente combinado em um tronco principal. Outra inovação incorporada por Berliner foi o uso de um repositório central e distribuído: dessa forma, os arquivos de histórico não mais seriam armazenados junto à copia de trabalho do usuário.

O código produzido por Berliner foi licenciado de forma aberta e hoje encontra-se sob a licença GPL (GNU Public License). A FSF (Free Software Foundation) e outros grupos ligados a software livre são responsáveis pela manutenção e evolução do CVS.


1-12


Arquitetura

A arquitetura do CVS é essencialmente distribuída, projetada para um grande número de usuários, mas pode também funcionar em pequena escala, atendendo apenas um único usuário. O diagrama deste slide mostra algumas alternativas de configuração.

O diagrama mostra ao centro um servidor, conectado a um repositório, que é basicamente um diretório dentro de um sistema de arquivos. O repositório armazena os históricos dos arquivos mantidos sob o controle de versões.

O cenário (1) mostra a configuração mais simples para o uso do CVS. Um terminal simples conectado ao servidor acessa diretamente o repositório, como um diretório local. Mesmo sendo ele um diretório local, o usuário nunca edita diretamente os arquivos do repositório, mas sempre usa uma cópia local de trabalho. Esta configuração é adequada para usuários que desejam utilizar o CVS de forma individual, em sua própria estação de trabalho.

O cenário (2) exibe outra configuração, mais comum. Nela o servidor está em uma rede local e os clientes conectam-se a ele usando a rede como meio de transporte. Esta implantação já sugere algum tipo de autenticação dos usuários, para evitar acessos não-autorizados ao repositório. Também aqui, os arquivos são editados em cópias locais nas estações dos usuários. As alterações são propagadas para o repositório quando o usuário termina uma unidade de trabalho.

O cenário (3) ocorre em grandes projetos distribuídos, envolvendo participantes em diversos lugares e até em países diferentes. O servidor encontra-se em um determinado lugar, em um data center ou na sede da companhia, e os usuários acessam o repositório através da Internet. Este também é o caso de projetos open-source hospedados por serviços como SourceForge ou fundações como Apache e FSF. A autenticação é importante, mas nos casos de projetos open-source há também o acesso anônimo, que permite apenas a leitura de informações do repositório. Normalmente, o servidor está protegido por um firewall para evitar invasões.


1-13


Funcionamento Básico do CVS

• Eis um cenário que descreve uma sessão típica de uso do CVS, assumindo um repositório disponível:– João é destacado para trabalhar no projeto de um novo

sistema de cadastro de clientes para sua empresa– João faz um check-out do projeto, obtendo assim uma

cópia de trabalho com as últimas revisões do código– João compila o código, executa o sistema e identifica

um defeito no cadastro do endereço comercial– João edita um arquivo-fonte, testa novamente e verifica

que corrigiu o defeito– João submete sua alteração ao repositório, incluindo

um comentário que descreve o propósito da correção

A sessão descrita neste slide ilustra um cenário típico de uso do CVS. Antes de tudo, para se trabalhar em um projeto que está sob o controle de versões do CVS, é preciso obter uma cópia de trabalho. Normalmente, um programador irá obter a última versão dos arquivos-fontes presentes no repositório.

A partir daí, o ideal é que tudo aquilo que o programador precisa para desenvolver e contribuir para o projeto esteja disponível em sua cópia de trabalho. Isto é, não é necessário instalar outros softwares, copiar arquivos de outros diretórios, nem configurar variáveis de ambiente. Porém, isso nem sempre é possível.

Assumindo que o programador é capaz de compilar, executar e testar o sistema que ele estádesenvolvendo, ele pode encontrar algum defeito que deve corrigir ou implementar alguma requisição solicitada. Ao fazer isso, ele edita arquivos em sua cópia de trabalho e volta ao ciclo de compilação, execução e teste.

Uma vez satisfeito com seu trabalho, ele submete a alteração ao repositório. Nesta operação, écriada no repositório uma nova revisão para cada arquivo modificado. A partir deste momento, estas novas revisões estão disponíveis para qualquer outro desenvolvedor que criar uma nova cópia de trabalho ou atualizar sua cópia existente.

Uma observação: é importante que a alteração submetida pelo programador forme uma unidade coerente; isto é, se foi necessário realizar alterações em 3 arquivos para atingir seu objetivo, o programador deve submeter estas 3 alterações ao repositório. Caso contrário, imagine o que ocorreria na seguinte situação: uma alteração submetida em um arquivo depende de um novo método criado em outro arquivo, que não foi submetido. Na cópia de trabalho do programador, tudo funcionará bem, mas se outro programador atualizar sua cópia neste momento, o código não compilará. Portanto, são necessários bom senso e disciplina para se manter o repositório sempre em um estado coerente. O CVS não tem como forçar o usuário a fazer isso, mas oferece recursos para que ele perceba que está se esquecendo de submeter uma alteração.


1-14


Ilustração do Cenário Básico

Cria cópia

João : Autor

: Cópia de trabalho

Obtém alterações

: Repositório

Edita arquivo

Cria revisão

Check-out

Check-in

Este diagrama de seqüência (um diagrama da UML) ilustra o funcionamento do cenário que acabou de ser descrito. Cada caixa representa um papel no cenário. As linhas verticais representam o ciclo de vida de cada um dos participantes. As setas representam mensagens que são enviadas entre os participantes; neste caso, ações ou comandos que são executados. A seta pontilhada indica um tipo especial de mensagem, que é a criação de um participante; no caso, ela indica o repositório criando uma cópia de trabalho para o autor João.


1-15


Um Cenário Mais Complexo

• Eis um cenário um pouco mais complexo de uso do CVS, envolvendo mais de um usuário:– João acha um defeito na validação do cartão de crédito– Carlos, que também trabalha no projeto, implementa o

suporte a uma nova bandeira de cartões de crédito– Carlos termina suas alterações e as submete– João corrige o defeito e tenta submeter suas alterações– João é avisado que já existe no repositório uma nova

revisão para um dos arquivos que ele modificou e sua submissão falha

– João tem que atualizar sua cópia e resolver o conflito, mesclando as alterações feitas por ele e por Carlos

– João submete novamente o arquivo e tem sucesso

Em projetos com muitos programadores, é provável que, em algum momento, dois ou mais deles modifiquem o mesmo arquivo ao mesmo tempo, cada um em sua respectiva cópia de trabalho. O CVS permite que esta situação seja resolvida da forma descrita neste slide.

Em primeiro lugar, não existe o conceito de “trava” no CVS, ao contrário de outros sistemas de controle de versões. A operação de check-out apenas obtém uma cópia dos arquivos para que o programador trabalhe sobre eles; isto é, o check-out não reserva ao programador o direito de ser o único a alterar aqueles arquivos. Portanto, qualquer número de usuários pode modificar um mesmo arquivo ao mesmo tempo, de forma independente.

Como o CVS não monitora as cópias de trabalho dos usuários, ele deixa para que esta situação seja resolvida no momento da submissão das alterações, o chamado check-in. O primeiro programador a submeter a primeira alteração sobre o arquivo, não encontra problema algum, pois a última revisão no repositório é exatamente aquela sobre a qual ele trabalhou.

Entretanto, para os outros programadores, a situação é mais complexa. Quando um deles tentar submeter sua alteração, o CVS verificará que a revisão sobre a qual ele trabalhou não é a última disponível no repositório. Portanto, se o CVS aceitar as alterações daquele programador, elas podem desfazer o trabalho feito sobre a última revisão. Sendo assim, o CVS rejeita as alterações, dizendo que a cópia de trabalho deve ser atualizada antes da submissão. Ao fazer isso, o programador é conduzido a mesclar suas alterações com aquelas obtidas do repositório. Feito isso, ele pode novamente submeter suas alterações. Se nenhuma nova revisão tiver sido criada desde a atualização da cópia de trabalho, ele terá sucesso.


1-16


Ilustração do Cenário Complexo

Este outro diagrama de seqüência ilustra o cenário complexo. Notem como a interação de Carlos, o programador que fez o check-in mais cedo, acaba muito mais rápido. Por outro lado, é João, que recebeu o conflito, quem deve interagir com o repositório por um período bem mais longo, além de ter o trabalho de realizar a mescla de suas alterações com as de Carlos.


1-17


O Modelo Copia-Modifica-Mescla

• O modelo de funcionamento do CVS é chamado “copia-modifica-mescla”– Ele recebe este nome pela forma como autores

trabalham sobre os arquivos sob controle de versões:• Obtêm uma cópia da última revisão dos arquivos• Modificam como e quando bem quiserem• Ao submeter as alterações, podem encontrar conflitos; e, neste

caso, devem mesclar as alterações que geraram os conflitos

• Esse modelo se opõe ao “trava-modifica-destrava”– Travas impõem um funcionamento mais restritivo:

• Ao obter uma cópia de trabalho, um autor trava os arquivos• Enquanto ele modifica os arquivos, ninguém pode alterá-los• Ao submeter as alterações, ele destrava os arquivos

O modelo de funcionamento do CVS pode parecer muito liberal a princípio, mas na verdade ele estimula uma série de boas práticas de gestão de configuração.

Por exemplo, o “copia-modifica-mescla” favorece os autores que submetem suas modificações com mais freqüência. Em um projeto de software com o CVS, se um programador guardar suas alterações por muito tempo, ele sabe que poderá ter que realizar uma mescla para resolver conflitos. Esse pode ser um processo difícil, sobretudo se envolver muitos arquivos e se eles tiverem sido muito modificados. Portanto, o modelo adotado pelo CVS ajuda a diminuir riscos de integração e defeitos tardios. (Por vezes é necessário realizar as alterações em uma cópia à parte, sem afetar as revisões principais no repositório, ao menos por um período. Para isso, existem ramos, que viabilizam diferentes linhas de código ao mesmo tempo).

Outro problema evitado pelo CVS é a situação em que programadores travam os arquivos do repositório por um longo período apenas por “garantia”, causando inconvenientes ou atrasando o andamento do projeto. Pior ainda, acontecem casos em que desenvolvedores saem de férias ou deixam a empresa e “esquecem” suas cópias de trabalho travando arquivos do repositório.

Trabalhei muito tempo com o Rational ClearCase, que funciona no modelo “trava-modifica-destrava”. Várias vezes tive que intervir como administrador para remover travas feitas por programadores em férias ou que haviam deixado a empresa. Na verdade, o ClearCase permite tanto o uso do modelo “trava-modifica-destrava” (chamado por ele “check-out reservado”) quanto o “copia-modifica-mescla” (“check-out não-reservado”). O curioso é que todos os programadores optavam quando pelo check-out reservado, que lhes dava um sentimento (egoísta) de controle.

Também é curioso que, na mesma empresa, o modelo de funcionamento do CVS foi justificativa para se optar pela aquisição do ClearCase, pois a gerência julgava o CVS “muito permissivo” e, por isso, “inseguro”. Quando o excesso de check-outs reservados no ClearCase começou a comprometer o andamento de projetos, a mesma gerência determinou que todos passassem a realizar check-outs não-reservados, exatamente o criticado modelo de funcionamento do CVS.


1-18


Visita Guiada ao CVS

• Cenário 1– Fazemos o check-out de um módulo– Tomamos um arquivo e examinamos seu histórico– Editamos este arquivo na cópia de trabalho– Submetemos a modificação ao repositório– Verificamos a nova revisão no histórico do arquivo

• Cenário 2– Criamos outra cópia de trabalho– Submetemos uma modificação, agora desta cópia– Modificamos o mesmo arquivo na outra cópia– Tentamos submeter a modificação. O que ocorre?

Já falamos muito sobre o CVS e agora é hora de mostrá-lo funcionando na prática.

Vamos acompanhar o trabalho de um programador, João, e usar um repositório local para fazer o check-out de um módulo, que normalmente corresponde a um projeto. Para isso usamos o comando checkout. A linha de comando é:

C:\Joao> cvs –d C:\cvsrep checkout alomundo

Observe que o executável cvs recebe o comando como um parâmetro. Note também que especifico o repositório pela opção –d, que aparece antes do comando checkout. Esse comando criou uma cópia de trabalho no diretório C:\Trabalho\alomundo. Examinamos então o histórico do arquivo AloMundo.java:

C:\Joao\alomundo> cvs log AloMundo.java

Podemos também verificar o status desse arquivo e verificar que ele está atualizado:

C:\Joao\alomundo> cvs status AloMundo.java

Editamos esse arquivo na cópia de trabalho. Verificar o status novamente e observamos que ele encontra-se modificado. Submetemos então a alteração ao repositório:

C:\Joao\alomundo> cvs commit –m “Adicionei uma exclamacao” AloMundo.java

Verificamos novamente o histórico e observamos a nova revisão criada. Consultando o status doarquivo, vemos que ele está mais uma vez atualizado em relação ao repositório.

Partimos agora para outro cenário. Criamos outra cópia de trabalho, agora com outro programador, Carlos, que trabalhará no mesmo projeto. Verificamos que o arquivo AloMundo.java está atualizado e já contém a última alteração de João. Carlos altera novamente esse arquivo, incluindo uma nova linha, e submete a modificação.

João, por sua vez, altera novamente o arquivo e tenta submeter sua modificação. O que ocorreu?


1-19


Conceitos Básicos de GCS

• Repositório (Repository)• Módulo (Module, Projeto)• Área de trabalho (Workspace, Sandbox, Cópia de

trabalho)• Check-out (Retirar, Obter)• Check-in (Commit, Efetivar, Submeter)• Revisão (Revision)

Usaremos os cenários de uso vistos anteriormente para explicar os conceitos básicos de Gestão de Configuração de Software. Estes conceitos serão empregados ao longo de todo o curso, portanto, não devem ficar dúvidas quanto a eles.

Os conceitos são conhecidos por diversos nomes e apelidos. Muitas vezes, cada ferramenta de controle de versões traz sua nomenclatura, o que pode ser confuso. Procuraremos usar os nomes mais conhecidos e apresentamos sinônimos e os nomes em inglês, para que seja fácil identificar os conceitos em qualquer leitura. Os nomes que escolhemos estão à esquerda; sinônimos e versões em inglês estão entre parênteses. Os termos em inglês estão em itálico.


1-20


Repositório

• É o local onde o sistema de controle de versões armazena os históricos dos arquivos– Pode ser um banco de dados, ou um diretório especial

• Guarda também outras informações, tais como:– Usuários e senhas– Permissões (leitura, modificação)– Tipos dos arquivos (binário, texto)– Etiquetas e ramos– Travas (quando suportadas) e outros controles

• No CVS, o repositório é um diretório contendo:– Módulos, cada um com os históricos de seus arquivos– Um diretório administrativo, chamado CVSROOT

• O repositório pode ser especificado para qualquer comando CVS usando-se a opção global -d

Repositório é o local onde um sistema de controle de versões armazena os históricos dos arquivos, geralmente implementado por um banco de dados ou um diretório especial. O repositório guarda, além dos históricos, outras informações sobre os arquivos, como tipos (texto, binário), permissões (leitura, modificação) e outros atributos. Além disso, dados dos usuários (login e senha), informações sobre etiquetas e ramos (conceitos vistos logo adiante), bem como travas e outros tipos de controle são normalmente armazenados no repositório.

O repositório do CVS é um diretório que pode estar na própria máquina do usuário ou em um servidor remoto. Ele é composto por um diretório administrativo, chamado CVSROOT e por outros diretórios, cada um contendo um módulo, próximo conceito que veremos.

Os comandos do CVS precisam saber a localização do repositório. Aqueles que realizam uma primeira interação com o repositório (como checkout) esperam uma especificação pela opção global -d ou pela variável de ambiente $CVSROOT. Não confunda essa variável com o diretório administrativo CVSROOT – foi uma má idéia dar a ambos o mesmo nome. Os comandos que operam sobre uma área de trabalho podem obter essa informação de arquivos de controle locais. Veremos o que é a área de trabalho logo mais; conheceremos os arquivos de controle na parte mais avançada do treinamento.

No comando que invoquei para realizar o check-out, usei a opção –d. Ela é chamada “global” pois aparece antes do nome do comando, no caso, checkout. Podemos entender da seguinte forma: ela parametriza o CVS como um todo, não o comando sendo executado. Opções para um comando específico também existem, mas são incluídas depois do nome do comando.

Entrando no diretório C:\cvsrep, vemos os arquivos de histórico, com o sufixo ,v dentro do módulo que copiamos. Vemos também o diretório CVSROOT, no mesmo nível do módulo alomundo. Este diretório funciona como um módulo qualquer e pode ser obtido por um check-out. Os arquivos contidos nele são chamados “arquivos administrativos”. Mais adiante veremos a função de cada desses arquivos.


1-21


Módulo

• É uma unidade de trabalho independente, sob o controle de versões– Está associado a um sistema, componente ou projeto

• Um módulo bem projetado pode ser obtido do repositório e utilizado de forma isolada– Pode haver dependências entre os produtos de dois módulos: um

sistema S usa um componente C

• Um módulo tem seus próprios arquivos e atributos– Permissões, etiquetas e ramos existem por módulo

• No CVS, é um diretório sob a raiz do repositório– Módulos mais complexos podem ser definidos no arquivo

administrativo modules

• O nome do módulo é o parâmetro para checkout

Um módulo corresponde a uma unidade de trabalho independente sob o sistema de controle de versões e normalmente está associado a um sistema ou um projeto. É comum um módulo ser chamado de “projeto”.

Cada módulo tem seus próprios atributos, como permissões, etiquetas e ramos (definições adiante). No CVS, um módulo é simplesmente um diretório logo abaixo da raiz do repositório, ou uma entrada no arquivo administrativo modules. Este arquivo permite a definição de módulos mais complexos, tais como apelidos de módulos, módulos que apontam para um subdiretório de outro módulo, ou ainda módulos que excluem arquivos de outros módulos.

O nome do módulo é o parâmetro para o comando checkout e outros comandos que atuam diretamente sobre o repositório.


1-22


Área de Trabalho

• É onde o autor guarda seus arquivos de trabalho– Normalmente corresponde a um diretório local na

estação de trabalho do autor

• Contém cópias de revisões dos arquivos no repositório, daí outro nome: cópia de trabalho– Pode conter arquivos fora do controle de versões

• Na área de trabalho, o autor:– Edita arquivos sob o controle de versões– Cria e adiciona novos arquivos ao controle de versões– Obtém novas revisões de arquivos no repositório– Realiza outras operações sobre o módulo, como criar

etiquetas e ramos, observar alterações em arquivos

A área de trabalho é o local onde o autor guarda os arquivos que ele utiliza para trabalhar. Na terminologia do CVS, ela é chamada cópia de trabalho (working copy), ao passo que outras ferramentas usam nomes como workspace, view ou sandbox. Em geral, a área de trabalho é uma árvore de diretórios no disco local da máquina do autor e contém tanto arquivos mantidos sob o controle de versão como arquivos gerados e temporários, dos quais não se guarda o histórico. Por exemplo, para um programador Java, a área de trabalho contém versões de arquivos fonte (arquivos .java) obtidos do repositório e arquivos gerados localmente, como classes (arquivos .class) e bibliotecas de classes (arquivos .jar). Áreas de trabalho são individuais, isto é, não devem ser compartilhadas por dois ou mais autores.

No CVS, uma área de trabalho é uma árvore de diretórios criada pelo comando checkout e que reflete a estrutura do módulo no repositório. Normalmente, a raiz da área de trabalho tem o mesmo nome do módulo, mas isso pode ser alterado com um parâmetro para checkout. Basicamente, o que diferencia uma área de trabalho de uma árvore de diretórios normal é a presença dos diretórios chamados CVS em cada subdiretório da árvore. Esses diretórios contém os arquivos de controle da área de trabalho, que são usados para controlar o status da cópia. Entenderemos mais adiante que tipo de status é mantido nesses arquivos e veremos em maiores detalhes o seu formato.


1-23


Check-Out

• É a ação que traz revisões do repositório– Quando executada pela primeira vez, cria a área de trabalho– Se executado sobre uma área de trabalho existente, atualiza as

cópias dos arquivos

• Em geral, um check-out obtém as revisões mais recentes no repositório. O CVS permite também obter revisões:– Por uma data (p.e., todas as revisões em 23/07/2005, 15:13h)– Marcadas por uma etiqueta (p.e., revisões marcadas REL_2-1)– Em um ramo (p.e., últimas revisões no ramo defeitos_2-0)– Pelo seu número identificador (p.e., a revisão 1.2 de um arquivo)

• No CVS, um check-out não trava as revisões obtidas• O comando update também traz revisões do repositório

– Só pode ser usado sobre áreas de trabalho existentes

Check-out é a ação que traz arquivos do repositório para a cópia de trabalho, permitindo ao usuário alterá-los. Quando um check-out é realizado pela primeira vez, sem que exista ainda uma área de trabalho, ele cria essa área. No CVS, isso acontece quando chamamos o comando checkout. Um check-out também pode ser executado sobre uma área de trabalho existente, aí com o propósito de atualizar as cópias dos arquivos com revisões mais recentes no repositório.

Além de obter revisões mais recentes, o CVS permite que um check-out traga para a cópia de trabalho revisões especificadas por critérios variados. Por exemplo, é possível obter as revisões existentes em um instante do tempo, tal como 23/07/2005, às 15:13h. Esse check-out trará as revisões existentes naquele momento, isto é, as últimas revisões criadas antes daquele instante. Essa opção é útil para se inspecionar o estado do projeto em um dado momento. Pode-se também trazer as revisões marcadas por uma etiqueta (definição adiante), ou as últimas revisões dentro de um ramo de código. Uma opção bem menos utilizada é obter revisões com base em seu número identificador. Como cada arquivo tem seu próprio histórico, essa opção é normalmente usada para se obter um único arquivo.

Como vimos, o CVS, ao contrário de outras sistemas de controle de versão, permite que vários usuários façam o check-out de um mesmo arquivo e o editem independentemente, deixando a resolução de eventuais conflitos para o momento do check-in (definido adiante). O check-out no CVS, portanto, não trava revisões. Isso não quer dizer que não exista o conceito de trava no CVS. Essa possibilidade existe: é possível que um usuário trave arquivos no CVS, impedindo que outros façam alterações nesses arquivos enquanto ele detém a trava. Entretanto, esse é uma ação com propósitos administrativos, não faz parte do dia-a-dia e nem é recomendada. Veremos adiante o comando admin e sua opção –l.

O comando do CVS usado para se realizar um check-out é, intuitivamente, checkout. Para atualizar áreas de trabalho já existentes, é mais comum usar-se o comando update (também intuitivo), apesar de também ser possível nesse caso usar checkout.


1-24


Check-In

• É a ação que submete ao repositórioalterações feitas sobre um ou mais arquivos– As alterações devem ser feitas em uma área de trabalho, de onde

o check-in envia as modificações

• Um check-in com sucesso sempre cria no repositório uma nova revisão para cada arquivo alterado– A nova revisão fará parte da linha de código em uso na área

• Para que um check-in tenha sucesso, a área de trabalho deve estar atualizada em relação a sua linha de código– Uma tentativa de check-in de um arquivo desatualizado força uma

atualização da cópia e uma mescla das modificações

• No CVS, o comando commit faz o check-in de alterações– O apelido desse comando (ci) faz referência ao termo check-in

A ação de efetivar no repositório alterações em um ou mais arquivos é chamada check-in ou, na terminologia específica do CVS, commit. Enquanto um check-out pode ser realizado sem uma área de trabalho, o check-in depende de uma para executar. Isso não é um problema, pois é na própria área de trabalho que as alterações devem ser realizadas. Tirar um arquivo dessa área inviabiliza tarefas como verificar seu status (atualizado, desatualiza, modificado) e o próprio check-in, pois esses comandos inspecionam os arquivos de controle. Para se criar revisões usando arquivos fora de uma área de trabalho (arquivos novos ou fornecidos por um terceiro), o comando a ser usado é import, que veremos mais à frente no treinamento.

Um check-in com sucesso sempre cria uma nova revisão do arquivo no repositório, com o conteúdo do arquivo na cópia de trabalho. Uma revisão nunca é sobrescrita no repositório. Observem a saída do comando commit. Ela mostra qual era a revisão na área de trabalho e qual revisão foi criada pelo check-in. A nova revisão será a sucessora da revisão que estava presente na área de trabalho, dentro da linha de código em uso nessa área. Linhas de código são conceitos mais avançados; por enquanto podemos imaginar que existe apenas uma linha de trabalho, isto é, a sucessão de revisões é totalmente linear.

Já vimos que, para que o check-in tenha sucesso, a cópia do arquivo alterado na área de trabalho deve estar atualizada com relação ao repositório. Se tentarmos fazer o check-in de um arquivo desatualizado, receberemos um erro e seremos forçados a atualizar a cópia, fazer uma mescla e sódepois tentar um novo check-in.

O comando CVS correspondente ao check-in é commit, mas seu apelido é ci, uma abreviação de check-in.


1-25


Revisão

• É cada um dos estágios na evoluçãode um arquivo sob o controle de versões– O conjunto de revisões de um arquivo é seu histórico

• O CVS armazena revisões no seu repositório, em arquivos de histórico (arquivos RCS)– Um arquivo de histórico tem o mesmo nome do arquivo

versionado, seguido de ,v (vírgula vê)– Apenas as diferenças (deltas) entre as revisões são armazenados,

não as revisões inteiras (exceto binários)

• No CVS, revisões são identificadas por uma seqüência par de números inteiros, separados por pontos– Por exemplo, 1.2 e 1.3.2.15 são revisões válidas, 1.3.2 não é

1.1

Uma revisão é um estágio na evolução de um arquivo que se encontra sob o controle de versões. Cada revisão é criada em um dado instante do tempo; o conjunto ordenado de revisões de um arquivo forma o que chamamos de histórico. Como visto na definição de check-in, a cada vez que um arquivo é modificado e a alteração é propagada para o repositório, é criada uma nova revisão daquele arquivo.

Para cada arquivo mantido sob o controle de versões, o CVS armazena seu histórico em um arquivo correspondente. Este arquivo é chamado (apropriadamente) “arquivo de histórico” ou “arquivo RCS” (pois seu formato for herdado do RCS). O arquivo de histórico tem o mesmo nome do arquivo versionado, seguido de ,v (isso mesmo, uma vírgula, seguida da letra “v”). O CVS usa um algoritmo inteligente para armazenar os históricos, guardando apenas as diferenças (chamadas deltas) de uma revisão para a outra. Isso funciona bem para arquivos texto, mas não para binários, que precisam ser repetidos integralmente a cada revisão. Na parte avançada do curso, entenderemos o formato dos arquivos no repositório.

No CVS, as revisões são identificadas por uma seqüência de números inteiros, separados por pontos. A seqüência deve ter um tamanho par para ser um número de revisão válido. Por exemplo, 1.2 e 1.3.2.15 são números de revisões, mas 1.3.2 não é. Para facilitar sua identificação, as revisões podem ser marcadas com etiquetas, chamadas também “revisões simbólicas” (veremos a definição adiante). Podemos ver os números de revisão criados por cada check-in olhando para a saída do comando commit.


1-26


Outros Conceitos de GCS

• Mescla (Merge)• Conflito (Conflict)• Liberação (Release, Version, Versão)• Etiqueta (Tag, Label)• Linha de código (Codeline)• Ramo (Branch)• Perfis envolvidos em GCS

Estes são conceitos mais avançados, que não são usados normalmente no dia-a-dia, mas que são muito importantes para a gestão de configuração, pois lidam com aspectos de mais alto nível, tais como mesclas, liberações de novas versões do sistema, marcação de estágios relevantes do progresso do sistema e de abertura para o desenvolvimento de mais de uma versão em paralelo. Vemos aqui também os perfis de profissionais envolvidos nas atividades de gestão de configuração de software.


1-27


Mescla

• É o processo de se combinar duas revisões de um arquivo, produzindo uma nova revisão– Só faz sentido mesclar revisões de um mesmo arquivo!

• Diante de modificações independentes, o CVS tenta realizar uma mescla automática– O algoritmo de mescla foi uma das razões da criação do CVS– Ele vê o ancestral comum e procura uma combinação das revisões

• Entretanto, a mescla falha se as modificações foram feitas em regiões próximas do arquivo– Esta situação é chamada conflito (definido adiante)– Neste caso, o algoritmo cria um arquivo com uma mescla parcial,

marcando a região problemática– O autor diante do conflito deve resolvê-lo com uma mescla manual

Mescla é o processo que, a partir de duas revisões de um mesmo arquivo, produzidas por modificações independentes, produz uma nova revisão, procurando preservar as modificações na revisão resultante. Devido à mecânica de funcionamento do CVS, o copia-modifica-mescla, a necessidade de uma mescla de revisões surge de tempos em tempos em projetos que contam com mais de um autor. O cenário de mescla mais comum é a alteração simultânea de um mesmo arquivo por mais de um autor, como já vimos (outro cenário ocorre quando trabalhamos com ramos). Quando um autor está com sua cópia local desatualizada e tenta submeter modificações, ele é forçado a fazer manualmente uma mescla de suas modificações com as alterações presentes na última revisão do arquivo no repositório.

Na verdade, a mescla manual nem sempre é necessária. Quando o CVS encontra duas modificações independentes em um arquivo, ele tenta em primeiro lugar uma mescla automática. Este foi um dos recursos que motivou a criação do CVS: permitir a combinação automática de modificações feitas por programadores diferentes. O algoritmo de mescla será visto em maiores detalhe na parte avançada do curso, mas podemos entender de forma geral como ele funciona:

O CVS identifica a revisão ancestral às modificações independentes. No cenário que vimos, ela éa revisão base do arquivo na cópia de trabalho do autor. O CVS localiza, em relação à revisão ancestral, onde foram feitas as modificações. A mescla automática tem sucesso se as modificações foram feitas em locais distantes do arquivo. Se elas foram feitas próximas (o quão próximo depende de vários fatores), o algoritmo automático falha.

Caso a mescla automática falhe, temos um conflito (o próximo conceito que veremos). O algoritmo produz então um arquivo com uma mescla parcial. Esse arquivo tem como propósito ajudar o autor a resolver manualmente o conflito.

O algoritmo de mescla automática do CVS encontra-se disponível no utilitário diff3 da GNU, cuja documentação pode ser encontrada em http://www.gnu.org/software/diffutils/diffutils.html. Ele tem esse nome porque usa 3 arquivos na comparação: as 2 cópias conflitantes e a cópia ancestral.


1-28


Mescla: Ilustração

Este diagrama ilustra um processo de mescla. Neste cenário, o autor trabalhava com a revisão 1.3 em sua cópia de trabalho, mas já havia sido criada no repositório uma revisão 1.4. Ao ter seu check-in negado, ele foi forçado a atualizar sua cópia local, o que disparou a mescla das revisões 1.3’ (a revisão 1.3 alterada localmente) e 1.4.

Independente da mescla ter ocorrido de forma automática ou manual, ela produz uma revisão 1.4’(a revisão 1.4, com alterações locais). Essa revisão está em sincronia com o repositório, cuja última revisão é ainda 1.4. O autor pode então submeter as alterações ao repositório, o que criaráuma nova revisão, 1.5. A cópia de trabalho passará então a estar atualizada com o repositório, ambas na revisão 1.5.


1-29


Conflito

• É a situação que ocorre quando uma mescla não pode ser realizada automaticamente– O algoritmo de mescla salva uma cópia do arquivo com

os trechos conflitantes de ambas as revisões– Cabe então ao autor resolver apropriadamente o

conflito, produzir uma cópia consistente e submetê-la

• O CVS não tem controle sobre a mescla manual– A única verificação que o CVS faz para evitar o check-in

de arquivos parciais é a data de alteração do arquivo• Ela deve ser mais recente do que o momento da mescla parcial

• Ferramentas dão suporte visual à mescla manual– Exemplo: Guiffy

Vimos que, diante de uma situação em que uma mescla é necessária, o CVS procura conciliar automaticamente as alterações paralelas. Entretanto, em algumas situações, isso não é possível. Por exemplo, caso as alterações tenham sido feitas sobre o mesmo trecho do arquivo, o algoritmo de mescla não saberá qual das duas manter. De forma semelhante, se as alterações mudam significativamente a estrutura do arquivo, o CVS não conseguirá conciliá-las. Nesses casos, diz-se que existe um conflito. Um conflito deve ser resolvido realizando manualmente a mescla das alterações.

Quando ocorre um conflito, o arquivo produzido pelo algoritmo de mescla traz os trechos conflitantes marcados com <<<<<<<, ======= e >>>>>>>. Esses são marcadores usados para indicar qual trecho veio de qual revisão. O CVS não oferece nenhum recurso ou ferramenta para auxiliar a resolução de conflitos; cabe ao autor inspecionar os trechos, julgar o que deve ser mantido, remover os marcadores e salvar o arquivo. O CVS não tem controle algum sobre esse processo; ele é de responsabilidade do autor que se vê diante do conflito.

Entretanto, existem ferramentas visuais que auxiliam a realização de mesclas manuais, tais como o Guiffy (http://www.guiffy.com/). Veremos neste treinamento que ferramentas podem ser usadas para tornar o uso do CVS mais ameno. Sistemas comerciais de controle de versões, tais como o ClearCase, são integrados a ferramentas visuais de mescla.


1-30


Liberação

• Um projeto é formado por vários arquivos– Cada arquivo tem seu próprio histórico de evolução, mas evolui em

ritmo diferente dos outros– A questão é: como identificar um conjunto de revisões em um

projeto que forma um todo coerente?• Podem existir vários conjuntos coerentes...

• Uma liberação é um conjunto coerente de revisões que érelevante para o projeto– Normalmente, liberações marcam etapas no ciclo de

desenvolvimento de um sistema (milestones)• Por exemplo, a versão 2.0 Beta, ou a versão 2.1 Final

• Para criar uma liberação, é preciso marcar cada revisão que deve fazer parte dela– O mecanismo usado para isso é a etiqueta, definição adiante

2.0 Beta

Cada arquivo de um projeto tem seu histórico de evolução. Alguns arquivos, por serem muito centrais ou muito problemáticos, acabam tendo muito mais revisões ao longo do tempo. Outros jámudam muito pouco. Como conseqüência, as linhas de evolução dos arquivos são muito irregulares: algumas muito longas, outras curtas. Além disso, um arquivo que pouco mudou em uma fase do projeto pode passar a ser modificado com mais freqüência.

Pensando especificamente em projetos de software, os arquivos mudam em conjunto, logo, hárevisões que só funcionam dentro um certo contexto. Por exemplo: se temos um projeto com os arquivos Pais.java, Estado.java e Cidade.java, é possível que uma alteração em Pais.java (por exemplo, a remoção de um método) provoque uma alteração em Estado.java para que este continue funcionando corretamente. Portanto, deve ser possível especificar que versão de Estado.java funciona em conjunto com uma dada versão de Pais.java, para que não surjam inconsistências.

Não é viável marcar todos os conjuntos consistentes de revisões em um projeto. Ao contrário, marcamos somente aqueles que são relevantes para o projeto. A esses conjuntos consistentes e relevantes, damos o nome de liberação. Em geral, liberações marcam etapas relevantes no ciclo de vida do projeto (os chamados milestones). Por exemplo, podemos imaginar a liberação da versão 2.0 Beta do sistema, enviada para testes, ou a versão 2.1 Final, enviada para o cliente.

Podemos estabelecer a seguinte analogia: liberações estão para um projeto assim como revisões estão para um arquivo. A ferramenta que se usa para marcar as revisões participantes em uma liberação é a etiqueta, cuja definição veremos adiante.


1-31


Liberação: Antes da Marcação

1.1

1.2

Estado.java

1.1

1.2

1.3

1.4

Pais.java

1.1

1.2

1.3

1.4

Cidade.java

1.1

1.2

1.3

1.4

Teste.java

1.5

1.6

1.5

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.


1-32


Liberação: Após a Marcação

Esta ilustração mostra a marcação de uma liberação: as revisões coerentes foram “alinhadas” e marcadas com a etiqueta “2.1 Final”.


1-33


Etiqueta

• Nome que pode ser dado a uma revisão, para facilitar sua identificação– É também chamado “revisão simbólica” ou “rótulo”

• É usada para marcar liberações, identificar revisões testadas, indicar revisões com defeito– O nome de uma etiqueta deve descrever seu propósito

• Uma etiqueta só pode marcar uma única revisão de cada arquivo

• É comum que uma etiqueta marque todos os arquivos de um módulo– Entretanto, isso não é obrigatório

Etiqueta é um nome simbólico que pode ser associado a uma certa revisão de um arquivo, para facilitar sua identificação. Na terminologia do CVS, usa-se o nome inglês tag e também “revisão simbólica”, ao passo que outras ferramentas usam o termo “rótulo” (em inglês, label).

O nome da etiqueta deve ser claro e descritivo, pois este é o objetivo da etiqueta: descrever melhor revisões relevantes. Etiquetas podem ser usadas, por exemplo, para identificar revisões que passaram por um teste, ou para marcar revisões que têm algum defeito e devem ser corrigidas.

Se um arquivo recebe uma etiqueta, somente uma de suas revisões pode ser marcada. Isto é, não épossível que uma etiqueta marque duas ou mais revisões de um mesmo arquivo; ou ela marca apenas uma, ou não marca nenhuma.

Uma etiqueta pode ser aplicada sobre somente um ou sobre alguns poucos arquivos do repositório. Porém, o emprego mais útil de uma etiqueta é aplicá-la sobre todos os arquivos de um módulo, de forma a marcar uma liberação do projeto ou sistema.

O CVS permite que etiquetas sejam movidas de uma revisão para outra de um mesmo arquivo. Isso é interessante, por exemplo, se incluímos uma correção de última hora em uma liberação que já havia sido marcada. Nesse caso, a revisão que corrige o defeito é mais recente que a revisão problemática, marcada com a etiqueta. Portanto, deve-se mover a etiqueta da revisão original para a nova revisão, de forma a ajustar a liberação.

No CVS, etiquetas podem ter qualquer nome, exceto pelos nomes reservados HEAD e BASE e por alguns caracteres proibidos, como “.”. Por convenção, usamos neste treinamento letras maiúsculas para nomes de etiquetas.


1-34


As Etiquetas Virtuais BASE e HEAD

• O CVS disponibiliza duas etiquetas “virtuais”

• Revisão base: BASE– A revisão na qual a cópia de

trabalho está baseada– É a revisão obtida pela

última atualização da área

• Revisão cabeça: HEAD– A última revisão do arquivo

no repositório– Leva em consideração a

linha de código em uso

• Podem ser usadas como qualquer outra etiqueta

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 parâmetro que espera um número de revisão ou um nome de uma etiqueta (em geral, é o parâmetro –r).

As revisões base e cabeça podem ser inspecionadas usando-se o comando status. Veja o seguinte trecho de saída desse comando:

Working revision: 1.3

Repository revision: 1.4

Esse trecho mostra que a revisão base é 1.3, enquanto a cabeça é 1.4. Cuidado com opções aderentes (conceito visto adiante); elas podem dar a impressão que a revisão cabeça é menor do que realmente é.


1-35


Linha de Código

• É a evolução dos arquivos de um módulo– Engloba todas as revisões dos arquivos do módulo– Uma linha de código está para um módulo assim como um

histórico está para um arquivo

• A progressão das revisões em uma linha de código é linear– Dado um instante no tempo, uma linha de código tem apenas uma

revisão de cada arquivo

• Pode ser necessário criar bifurcações de uma linha de código, para permitir a evolução paralela de revisões– Por exemplo, para se corrigir os defeitos da versão 1 de um

sistema, enquanto já se trabalha na versão 2

• Uma área de trabalho está associada a uma e somente uma linha de código

• Todo módulo tem uma linha principal, chamada tronco

Linha de código é a progressão das revisões dos arquivos de um módulo, ou seja, o conjunto de históricos dos arquivos que fazem parte de um projeto. Podemos fazer a seguinte analogia: uma linha de código está para um módulo assim como um histórico está para um arquivo.

No cenário mais simples, um módulo tem apenas uma linha de código. Isso quer dizer que, em um dado momento do tempo, existe apenas uma revisão para cada arquivo do módulo, isto é, a progressão das revisões é linear. Porém, os bons sistemas de controle de versão (entre os quais o CVS) permitem que as linhas de código tenham bifurcações, viabilizando o desenvolvimento paralelo. O melhor exemplo da necessidade de desenvolvimento paralelo é uma equipe que precisa consertar defeitos na liberação 1 de um sistema, ao mesmo tempo em que já trabalha na versão 2. Uma bifurcação em uma linha de código é chamada ramo, o próximo conceito.

Um área de trabalho está sempre associada a uma e somente uma linha de código. Isso quer dizer que um programador está sempre trabalhando em uma única linha de código por área de trabalho; não é possível “misturar” as linhas. Obviamente, é possível que um mesmo programador trabalhe em duas linhas de código ao mesmo tempo, mas para isso ele precisa criar duas áreas de trabalho distintas. Por exemplo, ele pode ter um diretório “Bugs”, onde ele armazena a linha de correção de defeitos da versão 1 do sistema, e um diretório “Projetos”, onde ele armazena a linha de criação da versão 2. O CVS permite que façamos o check-out de uma linha de código específica.

Todo módulo tem uma linha principal, que é chamada tronco. Este nome vem da analogia com uma árvore: a linha de código principal é o tronco, enquanto as linhas derivadas são os ramos. O tronco é a linha de código que existe assim que se cria um módulo. Muitos projetos podem viver somente com um tronco, sem ramos. Se um projeto tiver a necessidade de ser ramificado, o tronco continua existindo e os programadores devem cuidar para que ele continue evoluindo. Por exemplo, no caso do projeto que tem defeitos a serem corrigidos, o tronco deve ser a evolução da versão 2. Os defeitos corrigidos no ramo de correção da versão 1 devem ser propagados para o tronco, garantindo que ele sempre evolua.

No CVS, o tronco pode ser facilmente identificado. As revisões pertencentes a ele são aquelas com apenas dois inteiros (por exemplo, 1.1, 1.5, 2.3, 3.8...)


1-36


Ramo

• É uma derivação da linha de código principal– Seu propósito é permitir a evolução paralela (concorrente) de

revisões de um mesmo arquivo• Algumas situações para o emprego de ramos:

– Criação de uma nova versão de um sistema em paralelo com correção de defeitos na versão anterior

– Grande reescrita de um sistema, de longa duração, em paralelo com pequenos requisitos e/ou defeitos

– Incorporação de código fornecido por um terceiro• No CVS, ramos são tipos especiais de etiquetas

– A diferença é que um ramo pode marcar mais de uma revisão por arquivo: ele marca todas as revisões de uma linha de código

• Dentro de um histórico CVS, ramos são identificados por uma seqüência ímpar de inteiros, separados por pontos– Por exemplo, 1.3.2 e 1.5.32.7.10 são números válidos de ramos

Um ramo (inglês, branch) é uma derivação, ou variante, da linha principal de código. O propósito de um ramo é permitir a evolução paralela de revisões de um mesmo arquivo. Como vimos hápouco, uma motivação típica para se criar um ramo é a necessidade se corrigir defeitos na versão 1 de um sistema, enquanto já se iniciou o desenvolvimento da versão 2.

Existem outras situações que demandam o uso de ramos. Por exemplo, se um sistema irá passar por uma evolução muito grande (devido a um requisito muito especial ou a uma reescrita do código) e que deixará um código “instável” por um tempo mais longo, pode ser interessante criar um ramo para esta evolução. Isso impede que o tronco fique “congelado” e permite que, se forem descobertos defeitos nele durante a evolução da nova versão, eles possam ser corrigidos de forma rápida. Outra situação que pede o uso de ramos é quando se recebe o código fornecido por uma empresa terceirizada (inclusive, foi esta a motivação para a criação de ramos no CVS).

No CVS, um ramo é um tipo especial de etiqueta. Portanto, os nomes de ramos devem ser descritivos, assim como etiquetas, e estão sujeitos às mesmas regras. Neste treinamento, convencionamos usar letras minúsculas para nomes de ramos (enquanto que, para etiquetas normais, usamos letras maiúsculas). A diferença principal de um ramo para uma etiqueta é que, enquanto uma etiqueta marca apenas uma revisão de cada arquivo, um ramo marca um conjunto de revisões em seqüência, formando assim uma linha alternativa de código.

No CVS, dentro do histórico de um arquivo, os ramos são identificados por números. Um número de ramo é sempre formado por uma quantidade ímpar de números inteiros, separados por pontos. Por exemplo, 1.3.2 e 1.5.32.7.10 são números válidos de ramos. O número do ramo é formado pela revisão a partir da qual foi feita a bifurcação (1.3 e 1.5.32.7, no exemplo).

Também, no CVS, existe o conceito do ramo padrão (default branch). Cada arquivo tem um ramo padrão, aquele utilizado quando se faz um check-out do arquivo sem se especificar ramo algum. Quando um módulo é criado, o tronco é o ramo padrão para todos os arquivos. Como veremos na parte avançada do treinamento, isso pode ser alterado pelo comando admin, usando-se a opção –b, mas é perigoso e quase nunca necessário.


1-37


Perfis Envolvidos em GCS

• Administrador de sistemas– Preparação do ambiente, instalação e configuração de

máquinas, sistemas operacionais, ferramentas, etc.

• Gestor de configuração– Definição da política de GCS

• Gerente/coordenador de projeto– Criação de projetos, definição de autores e permissões,

conduz a comunicação entre os demais perfis

• Autor– Obtenção de arquivos, submissão de modificações– Autores de nível sênior definem liberações e ramos

Este slide destaca os principais perfis envolvidos na atividade de Gestão de Configuração de Software. Os módulos seguintes deste treinamento serão direcionados para cada um desses perfis.

O administrador de sistemas, ou administrador do CVS é o responsável por preparar o ambiente para a utilização do sistema, envolvendo a instalação do CVS, a configuração de servidores, sistemas de suporte, implementação de políticas de segurança, disponibilização de ferramentas, entre outras atividades relacionadas.

O gestor de configuração é o responsável por definir a política de gestão de configuração da empresa, participando de comitês de qualidade e auxiliando na definição de processos. Existe um documento do IEEE para a especificação de políticas de GCS.

O gerente ou coordenador de projetos é quem cria os projetos e define quais autores estarão envolvidos em cada um deles, incluindo permissões dos mesmos. Ele tem contato com todos os outros perfis, mas principalmente com o gestor de configuração, com o qual define a política de GCS que será aplicada às linhas de código do projeto.

Por fim, o perfil mais importante é o autor, o usuário do sistema de controle de versões. Ele obtém arquivos do SCV, submete modificações, examina históricos, etc. Em projetos de software, um autor é um programador. Autores de nível sênior são responsáveis por definir liberações do projeto, decidir quando e como criar ramos.


1-38


Comandos CVS

• O CVS possui apenas um executável, que recebe comandos como parâmetro

• Os comandos têm uma forma geral:– cvs [op_glob] comando [op_cmd] [args]

• Onde:– cvs é o nome do executável do CVS– op_glob são opções globais, que afetam todos os

comandos CVS– comando é o nome ou apelido do comando invocado– op_cmd são opções específicas do comando– args são argumentos do comando, tais como arquivos

sobre os quais ele opera

Como o CVS é uma ferramenta essencialmente de linha de comando, seria complicado disponibilizar um executável para cada operação que pode ser realizada. Portanto, ele possui apenas um executável, que recebe os comandos (operações) como parâmetro.

Todos os comandos seguem uma forma geral. A chamada tem o formato mostrado neste slide. A única parte fixa dos comandos é o nome do executável do CVS. Os elementos em itálico devem ser substituídos por parâmetros reais, por exemplo, comando deve ser substituído por checkout, commit, etc.). Itens entre colchetes são opcionais.

Por vezes, os usuários do CVS confundem opções globais com opções de comando. Algumas opções globais (por exemplo, –d) têm o mesmo nome que opções de comando, mas significados completamente diferentes. O importante para perceber a diferença é observar que opções globais aparecem logo após o cvs, antes do comando: afetam portanto, o CVS como um todo. Já opções de comando aparecem logo após o nome do comando: afetam portanto, o comando especificado.

Outra observação: cada comando define suas próprias opções, com significados específicos para aquele comando. Entretanto, existem parametrizações comuns a diferentes comandos como, por exemplo, se o comando deve executar de forma recursiva ou não. Nesses casos, o CVS usa o mesmo nome de opção para os diversos comandos que a utilizam. Por exemplo, a opção –R força o comportamento recursivo em diversos comandos aos quais ela se aplica.


1-39


Algumas Opções Globais

• Algumas opções globais do CVS são usadas com maior freqüência e merecem destaque:– –d rep: Especifica o repositório utilizado, como um

diretório local ou no seguinte formato:• [:método:][usuário[:senha]@][servidor[:porta]]raiz

– –n: Não realiza nenhuma operação, útil para testes– –q e –Q: Suprime a impressão de mensagens na saída– –r: Faz com que todos os arquivos de trabalho sejam

criados para somente leitura– –z nível: Comprime a comunicação com o servidor

Este slide destaca algumas opções globais do CVS. Este treinamento não visa passar por todas as opções do CVS, pois não teríamos tempo para isso e provavelmente nos esqueceríamos logo depois; para isso existem os guias rápidos!

Talvez a opção global mais usada é –d, que especifica o repositório a ser usado. Ela é necessária sempre que executarmos um comando fora de uma área de trabalho. A variável de ambiente $CVSROOT pode ser usada em vez dessa opção, para evitar a necessidade de digitar repetidamente a localização do repositório, sobretudo quando existe apenas um repositório. A localização é especifica no formato mostrado neste slide. No módulo de administração, veremos quais são os métodos disponíveis.

A opção –n faz com que o CVS apenas imprima o que o comando faria, mas não execute modificação alguma. Ela é útil para testes como, por exemplo, verificar quais arquivos estão modificados ou seriam atualizados em uma cópia de trabalho, mas sem executar um update.

As opções –q e –Q fazem com que o CVS execute “quieto”. O uso de –q faz com que apenas mensagens muito importantes (por exemplo, de erros) sejam impressas, enquanto que –Q faz com que nenhuma saída seja gerada.

A opção –r faz com que arquivos de trabalho sejam criados para somente leitura. Isso é útil para se criar cópias de trabalho que não possam ser modificadas. Outra opção é definir a variável de ambiente $CVSREAD na máquina cliente. Caso essa variável seja definida, a opção –w pode ser usada para contrapor seu efeito.

Por fim, a opção –z comprime, usando o gzip, a comunicação com o servidor. Ela recebe um parâmetro indicando o nível de compressão, assim como o programa gzip: 0 para nenhuma compressão, até 9 para compressão máxima.


1-40


Recursos Gerais do CVS (1)

• Repositório como um sistema de arquivos normal– Permite configurações de permissões usando recursos

do sistema operacional– Viabiliza inspeção e edição direta de históricos

• Comportamento recursivo– A grande maioria dos comandos se aplica

recursivamente a diretórios– Simplifica o uso de comandos como update e commit

• Opções aderentes à área de trabalho– Algumas opções ficam gravadas na área de trabalho– Não precisam ser especificas a cada novo comando

Para fechar nossa visão geral de gestão de configuração e CVS, vamos passar por alguns recursos gerais que o CVS oferece. Isso vai nos dar uma noção melhor do funcionamento do CVS e ajudar a entender alguns comandos, opções e arquivos de configuração. Em primeiro lugar, uma das características que torna o CVS simples e poderoso é o fato do seu repositório ser uma árvore de diretórios normal em um sistema de arquivos. Com isso, permissões e segurança podem ser controladas usando-se os recursos do sistema operacional onde o repositório está localizado. Os históricos, por sua vez, são arquivos comuns, o que nos deixa aberta a possibilidade de editá-los diretamente para contornar problemas.

A grande maioria dos comandos CVS têm por default um comportamento recursivo. Isto significa que, quando executados sobre um diretório, eles se aplicam a todos os arquivos debaixo daquele diretório, recursivamente. Estes mesmos comandos, quando executados sem argumentos, aplicam-se ao diretório corrente e, portanto, a todos os arquivos nele e em subdiretórios dele. Isso éinteressante para diversos comandos, como update e commit, mas pode ser perigoso para outros. É possível mudar esse comportamento usando-se a opção –l (a letra “ele”, de local). Essa opção pode inclusive ser configurada para se aplicar a todos os comandos, colocando-a no arquivo de configuração pessoal .cvsrc, que veremos adiante. Nesse caso, para desligá-la, a opção –R deve ser usada.

Os arquivos que controlam a área de trabalho (aqueles sob os diretórios CVS) podem guardar algumas opções para que elas não precisem ser especificadas a cada comando. As opções que têm essa característica são chamadas de “aderentes”. Em inglês, usa-se o termo sticky option. Exemplos de opções com essa característica são: a especificação de etiquetas e ramos a serem usadas na área de trabalho (opção –r), idem para datas (opção –D), ou para palavras-chave (citadas a seguir, opção –k). Para “limpar” essas opções, usa-se a opção –A em update.


1-41



• Substituição de palavras-chave– Informações sobre as revisões podem ser incluídas

dentro de arquivos mantidos sob o controle do CVS– Expressões como $Revision$, $Date$ e $Author$

são expandidas para os valores correspondentes– Pode ser controlada por arquivo (a chamada opção–k)

• Arquivos ignorados por padrões de nome– Arquivos que não serão nunca adicionados ao controle

de versões podem ser ignorados pelos comandos CVS

• Configuração de arquivos por padrões de nome– Algumas características dos arquivos podem ser

configuradas de acordo com seus padrões de nome

O CVS possui um recurso chamado substituição (ou expansão) de palavras-chave, que permite a inclusão automática de informações sobre revisões no conteúdo dos arquivos. A motivação para esse recurso é a seguinte. Enquanto os arquivos estão na cópia de trabalho, é possível obter dados através dos comandos log e status. Mas, quando os arquivos são distribuídos, essa informação éperdida. Além disso, é mais conveniente ver algumas informações (como a revisão atual, a data da última modificação ou o último autor a modificá-lo) no próprio arquivo do que na linha de comando. Para contornar esses problemas, o autor pode inserir nos arquivos palavras-chave no formato $PalavraChave$, como $Revision$, $Author$ ou $Date$. Sempre que uma revisão for criada, a palavra-chave é substituída pela informação correspondente, segundo critérios de controle. Pode-se controlar a substituição de palavras-chave – por exemplo, desabilitá-la para arquivos binários – através de modos de substituição. Cada arquivo tem um modo default de substituição, registrado no repositório, e um modo local de substituição, associado a cada cópia de trabalho. O modo de substituição de um arquivo é apelidado opção-k, pois é especificado pela opção –k.

Outra característica interessante do CVS são os arquivos ignorados. Como vimos, alguns arquivos não devem ser colocados sob controle de versões, tais como arquivos resultantes de compilação. Idem para arquivos de back-up, arquivos de saída de comandos, etc. Não queremos que o CVS sequer veja esses arquivos. Para isso, é possível fazer com que o CVS ignore arquivos de acordo com padrões de nome. Por default, o CVS já ignora diversos padrões (*.o, *~, etc.) e podemos adicionar outros padrões a essa lista.

Também conseguimos configurar outras características de tratamento de arquivos de acordo com padrões de nome. O melhor exemplo é o de arquivos binários, que não devem passar por substituição de palavras-chave e nem pela substituição de fins-de-linha (o CVS armazena os históricos de acordo com a convenção de fins-de-linha do sistema onde o repositório se encontra). Esse recurso do CVS nos permite por exemplo, dizer que todos os arquivos *.doc devem ser importados e tratados como binários.


1-42



• Observação de arquivos– Um usuário pode marcar arquivos para que ele seja

notificado quando esses arquivos forem editados– A marcação é feita pelo comando watch; a edição tem

que ser indicada com o comando edit

• Especificação de revisões– Pode ser feita por número de revisão, etiqueta ou data– As opções –r (para números e etiquetas) e –D (para

datas) são reconhecidas por diversos comandos

• Consulta a variáveis de ambiente– Alguns comportamentos do CVS podem ser controlados

por variáveis de ambiente do cliente

Como já vimos, o modelo de funcionamento padrão 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 o arquivo fica com permissão de somente leitura nas áreas de trabalho e 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 sobre eventos relativos a arquivos observados.

O CVS representa revisões por números separados por pontos. Apesar dessa numeração ter sua lógica, nem sempre é interessante usá-la. Para isso, o CVS usa etiquetas, que associam nomes mais relevantes a revisões e, mais interessante, aplicam-se a vários arquivos. Por outro lado, às vezes queremos obter ou comparar revisões pela data em que foram criadas. O CVS permite que essas três alternativas sejam usadas para se obter revisões, em diversos comandos. Números de revisões e etiquetas são especificados pela opção –r, enquanto que datas, pela opção –D. Entre os comandos que reconhecem essas opções estão update, diff, log, export.

O CVS consulta algumas variáveis de ambiente para configurar certos comportamentos. Como exemplos estão programas a serem usados, caminhos e outros detalhes. Veremos adiante uma lista mais completa dessas variáveis e seus efeitos. O mais interessante sobre esse recurso é que, quando o CVS está funcionando no modo cliente/servidor, essas variáveis são lidas no ambiente do cliente e passadas ao servidor. Com isso, cada usuário pode configurar uma parte do comportamento do servidor à sua maneira.

Curso de CVS - Parte 1 - Introdução

Technology

Transcript of Curso de CVS - Parte 1 - Introdução