O CVS pode fazer muitas coisas para você, mas ele
não quer ser tudo para todos.
- O CVS não é um sistema de desenvolvimento.
Embora a estrutura de seu repositório e os módulos de
arquivos interajam com seu sistema de desenvolvimento (por
exemplo, `Makefiles'), eles são essencialmente
independentes.
O CVS não dita como você constrói qualquer
coisa. Somente armazena arquivos para recuperação em
uma estrutura hierárquica que você define.
CVS não dita como usar espaço em disco nos
diretórios de trabalhando checked out. Se você
escreve seus `Makefiles' ou scripts em todos
diretórios de modo que eles saibam as posições
relativas de todo o resto, resulta que todo o repositório
deve passar pelo checked out.
Se você modularizar seu trabalho, e construir um sistema
que compartilhe arquivos (via links, mounts,
VPATH nos `Makefiles', etc.), você pode
organizar o uso do espaço em disco como desejar.
Mas você deve lembrar-se de que todo sistema desse tipo
é trabalhoso para construir e manter. O CVS não
envolve nessas decisões.
Obviamente você deve fazer todos os ajustes para atender
às necessidades de implementação de sistemas
(scripts, `Makefiles', etc) para o ambiente
oferecido pelo CVS.
Determinar que arquivos precisam ser reconstruídos quando
algo muda é, novamente, algo além do escopo do
CVS. Uma estratégia corriqueira é usar o
make para a construção e algum instrumento
automático para estabelecer as dependências usadas pelo
comando make.
Veja em @xref{Construções}, para mais
informações sobre a execução de
construções usando o CVS.
- O CVS não é um substituto para a boa administração.
Seus gerentes e líderes de projeto devem comunicar-se o
suficientemente freqüênte com você para assegurar que
você está atento dos agendamentos, eventos de
convergência, ramificação de nomes edatas para
libera'~ao de novas versões. Se eles não o fizerem, o
CVS não poderá ajudar.
O CVS é um instrumento para
fazer os códigos fonte dançarem de acordo com a
sua melodia. Mas você é o flautista e o compositor.
Nenhum instrumento se toca
a si mesmo ou escreve sua própria partitura.
- O CVS não é um substituto para intercomunicação
- entre os desenvolvedores.
Quando enfrentam conflitos que envolvem um único arquivo,
a maioria dos programadores consegue solucionalos sem muito
esforço. Mas uma definição mais geral de
"conflito´´ inclui problemas difíceis demais para
resolver sem a comunicação entre os desenvolvedores.
O CVS não pode saber quando mudanças
simultâneas em um mesmo arquivo, ou em um grupo de
arquivos, resultarão em em conflito logico com algum
outro. Seu conceito de um conflito é puramente
textual, ocorrendo quando duas mudanças no mesmo
arquivo base estiverem perto de bastante para ativar a
diretiva merge do comando diff3.
O CVS não se propões a ajudar a resolver conflitos
na lógica de programação.
Por exemplo: Digamos você muda os argumentos da funcão
X no arquivo `A'. Ao mesmo tempo, alguém
edita o arquivo `B', adicionando novas chamadas para a
função X mas usando argumentos no formato
antigo. Neste contexto você estará completamente fora
do escopo do CVS.
Adquira o hábito de ler os specs e falar com seus
parceiros.
- O CVS não faz controle de modificações.
Controle de modificações refere-se à vários
aspectos. Em primeiro lugar pode significar trastreamento
de erros, isto é, ser capaz de manter uma base de dados de erros (bugs) já relatados e a condição
atual destes (está corrigido? em que verssão? o relator
do erro concorda que este foi corrigido?). Para
interconectar o CVS com um sistema externo de
rastreamento de erros, veja os arquivos `rcsinfo' e
`verifymsg' ( C. Reference manual for Administrative files).
Outro aspecto sobre o controle de
mudanças é o fato de que mudadas em vários
arquivos são tratadas como uma única mudança
logica. Se você atualizar vários
arquivos em uma única operação de commit,
então o CVS esquece que esses arquivos foram verificados
juntos, e o fato que eles têm que a mesma mensagem
de registro será a único vínculo que os manterá
juntos. É útil manter um arquivo de mudanças
(`ChangeLog') ao estilo GNU.
Outro aspecto sobre o controle de mudanças, em alguns
sistemas, é a habilidade de manter registro do estado de
cada mudança. Algumas mudanças foram feitas por um
programador, outras foram revisadas por um segundo
programador, e assim por diante. Geralmente, o modo de
fazer isto com o CVS é gerar um diff (usando
o comando cvs diff ou diff ou) e envia-lo por
e-mail isto para alguém que aplica a modifica'~ao usando
o comando patch. Isto é muito flexível, mas
depende de mecanismos fora do CVS para assegurar que
nada escape pelas "frestas"...
- O CVS não é um programa para testagem automática
Deveria ser obrigatório o uso de um conjunto de fontes
para teste usando o arquivo `commitinfo'. Eu não
ouvi falar muito de projetos que tentam fazer uso disto ou
se existem problemas ocultos a este respeito.
- O CVS não tem um modelo para o processo de criação
Alguns sistemas oferecem modos de assegurar que as
modificações ou versões passem por várias etapas,
com várias instâncias de aprovações. De modo
geral, é possível fazer isto com o CVS oque exige
um pouco mais de esforço. Em alguns casos pode-se usar
os arquivos `commitinfo', `loginfo',
`rcsinfo', ou `verifymsg' de modo que antes do
checkin determinadas etapas tenham sido cumpridas. Também deve-se considerar o uso de processos como os de
ramificação e anotações para executar o
trabalho de desenvolvimento em um ramo separado e depois
rejunta-lo com a versão estável quando se estiver certo
de que está pronto para tal.
