CVS - Slides Parte 2 - Administração

2-1

CVS

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

Administração do CVS

Módulo 2

Foco: Administrador de Sistemas

2-2


Agenda

• Planejando a capacidade para o CVS• Escolhendo a distribuição mais adequada• Instalando o CVS, de binários e de fontes• Criando e conhecendo melhor os

repositórios• Criando e importando projetos• Copiando, movendo e apagando

repositórios• Controlando acessos e permissões• Configurando o comportamento do CVS

2-3


Planejamento de Capacidade

• O CVS é um sistema cliente/servidor– Um planejamento para sua implantação deve levar em conta

ambas as partes, bem como sua comunicação

• Podemos descartar a necessidade de planejamento de capacidade para o cliente CVS– É muito leve, qualquer estação de trabalho é capaz de

executá-lo– Muitos IDEs modernos já trazem o cliente embutido

• O planejamento de capacidade do servidor pode ser dividido em 4 aspectos (em ordem de relevância):– Armazenamento– Rede– Memória– Processamento

2-4


Armazenamento

• Planejar o armazenamento para o CVS equivale a estimar o tamanho do repositório, ou seja, dos históricos

• Para isso existem 3 fatores a serem considerados, em relação aos arquivos sob controle de versões:– Tamanho dos arquivos– Freqüência de alteração– Tipo dos arquivos (texto ou binário)

• Antes de detalhar cada fator, vejamos como o CVS organiza seus arquivos de histórico:– Para arquivos de texto, os históricos guardam somente as

diferenças entre as revisões– Para binários, cada revisão é mantida integralmente nos

históricos

2-5


Tamanho dos Históricos

• Obviamente, quando maiores os arquivos, mais espaço eles ocuparão no repositório

• Cada arquivo evolui em velocidade decrescente até atingir uma razoável estabilidade– Isso quer dizer que, com o passar do tempo, seu

histórico cresce cada vez menos– Podemos associar a curva de crescimento de um

histórico típico à função logaritmo (próximo slide)

• A questão a ser respondida é: Como estimar o tamanho de estabilidade de um histórico?– Assumindo que sabemos o tamanho do arquivo em si

2-6


Crescimento dos Históricos

0

1

2

3

4

5

6

7

Tempo

Tam

anho r

ela

tivo d

o h

istó

rico

Arquivo 1 Arquivo 2 Arquivo 3

2-7


Calculando o Tamanho dos Históricos

• Tomando estatísticas sobre projetos, criamos algumas “regras do dedão”

• Dado o tamanho F (talvez estimado) do arquivo, o tamanho H de seu histórico é dado por:– Para arquivos texto: H = 3F– Para arquivos binários: H = 5F

• É razoável assumir que F é dado– Para projetos importados, ele é

conhecido, basta verificar o tamanho dos fontes– Para novos projetos, os programadores podem

estimá-lo com base em projetos anteriores

2-8


Projetando o Armazenamento

• A principal recomendação é usar o bom senso na aquisição do equipamento– Os cálculos ajudam, mas lembrem que os históricos demoram

para atingir a estabilidade

• A capacidade de armazenamento pode começar menor e crescer ao longo do projeto– Escolha uma ocupação máxima (p.e., 80%) e, ao alcançá-la,

aumente a capacidade– A movimentação de repositórios é uma tarefa relativamente

simples, assim como o back-up

• Os maiores vilões são os arquivos binários– Normalmente são maiores e seus históricos crescem mais

rápido– Por sorte, muitos deles não devem ficar sob o controle de

versões!

2-9


Rede

• O planejamento da rede leva em conta 2 fatores:– O tamanho total do projeto (arquivos, não históricos)– A taxa de acessos ao repositório, que depende do

número de programadores envolvidos no projeto

• Como vimos, o 1o fator pode ser estimado• Para analisar o 2o fator, façamos considerações:

– Cada programador trabalha a maior parte do tempo em sua área de trabalho e a atualiza algumas vezes ao dia

– Quando uma atualização é feita:• O CVS verifica o timestamp do arquivo local• Se ele for diferente do momento da última atualização, o CVS faz

uma comparação para identificar diferenças, no servidor

2-10


Projetando a Capacidade de Rede

• Mais uma “regra do dedão”:– Dado M, o tamanho total do módulo– Cada dia, cada programador gera:

• 0,5M bytes de tráfego do cliente para o servidor• 1,5M bytes de tráfego do servidor para o cliente

• A regra é uma grande simplificação– Assume que cada programador trabalha em um

projeto– Não estima picos de tráfego

• Dicas para racionalizar o consumo de rede:– Mantenha relógios de clientes e servidor em sincronia– Recomende o uso do parâmetro –z nos clientes

2-11


Memória

• Memória dificilmente será um problema– O CVS tem mais de 15 anos, portanto,

é econômico para os padrões atuais

• Outra regra:– O consumo máximo de memória será 10x o

tamanho do maior arquivo

• Onde podem surgir problemas:– Muitos programadores acessando o servidor ao

mesmo tempo: o CVS cria um processo para cada cliente

– Módulos muito grandes: o check-out será pesado– Arquivos muito grandes: comandos como diff

carregam todos os dados em memória

2-12


Processamento

• É a menor das preocupações– O CVS foi criado quando processadores

de 33MHz eram considerados rápidos

• A regra:– Qualquer máquina que puder ser chamada de

“servidor” comportará o servidor CVS– Procure não colocar muitos outros serviços na

máquina

• A arquitetura da máquina é mais importante que o processador– Um barramento rápido e um I/O eficiente farão a

diferença

2-13


Instalando o CVS

• Passo 1: Definir o sistema operacional– UNIX ou Windows

• Passo 2: Escolher uma distribuição– GNU CVS ou CVSNT

• Passo 3: Compilar a distribuição (opcional)– Caso se tenha optado por uma distribuição-fonte

• Passo 4: Instalar a distribuição– Manualmente ou usando um instalador

• Passo 5: Conferir a instalação– Executar o CVS e testar alguns comandos

2-14


Definindo o Sistema Operacional

• É mais uma questão de política da empresa do que uma necessidade do CVS– Hoje, tanto servidor quanto clientes podem ser instalados

em UNIX, Windows e até Macintosh

• O mais importante é escolher o servidor levando em conta a demanda de acesso a disco e rede

• Entretanto, há algumas restrições:– Escolhendo o Windows como servidor, é recomendável optar

pela distribuição CVSNT; as versões possíveis são NT, 2000 e XP

– Caso se opte pelo uso de SSH para se ter conexões seguras entre cliente e servidor, versões compatíveis de SSH devem ser usadas

– Com clientes em múltiplas plataformas, os programadores devem ficar atentos às quebras de linha em seus editores

2-15


Escolhendo uma Distribuição

• As duas distribuições do CVS são:– GNU CVS: a distribuição original do CVS, de código

aberto (licença GPL) e mantida pela FSF– CVSNT: uma derivação do GNU CVS, também GPL,

mantida pela empresa March-Hare• Suporte comercial e treinamento são oferecidos

• Ambas podem ser instaladas em Windows e Linux– A instalação do servidor e do cliente é a mesma

• A recomendação é:– Em clientes UNIX/Linux: utilizar o GNU CVS– Em clientes Windows e Macintosh: utilizar o CVSNT– Para o servidor CVS: usar UNIX/Linux com o GNU CVS

2-16


Qual Versão Instalar?

• Optando pelo GNU CVS, há duas opções:– Versões stable : estão em uso há bastante tempo,

sem grandes evoluções recentes ou novas funcionalidades

• Atualmente, as versões estáveis estão sob o número 1.11• A última versão estável do GNU CVS é a 1.11.21

– Versões feature : introduzem novos recursos ou melhorias arquiteturais

• Atualmente, as novas versões evolutivas estão sob 1.12• A última versão evolutiva do GNU CVS é a 1.12.13

• Optando pelo CVSNT:– A versão paga (CVS Suite) está na versão 2.5.02– A versão open-source está na versão 2.5.03

2-17


Instalação e Verificação

• É recomendado instalar uma distribuição binária– Compilar uma distribuição-fonte só se justifica em

situações muito específicas

• A instalação do CVS é uma tarefa muito simples– Em qualquer distribuição ou sistema operacional, é

possível usar um instalador– Faremos a instalação (Linux e Windows) no próximo lab

• Para conferir a instalação:– cvs –v : mostra a versão instalada localmente– cvs version : mostra as versões do cliente local e do

servidor, se um servidor remoto estiver em uso

2-18


Lab2-1: Instalando o CVS

• Instalar o CVS no Linux– Compilar a distribuição GNU CVS em código-

fonte– Instalar a distribuição binária do GNU CVS

• Instalar o CVS no Windows– Instalar a distribuição binária do CVSNT

• Testar a Instalação– Verificar a instalação local– Verificar a instalação do servidor– Usar o comando version

2-19


Localização do Repositório

• O repositório é um diretório especial contendo históricos– Ao menos um repositório deve estar disponível para o uso do

CVS

• O ideal é cada programador trabalhar em um repositório– Boa prática: criar um repositório por empresa ou departamento

• Um repositório pode ser criado em qualquer disco local no servidor CVS, com algumas observações:– A área escolhida deve preferencialmente ter back-ups diários– O sistema de arquivos escolhido não pode travar o servidor se

atingir sua capacidade máxima– Em sistemas UNIX, um local comum é /var/lib/cvs– Em sistemas Windows, pode-se optar por D:\cvs

• Crie um usuário para ser o dono de todo o repositório– Garanta que ele é o dono da raiz do repositório

• Trate o servidor CVS como um servidor de arquivos!

2-20


Criando um Repositório

• Um repositório é criado pelo comando init– Este comando cria um diretório no local especificado,

com a configuração padrão de um repositório

• O local de criação do repositório é especificado pela opção global -d ou pela variável $CVSROOT– É a mesma forma que usamos para especificar a

localização do repositório para o comando checkout

• Com init, é mais comum usar-se a opção -d– Nem é recomendável para o administrador de sistemas

definir a variável $CVSROOT em seu ambiente

• Não há perigo se init for chamado especificando-se um repositório existente (nada é sobrescrito)

2-21


O Comando init

• O comando init cria um repositório• cvs [op_glob] init

– op_glob são opções globais do CVS. A única opção que afeta init é –d, que dá a localização do repositório

• Ele não recebe argumentos e, se a opção –d não for especificada, usa a variável $CVSROOT

2-22


Lab2-2: Criando um Repositório

• Criar um repositório com o comando init• Examinar os arquivos criados no repositório• Fazer o check-out do diretório CVSROOT• Alterar um arquivo na cópia de trabalho• Submeter uma alteração em um arquivo

administrativo

2-23


A Estrutura do Repositório

• É mera curiosidade saber como as informações são armazenadas em um repositório– Todos os acessos devem ser feitos pelos comandos

CVS, pois o formato interno do repositório pode mudar

• Um repositório CVS é um diretório comum, contendo, em um primeiro nível:– Um diretório CVSROOT, contendo arquivos

administrativos (de configuração e controle)• Inclui históricos e as cópias mais recentes desses arquivos

– Zero ou mais diretórios, correspondendo a módulos (projetos) sob o controle de versões

• Cada subdiretório de um módulo inclui os históricos dos arquivos correspondentes (mesmo nome, seguido de ,v)

2-24


Criando Projetos no CVS

• Na terminologia do CVS, projetos e módulos são sinônimos– Conceitualmente, são unidades independentes de trabalho,

como programas, projetos, artigos, sites– Para o CVS, são diretórios sob a raiz do repositório

• Para criar um projeto no CVS é preciso importá-lo– Esta tarefa cabe em geral ao gestor de configuração

• Preparação– Crie um conjunto inicial de arquivos para a importação– Organize-os em uma estrutura quase definitiva de

diretórios

• Importação– Execute o comando import, para popular o repositório

• Declaração (opcional)– Edite o arquivo modules, incluindo a declaração do módulo

2-25


O Comando import

• O comando import cria um novo projeto ou atualiza arquivos fornecidos por terceiros– Deve ser executado de dentro do diretório onde se

encontram os arquivos a importar

• cvs [op_glob] import [op_cmd]nome_projeto ramo_fornec etiq_versão...– op_glob e op_cmd são opções globais e do

comando– nome_projeto é o nome do projeto a ser criado– ramo_fornec é o nome do ramo do fornecedor dos

arquivos; as revisões criadas ficarão sob esse ramo– etiq_versão... são uma ou mais etiquetas a serem

aplicadas sobre as revisões criadas, marcando a versão

2-26


Lab2-3: Importando Projetos

• Importar um conjunto de arquivos para o CVS, criando um novo projeto

• Importar um novo conjunto de arquivos do mesmo fornecedor para o mesmo módulo

• Alterar um arquivo do projeto e importar novamente, causando um conflito

• Entender o funcionamento dasopções de arquivos ignoradose filtrados

2-27


Importando de Outros SCVs

• Ao migrar para o CVS, o ideal é importar os arquivos mantendo seus históricos

• A forma geral para se importar históricos para o CVS é através de arquivos RCS– Basta criar um diretório para o projeto no repositório e

copiar os arquivos RCS para ele

• Há scripts disponíveis para exportar arquivos RCS– SCCS: usar o script sccs2rcs na distribuição GNU CVS– PVCS: usar o script pvcs_to_rcs no GNU CVS– Outros sistemas podem disponibilizar seus conversores

• Em último caso, a opção é importar as últimas revisões e algumas liberações mais relevantes

2-28


Gerenciando Back-ups

• Um repositório CVS é uma árvore de diretórios– Back-ups podem ser feitos com as mesmas

ferramentas utilizadas para outras áreas de dados– É importante que estrutura, propriedades,

permissões e outros atributos sejam mantidos como no original

• As seguintes atividades estão relacionadas à gerência de back-ups de um repositório CVS– Congelar o repositório: pré-requisito para efetuar a

cópia do repositório– Copiar os dados: criar uma foto do repositório– Restaurar um back-up: voltar a um estado anterior– Espelhar um repositório: replicar os dados para

leitura

2-29


Congelando um Repositório

• Significa impedir que usuários modifiquem o repositório– Visa garantir que uma cópia encontre todos os dados em um

estado consistente– Caso isso não seja feito, uma cópia pode ser feita em meio a

um check-in de vários arquivos

• Há diversas alternativas para atingir esse objetivo– Desligar o processo servidor do CVS– Impedir logins no servidor (ou deixá-la em modo single user)– Bloquear o servidor com um firewall (ou desligar a rede)– Travar o repositório no modo exclusivo para leitura

• Travar o servidor é a forma preferida– Permite que usuários continuem usando o servidor para leitura– Os materiais do aluno incluem scripts para congelar e

descongelar

2-30


Criando e Restaurando Back-ups

• Uma vez congelado o repositório, uma cópia pode ser criada usando uma ferramenta de back-up– Todos os atributos devem ser preservados, para

manter as configurações de segurança do repositório– Exemplo de ferramenta simples e acessível: tar

• Para restaurar um back-up:– Certifique-se que os atributos serão preservados– Congele totalmente o repositório durante a

restauração– Garanta que o diretório CVSROOT foi restaurado; os

projetos podem ser restaurados em qualquer ordem– Peça que usuários façam novo check-out de seus

projetos e refaçam mudanças pendentes

2-31


Espelhando um Repositório

• Muitos projetos têm cópias públicas disponíveis – Projetos open-source de instituições como FSF, Apache

• As cópias devem permitir somente leitura– CVS não trata modificações em diferentes repositórios

• Os repositórios-espelho podem estar desde na mesma máquina até em uma rede distante

• O processo de espelhamento é similar ao back-up– Congele o repositório original (permita somente leitura) e

o destino (totalmente)– Faça a cópia usando uma ferramenta (ex.: rsync)– Descongele ambos os repositórios

2-32


Editando um Repositório

• Editar um repositório significa realizar uma das seguintes operações:– Mover ou apagar todo um repositório– Mover ou apagar um módulo– Mover ou apagar arquivos e diretórios em um módulo

• As operações listadas têm diferentes motivações– Move-se um repositório para colocá-lo em uma partição de

um novo disco, ou em uma área com back-up– Move-se um módulo quando se muda de idéia sobre seu

nome– Move-se um arquivo ou um diretório quando o projeto

demanda essa alteração– Remove-se qualquer um dos itens listados quando ele não

está mais em uso

2-33


Movendo e Apagando Repositórios

• Mover um repositório é similar a criar um back-up e depois restaurá-lo– Congele o repositório– Copie os arquivos para a nova área, mantendo atributos

como propriedade, permissões e datas de alteração (cp –a)

– Peça para que os usuários alterem suas variáveis $CVSROOT, façam check-outs do novo repositório e refaçam alterações

• Antes de remover um repositório certifique-se do que está fazendo– Faça um back-up dos dados (nunca se sabe!)– Verifique se há scripts usados pelos arquivos

administrativos repositório e que podem ser removidos– Remova recursivamente a raiz do repositório

• Por exemplo: rm –rf /var/lib/cvs

2-34


Movendo e Apagando Módulos

• Há duas opções para mover (renomear) um módulo:– Mover o diretório correspondente ao módulo

• Alternativa mais radical; o nome original não é mais acessível

• Invalida as áreas de trabalho dos usuários

– Definir o novo módulo no arquivo modules• Opção mais moderada, não necessita acesso direto ao

servidor• O nome original do módulo continua acessível, cópias de

trabalho antigas continuam válidas

• Ao remover um módulo, antes faça um back-up– Verifique se há referências ao diretório em modules– Remove recursivamente o diretório do módulo

2-35


Movendo Arquivos

• O CVS permite adicionar e remover arquivos com add e remove, mas não tem um comando para mover arquivos

• Há 3 alternativas para isso:– Renomear o arquivo na área de trabalho, remover do

repositório e então adicionar, usando remove e add• É simples, não requer acesso privilegiado ao repositório,

liberações são preservadas, mas o histórico é interrompido

– Renomear o arquivo de histórico no repositório (mv)• Preserva as revisões no histórico do arquivo, mas requer acesso

shell ao repositório e pode danificar liberações anteriores

– Copiar o arquivo antigo para criar o novo e mover o antigo para o Attic, como uma revisão morta

• Preserva as revisões no histórico e liberações antigas, mas é bem mais complexo e pode levar a problemas com ramos

2-36


Movendo e Apagando Diretórios

• Ao contrário de arquivos, o CVS não possui comandos para manipular diretórios

• Um diretório é adicionado ao repositório se algum arquivo debaixo dele for adicionado

• Para apagar um diretório, remova todos seus arquivos– Fazendo isso, o diretório vazio continua sendo visto; evita-se

isso com a opção –P em checkout e update

• Para mover um diretório há 3 formas:– Mover todos os arquivos para o novo nome na cópia local,

removê-los do local antigo no repositório e adicionar os “novos” arquivos

– Renomeá-lo diretamente no repositório– Copiá-lo para o novo nome no repositório e depois remover

todos os arquivos sob o nome antigo a partir de uma área de trabalho

2-37


Segurança no CVS

• A segurança de projetos sob controle de versões no CVS depende dos seguintes aspectos:– A área de armazenamento do repositório– O servidor CVS e seu ambiente– Todos os computadores contendo áreas de trabalho– Os métodos de acesso ao repositório– O armazenamento dos back-ups

• A segurança do servidor, das estações de trabalho e dos back-ups é comum a qualquer ambiente

• Destacaremos questões relativas às permissões no repositório e aos métodos de acesso

2-38


Controlando Permissões

• A segurança do armazenamento do repositório depende das permissões do sistema de arquivos– É dependente do sistema operacional no qual o servidor executa– Discutiremos as configurações para um servidor UNIX

• Raiz do repositório– Apenas os usuários que podem criar projetos devem ter

permissão de leitura, escrita e execução; os demais, leitura e execução

– Deve ter o bit SGID ligado

• Diretório CVSROOT– Todos usuários devem ter acesso de leitura a todos os arquivos e

permissão de escrita aos arquivos history e val-tags– Só usuários avançados podem ter acesso de escrita aos demais

arquivos (administrador de sistemas e gestor de configuração)

2-39


Permissões em Projetos

• Só é possível controlar permissões no nível de diretórios– Quando se faz um check-in, o CVS cria uma cópia

temporária do histórico e depois a joga sobre o original

– Consequentemente, permissões são sobrescritas e o dono é trocado a cada nova revisão de um arquivo

• A segurança em projetos é garantida por grupos– Cada projeto deve ser propriedade de um grupo e as

permissões dos diretórios devem refletir isso• Configuração geral: u=rwx, g=rwx, o=rx

– O bit SGID também deve estar ativo

2-40


Permissões de Somente Leitura

• Para configurar permissões de somente leitura em um projeto, é preciso mudar o local de criação de travas– Por default, o CVS cria travas dentro do diretório do projeto

• Como o CVS também cria travas para leitura, se o default for mantido, ocorrerá uma dos seguintes casos:– Se tirarmos a permissão de escrita do módulo para outros,

impedimos a leitura por quem não é do grupo do projeto– Se dermos permissão de escrita no módulo para outros, quem

não pertence ao grupo do projeto poderá alterar os arquivos

• O arquivo que controla o local das travas é config– A propriedade a ser alterada chama-se LockDir

• Para impedir a leitura de um projeto, deve-se tirar as permissões de leitura e execução de outros

2-41


Lab2-4: Controlando Permissões

• Criar um grupo e associá-lo a usuários e projetos

• Configurar o repositório CVS para permitir acessos de somente leitura a um projeto

• Testar a configuração, tentando check-outs e check-ins com usuários dentro e fora do grupo

• (Opcional) Configurar um projetopara não permitir a leitura porusuários fora de seu grupo

2-42


Repositórios Locais e Remotos

• O CVS opera com repositórios locais ou remotos– No primeiro caso, ele funciona como um programa

independente, no segundo, como cliente/servidor

• Quando optar pelo uso local?– Em um projeto particular– Com uma equipe usando um único

servidor por terminais

• E o uso remoto?– Em projetos

distribuídos– Com equipes onde cada um usa sua

própria estação de trabalho Repositório

LAN

`

Terminal

Internet

Servidor

1

2

3

2-43


Métodos de Acesso Remoto

• Como vimos no módulo introdutório, um repositório pode ser especificado no formato:– [:método:][usuário[:senha]@][servidor[:porta]]raiz

• O elemento método pode ser um dentre:– local: para repositórios na máquina local– ext: método de conexão por shell externo, estilo rsh ou ssh– fork: para conectar na máquina local como se fosse remota– server: método de conexão rsh, interno ao CVS– gserver: conexões usando a GSS-API (Kerberos 5)– kserver: conexões usando Kerberos 4– pserver: conexões usando o servidor de senhas interno

• Dependendo do método especificado, alguns dos outros elementos podem ser omitidos

2-44


Os Métodos local e fork

• São usados para acessar repositórios locais• Usar o método local é equivalente a

especificar diretamente o caminho do repositório– –d :local:/var/lib/cvs é idêntico a –d /var/lib/cvs

• O método fork força o CVS a funcionar no modo cliente/servidor, mas não usa a rede– Cliente e servidor executam sob o mesmo usuário:

o processo servidor é um fork do cliente– É usado para depuração, ajudando a verificar se um

problema está na rede ou no modo cliente/servidor

2-45


Os Métodos ext e server

• O método ext é um dos mais utilizados– Ele usa um shell externo para a conexão remota– Combinado com o SSH, é a opção para redes inseguras

• Algumas configurações de variáveis de ambiente:– O executável do shell cliente deve ser especificado pela

variável de ambiente $CVS_RSH, na máquina cliente– O executável do CVS deve estar no $PATH do servidor, ou o

cliente deve apontar $CVS_SERVER para ele

• O shell dispara o comando cvs no servidor com as permissões do usuário remoto que conectou

• O método server é similar e usa um shell interno– Depende de um processo servidor: comando server

2-46


Os Métodos gserver e kserver

• O método gserver usa a GSS-API para permitir autenticação e criptografia da conexão CVS– Essa API apenas define uma interface, quem

autentica e criptografa é outro sistema, tal como Kerberos 5

• O método kserver usa diretamente Kerberos 4– Este sistema tem falhas que foram corrigidas na

versão 5 e deve ser evitado em novas instalações do CVS

• Servidor e cliente CVS devem ser recompilados para permitir o uso desses métodos

• Um processo deve ser iniciado no servidor para receber conexões por pserver e kserver– Em sistemas UNIX, deve-se editar inetd.conf

2-47


O Método pserver

• Permite conexões com o repositório usando usuários e senhas armazenados no servidor– O administrador deve criar um arquivo passwd

• O método pserver tem algumas vantagens– Já é automaticamente suportado pelo CVS– Permite acesso anônimo, sem senha e somente leitura

• Há algumas desvantagens– A codificação das senhas no servidor é trivial– A comunicação cliente/servidor não é criptografada

• Para receber conexões pserver, um processo deve ser iniciado no servidor (inetd.conf)

• Para invocar comandos pelo método pserver, o cliente deve antes executar login e, ao fim da sessão, logout

2-48


Lab2-5: Configurando oAcesso Remoto

• Testar a instalação do servidor SSH no Linux• Instalar um cliente SSH no Windows (PuTTY)• Testar a conexão cliente/servidor• Criar e configurar chaves pública e privada• Configurar $CVS_RSH e realiza um check-

out usando o método ext• (Opcional) Realizar um check-out usando o

método pserver

2-49


Configurando o Servidor CVS

• O comportamento do servidor é configurado por:– Arquivos administrativos– Variáveis de ambiente

• Arquivos administrativos estão no repositório sob o diretório CVSROOT– São únicos por repositório; aplicam-se a todos os

projetos e todos os usuários

• Variáveis de ambiente são definidas pelo cliente– Quando o CVS funciona em modo cliente/servidor,

elas são lidas pelo cliente e passadas para o servidor– Portanto, o usuário final é capaz de configurar alguns

comportamentos do servidor

2-50


Os Arquivos Administrativos

• O CVS funciona satisfatoriamente sem que seja necessário editar os arquivos administrativos

• Porém, alguns comportamentos avançados podem ser obtidos usando corretamente tais arquivos

• Os principais arquivos administrativos são:– modules: lista os módulos presentes no repositório– cvsignore: especifica padrões de arquivos ignorados– cvswrappers: especifica padrões de arquivos filtrados– config: define configurações variadas do repositório– commitinfo, verifymsg, loginfo: definem gatilhos

que configuram o processo de check-in

2-51


O Arquivo modules

• Lista projetos (módulos) presentes no repositório– Um projeto não precisa estar em modules para ser visível: basta

que ele seja um subdiretório da raiz do repositório

• Entretanto, incluir projetos em modules tem vantagens:– Os projetos listados em modules são exibidos pelo comando

checkout, quando se usa –c ou –s– É possível definir módulos especiais ou excluir diretórios

• Cada linha é uma definição de módulo:– Módulo normal: nome [opções] dir [arquivos...]

• É possível especificar em dir um subdiretório qualquer do repositório

• Se arquivos forem especificados, somente eles serão obtidos– Módulo alias: nome –a [!dir_excluído] alias...

• É possível excluir diretórios precedendo-os por !– Inclusão de módulo: nome [opções] &módulo_inc...

• Quando nome for obtido, ele terá um subdiretório módulo_inc

2-52


Opções Permitidas em modules

• Os módulos normais e com inclusão permitem as seguintes opções:– -d outro_nome: o diretório de trabalho terá

outro_nome, não o nome do módulo– -e programa: programa será executado sempre

que o módulo for exportado– -o programa: programa será executado sempre

que foi feito um check-out do módulo– -t programa: programa será executado sempre

que uma etiqueta for aplicada pelo comando rtag– -s status: define um status para o módulo. Este

status é consultado por checkout, com a opção -s

2-53


O Arquivo cvsignore

• Alguns arquivos devem ser ignorados pelos comandos CVS, tais como import e update– Esses arquivos nunca serão colocados sob controle

de versões e nem queremos que o CVS os veja– Exemplos: arquivos resultantes de compilação,

temporários, arquivos de back-up, links (atalhos)

• Padrões de nomes de arquivos que devem ser ignorados são listados em cvsignore– O CVS já oferece alguns padrões ignorados por

default

• Outros padrões podem ser especificados de outras formas– Arquivo .cvsignore, variável $CVSIGNORE, opção -I

2-54


O Arquivo cvswrappers

• O CVS permite que algumas configurações de arquivos sejam controladas de acordo com padrões de nome

• Tratamento de palavras-chave: o CVS pode tentar expandir algumas palavras envolvidas por $– A opção –k controla se elas serão expandidas ou não

• Metodologia de atualização: o CVS pode atualizar um arquivo usando diferenças ou uma cópia nova– A opção –m controla se será tentada a atualização por

diferenças ou se será feita uma cópia da nova revisão

• O arquivo cvswrappers especifica padrões e suas opções

• O uso mais comum desse arquivo é listar padrões de nomes de arquivos binários, com a opção –k b

2-55


O Arquivo config

• O arquivo config é uma miscelânea de configurações do repositório CVS

• Ele mudou bastante nas últimas versões do CVS• Algumas configurações que config permite:

– Especificar o diretório onde as travas são criadas– Controlar o que é registrado no arquivo history, que

armazena o histórico de atividade do repositório– Fazer com que os diretórios CVS das cópias de trabalho

sejam criados em uma árvore de diretórios à parte– Permitir que o servidor pserver procure um usuário no

sistema operacional se ele não estiver em passwd

2-56


Os Arquivos de Suporte ao Check-in

• Alguns arquivos administrativos configuram programas externos a serem executados– Os eventos que podem disparar tais programas

são a aplicação de etiquetas e o check-in

• Os arquivos de suporte ao check-in são:– commitinfo: especifica programas para validar

a revisão submetida em um commit– verifymsg: especifica programas para verificar

a mensagem de log de um commit (opção –m)– loginfo: especifica programas para pós-

processar a mensagem de log de um commit

• Outros arquivos similares: taginfo e rcsinfo

2-57


Variáveis de Ambiente

• Principais variáveis de ambiente vistas pelo CVS:– $CVSIGNORE, $CVSWRAPPERS: listam padrões de

nomes de arquivos a serem ignorados e filtrados– $CVSREAD: se definida, checkout e update deixam

os arquivos da área de trabalho read-only– $CVSEDITOR, $EDITOR, $VISUAL: configuram o

editor invocado pelo CVS. São consultadas nesta ordem– $PATH: no cliente, usada para achar o shell para o

método ext e no servidor, para o executável do CVS– $CVS_RSH: nome do executável do shell externo– $CVS_SERVER: nome do executável do CVS, invocado

pelo processo servidor nos métodos ext, server e fork– $TMPDIR: diretório temporário usado pelo CVS

CVS - Slides Parte 2 - Administração

Technology

Transcript of CVS - Slides Parte 2 - Administração