Introdução à Gestão de Configuração e ao CVS

Copyright© 2005, Marden Neubert

© 2005 Marden Neubert www.mardenneubert.com

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

Módulo 1

Foco: Geral

1-1

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.



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
1-2

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



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
1-3

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.



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
1-4

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.



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
1-5

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.



O Que Deixar sob o
Controle 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
1-6

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 shell
scripts. 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.



Alternativas ao CVS
• Open-source
– RCS (Revision Control System)
– SCCS (Source Code Control System)
– Subversion
• Comerciais
– Microsoft Visual SourceSafe
– Rational ClearCase
– Borland StarTeam
– Perforce

1-7

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.



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
1-8

É 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.”



Melhores Práticas de
Engenharia de Software
• Abordagens conhecidas e testadas
– Observadas em projetos que tiveram sucesso

Desenvolver iterativamente

Gerenciar Usar Modelar Verificar a
requisitos componentes visualmente qualidade

Controlar mudanças

1-9

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.



Fases, Disciplinas e Iterações

1-10

Este slide explica melhor o que é um processo iterativo, usando um diagrama do “Rational
Unified 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 em
cada 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.



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
1-11

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 Vrije
Universiteit, 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 Berliner
trabalhava, 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.



Arquitetura

1-12

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.



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
1-13

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.



Ilustração do Cenário Básico

João : Autor : Repositório

Check-out

: Cópia de Cria cópia
trabalho
Edita arquivo

Check-in

Obtém alterações

Cria revisão

1-14

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.



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
1-15

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.



Ilustração do Cenário Complexo

1-16

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.



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

1-17

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.



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?
1-18

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:Trabalhoalomundo. Examinamos então o histórico
do arquivo AloMundo.java:
C:Joaoalomundo> cvs log AloMundo.java
Podemos também verificar o status desse arquivo e verificar que ele está atualizado:
C:Joaoalomundo> 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:Joaoalomundo> cvs commit –m “Adicionei uma exclamacao” AloMundo.java
Verificamos novamente o histórico e observamos a nova revisão criada. Consultando o status do
arquivo, 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?



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)

1-19

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.



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
1-20

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.



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
1-21

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.



Á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
1-22

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.



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
1-23

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.



Check-In
• É a ação que submete ao repositório
alteraçõ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
1-24

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.



Revisão 1.1
• É cada um dos estágios na evolução
de 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-25

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.



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

1-26

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.



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
1-27

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.



Mescla: Ilustração

1-28

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.



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
1-29

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.



2.0
Liberação Beta

• 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

1-30

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.



Liberação: Antes da Marcação
Pais.java Estado.java Cidade.java Teste.java

1.1 1.1 1.1 1.1

1.2 1.2 1.2 1.2

1.3 1.3 1.3

1.4 1.4 1.4

1.5 1.5

1.6
1-31

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.



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

1-32

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”.



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

1-33

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.



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
1-34

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 é.



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
1-35

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...)



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

1-36

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.



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
1-37

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.



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
1-38

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.



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

1-39

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.

Introdução à Gestão de Configuração e ao CVS

Introdução à Gestão de Configuração e ao CVS

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Introdução à Gestão de Configuração e ao CVS

Semelhante a Introdução à Gestão de Configuração e ao CVS (20)

Mais de Marden Neubert

Mais de Marden Neubert (7)

Introdução à Gestão de Configuração e ao CVS