CVS Instalação e Configuração

O CVS, ou Concurrent Version System (Sistema de Versões Concorrentes) permite que se trabalhe com diversas versões de arquivos organizados em um diretório e localizados local ou remotamente, mantendo-se suas versões antigas e os logs de quem e quando manipulou os arquivos.

É especialmente útil para se controlar versões de um software durante seu desenvolvimento, ou para composição colaborativa de um documento.

A exemplo de outros softwares usados neste projeto, o CVS pode ser baixado gratuitamente e tem o seu código aberto. (http://ximbiot.com/cvs/)

Funcionamento

O CVS utiliza uma arquitetura cliente-servidor: um servidor armazena a(s) versão(ões) atuais do projeto e seu histórico, e os clientes se conectam a esse servidor para obter uma cópia completa do projeto, trabalhar nessa cópia e então devolver suas modificações. Tipicamente, cliente e servidor devem estar conectados por uma rede local, ou pela Internet, mas o cliente e o servidor podem estar na mesma máquina se a configuração do CVS for feita de maneira a dar acesso a versões e histórico do projeto apenas a usuários locais. Geralmente um servidor CVS roda em um Sistema Operacional Unix(ou Linux), no entando, o Cliente CVS (WinCVS ou LinCVS) pode rodar em qualquer Sistema Operacional.

Os Projetos controlados pelo CVS podem ser formado por Módulos, assim sendo, o CVS permite a um usuário ou grupo de usuários que editem esses Módulos de maneira concorrente. Ao confirmar as alterações, o servidor faz um merge das mesmas. Caso o merge não ocorra o servidor avisa que existe algum conflito e que é necessário uma intervenção humana. Se a validação alteração for bem sucedida, o número de versão de cada cliente arquivo envolvido é incrementado, e o servidor CVS escreve uma linha de observação (fornecida pelo usuário), a data e o autor das alterações em seus arquivos de log.

Clientes podem comparar diferentes versões de um arquivo, pedir um histórico completo das alterações, ou baixar uma determinada versão do projeto, ou de uma data específica, não necessariamente a versão mais atual. Muitos projetos de código aberto permitem acesso para leitura anônimo, o que significa que qualquer pessoa pode baixar ou comparar versões sem necessidade de autenticação; somente para salvar mudanças é necessário informar a senha nesses casos.

Clientes também podem usar o comando "update" para manter suas cópias locais atualizadas com a última versão do servidor. Isso elimina a necessidade de se fazer diversos downloads de todo o projeto.

O CVS também pode manter diferentes "estados" do projeto. Por exemplo, uma versão do software pode ser um desses estados, usado para correção de bugs, enquanto outra versão, que está realmente sob desenvolvimento, sofrendo alterações e tendo novas funcionalidades implementadas, forma o outro estado.

Um servidor CVS pode gerenciar diversos módulos; ele armazena todos os módulos administrados por ele em seu repositório. A cópia do módulo que foi baixada para um cliente é chamada cópia de trabalho. Em cada pasta do Projeto o CVS cria uma pasta de controle, com alguns arquivos dentro.

Algumas Limitações

• Os arquivos em um repositório CVS não podem ser renomeados, eles devem ser explicitamente removidos e readicionados.

• O protocolo do CVS não permite que os diretórios sejam movidos ou renomeados. Cada arquivo do subdiretório em questão deve ser individualmente removido e readicionado.

Alguns dos principais desenvolvedores que trabalharam no CVS são atualmente responsáveis pelo Subversion (SVN), lançado no começo de 2004 e cujo objetivo é substituir o CVS ao lidar com algumas de suas limitações.

Instalação e Configuração

Faremos uma abordagem mais simples e direcionada à forma de instalação e configuração do CVS, no entanto, os testes foram realizados em máquinas que utilizam o Windows, Linux e Unix Solaris.

Forma de acesso:

• ext – utilizado em repositório remoto, suporta autenticação via um programa externo (Remote Shell ou Secure Shell);

• gserver – utilizado em repositório remoto, suporta autenticação GSSAPI, uma API de autenticação robusta que é suportada pela versão 5 ou KERBEROS;

• local – utilizado quando se cria um repositório no disco local;

• pserver – utilizado em repositório remoto, suporta autenticação via Password Server (TCP/2401), utiliza os usuários cadastrados no sistema operacional;
  

Nota:

1. Nos exemplos abaixo escolheremos o pserver (Password Server) como método de acesso. O pserver é o daemon que fica escutando na porta 2401;

2. Para a autenticação foi criado o grupo cvs (no Servidor) e todos os usuários autorizados a entrar no repositório (/usr/CVS) foram incluidos nesse grupo;

3. O repositório até o momento não é nada a mais que um diretório num local pré-determinado e abaixo de /usr/CVS/(aqui), onde ficarão os projetos;

4. Para certificarmos que o servidor está configurado corretamente e escutando na porta tcp 2401, podemos tentar acessar via browser o endereço http://seuservidor:2401/ (se estiver ok aparecerá uma mensagem de erro do próprio cvs)

Windows(lado servidor):

• Utilizamos o Wincvs para instalar o cvs como serviço, assim sendo ele configura os dois arquivos abaixo diretamente como um serviço do Windows:

cvsservice.exe cvslock.exe

Solaris(lado servidor):

• alterar o arquivo inetd.conf no diretório /etc/ (preferencialmente com root)

cvspserver stream tcp nowait root /opt/csw/bin/cvs grupo -f –allow- root=/usr/CVS pserver

Obs: /usr/CVS – diretório onde o repositório foi criado

grupo –