cvs - slides parte 4 - avançado
TRANSCRIPT
4-1
CVS
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Uso Avançado do CVS
Módulo 4
Foco: Gestor de Configuração e Projeto
4-2
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Agenda
• Os arquivos de controle da áreade trabalho
• Trabalhando com etiquetas• Utilizando ramos e múltiplas linhas de código• Exportando projetos• Recursos para projetos com vários usuários• Editando o repositório com o comando admin• Ferramentas de auxílio ao CVS• Boas práticas em Gestão de Configuração de
Software
4-3
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Os Arquivos de Controleda Área de Trabalho
• No módulo de administração vimos um pouco de como o CVS guarda informações no repositório– Veremos agora o que o CVS armazena na cópia local
• Os arquivos de controle estão sob os diretórios CVS– Eles são armazenados em formato texto, seguindo a
convenção de fins-de-linha do sistema operacional cliente
• Os principais arquivos da área de trabalho são:– Root: Contém a localização da raiz do repositório– Repository: Tem o caminho no repositório ao qual o
diretório da cópia local corresponde– Entries: Lista arquivos e diretórios sob o diretório de
trabalho• Indica nome, revisão em uso, data da atualização, presença de
conflitos e opções aderentes a arquivos (opção-k, etiqueta ou data)
– Tag: Registra etiquetas e datas aderentes ao diretório todo
4-4
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Gerenciando Etiquetas
• O CVS permite a obtenção de qualquer revisão de arquivos mantidos sob o controle de versões– Vimos que é útil obter uma revisão específica de um
arquivo, por exemplo, para se reverter uma alteração
• Porém, é muito mais útil recuperar as revisões de arquivos que, juntas, formam um conjunto coeso– O conceito que representa um conjunto coerente de
revisões dentro de um projeto é a liberação
• Etiquetas são usadas para marcar liberações– Também são usadas para marcar revisões individuais
• Um nome é muito mais significativo que um número de revisão
4-5
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Uma Liberação Antes da Etiqueta
1.1
1.2
Estado.java
1.1
1.2
1.3
1.4
Pais.java
1.1
1.2
1.3
1.4
Cidade.java
1.1
1.2
1.3
1.4
Teste.java
1.5
1.6
1.5
4-6
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
A Liberação Após a Etiqueta
1.1
1.2
Estado.java
1.1
1.2
1.3
1.4
Pais.java
1.1
1.2
1.3
1.4
Cidade.java
1.1
1.2
1.3
1.4
Teste.java
1.5
1.6
1.5
2.1 Final
4-7
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
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
C:\ 1.1
1.2
1.3
1.4
1.3
BASE
HEAD
4-8
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
O Comando tag
• O comando tag aplica uma etiqueta sobre revisões de arquivos, por default, as revisões na cópia local (BASE)
• cvs [op_glob] tag [op_cmd] etiqueta [arquivos...]– op_glob são opções globais, op_cmd são opções do comando– Os argumentos são: o nome da etiqueta a ser criada e zero ou
mais arquivos (e diretórios) sobre os quais ela será aplicada
• As opções de comando mais úteis com tag são:– -b: Faz com que etiqueta seja um ramo (branch)– -c: Não aplica a etiqueta se algum arquivo local estiver
modificado– -D data, -r revisão e -f: permitem especificar outras revisões– -F: Move a etiqueta se ela já existe em outra revisão do arquivo– -d: Apaga a etiqueta dos arquivos especificados
• O comando rtag é similar, porém atua só no repositório e, por default, marca as últimas revisões (HEAD)
4-9
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Nomes de Etiquetas
• Use nomes significativos e claros para etiquetas• O CVS impõe restrições aos nomes de etiquetas
– Devem começar com letra (maiúscula ou minúscula)– Podem conter letras, dígitos, hífen “-” e sublinhado “_”
• Sugestão de convenção para nomes de etiquetas:– Todas as letras maiúsculas– Separar nomes e dígitos por hífen “-”– Usar sublinhado “_” no lugar de ponto “.”
• Exemplos:– O módulo places-1.0 ganhou a etiqueta PLACES-1_0– O cvs-1.12.13 seria etiquetado CVS-1_12_13
4-10
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Quando Aplicar Etiquetas
• A freqüência de aplicação de etiquetas faz parte da política de gestão de configuração do projeto– Assim como as convenções de nomenclatura de etiquetas
• Regra geral: aplique uma etiqueta a cada estágio importante do projeto– No mínimo, cada liberação deve ser marcada
• Outras situações onde é recomendado aplicar etiquetas:– Logo após finalizar um requisito importante– Logo antes de remover um recurso a pedido do cliente– Logo antes de iniciar uma bateria de testes– Logo antes de criar um novo ramo (veremos adiante)– Logo antes de fazer a mescla de um ramo (veremos adiante)
4-11
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Lab4-1: Aplicando Etiquetas
• Aplicar uma etiqueta sobre as revisões presentes em uma cópia local
• Verificar o comportamento da opção –c• Mover uma etiqueta• Aplicar uma etiqueta diretamente sobre o
repositório• Desafio: renomear uma etiqueta
4-12
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Múltiplas Linhas de Código
• Um ramo é uma derivação da linha de código principal de um projeto, o tronco– Permite que alterações sejam feitas em uma cópia à parte dos
arquivos, sem afetar a linha principal• O CVS implementa um ramo como uma etiqueta especial
– Um ramo é criado pelo comando tag, com a opção –b– As revisões marcadas pela etiqueta formam a base do ramo– É boa prática marcar as revisões-base com uma etiqueta normal– A partir da base, alterações feitas sobre o ramo são armazenadas
separadas das alterações feitas sobre o tronco– A numeração das revisões no ramo é derivada das revisões-base
• Nomes de ramos seguem as mesmas regras que etiquetas– Para diferenciar, convencionamos usar letras minúsculas
• Como etiquetas, é possível criar ramos sobre apenas alguns arquivos de um projeto, mas não é recomendado
4-13
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Tronco Principal e Ramos
1.1 1.3 1.4 1.51.2
1.2.2 1.2.2.1 1.2.2.2
1.2.4Ramos
1.2.4.1 1.2.4.2 1.2.4.3
1.3.2Ramo 1.3.2.1 1.3.2.2
Tronco
4-14
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Trabalhando em um Ramo
• Um ramo define uma linha de código distinta• Cada área de trabalho está associada a uma
linha• Portanto, para se trabalhar em um ramo, cria-se
uma área de trabalho voltada para aquele ramo• A opção –r para checkout e update permite a
associação de uma cópia local a um ramo– Basta especificar o nome de um ramo para a opção– A opção é aderente, futuras execuções de comandos
na mesma cópia local se aplicarão ao ramo– Ao contrário de etiquetas comuns, ramos permitem a
execução do comando commit• Novas revisões serão criadas dentro do ramo utilizado
4-15
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Mesclas de Ramos
• É útil ter linhas distintas de código, mas por vezes é preciso mesclar alterações entre duas linhas. Exemplos:– Quando uma nova liberação está sendo desenvolvida em um ramo
e se deseja propagar a correção de um defeito para o tronco– Quando a nova liberação está pronta e deve se tornar a principal
• Uma mescla de ramos tem uma direção: o ramo origem (inalterado) e o ramo destino (conterá as modificações)– Tanto o ramo origem quanto o destino podem ser o tronco
• Mesclas de ramos são feitas com o comando update, usando-se a opção –j (join ou junção)
• Boas práticas:– Aplicar uma etiqueta sobre o ramo destino antes da mescla– Um ramo pode ser abandonado após uma mescla, mas não é
possível nem desejável remover troncos abandonados
4-16
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
A Opção –j para update
• A opção –j para o comando update realiza a junção de revisões, geralmente em ramos distintos– Use também –k k, para evitar expansões de palavras-chave
• É possível usar uma ou duas opções –j em update• Com duas opções: update –j rev1 –j rev2
– Toma as diferenças de rev1 para rev2 = Delta(rev1, rev2)– Aplica Delta(rev1, rev2) sobre a revisão na cópia local, loc– Pode ocorrer conflito entre Delta(rev1, rev2) e Delta(rev1, loc)
• Com uma opção: update –j rev– Obtém a revisão ancestral entre rev e a cópia local: anc– Calcula as diferenças de anc para rev = Delta(anc, rev)– Aplica Delta(anc, rev) sobre a revisão na cópia local, loc– Pode ocorrer conflito entre Delta(anc, rev) e Delta(anc, loc)
4-17
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Mesclando de Ramo para Tronco
• Queremos tomar as diferenças entre a base do ramo e a ponta do ramo e aplicá-las sobre a ponta do tronco
• Faça um check-out do tronco• Execute update –j ETIQ-BASE –j ramo• Na figura, ETIQ-BASE é REL-2_0 e ramo é rel-2_0
1.1 1.3 1.4 1.51.2
1.2.2Ramo “rel-2_0” 1.2.2.1 1.2.2.2
Tronco 1.6
REL-2_0
4-18
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Mesclando de Tronco para Ramo
• Queremos tomar as diferenças entre a base do ramo e a ponta do tronco e aplicá-las sobre a ponta do ramo
• Faça um check-out do ramo• Execute update –j ETIQ-BASE –j HEAD• Na figura, ETIQ-BASE é REL-2_0 e HEAD é 1.5
1.1 1.3 1.4 1.51.2
1.2.2Ramo “rel-2_0” 1.2.2.1 1.2.2.2
Tronco
REL-2_0
1.2.2.3
4-19
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Mesclando de Ramo para Ramo
• Queremos tomar as diferenças entre a base e a ponta do ramo origem e aplicá-las sobre a ponta do ramo destino
• Faça um check-out do ramo destino• Execute update –j ETIQ-BASE-ORIG –j ramo-dest• Abaixo, ETIQ-BASE é REL-2_0 e ramo-dest é rel-2_1
1.1 1.3 1.4 1.51.2
1.2.2Ramo “rel-2_0” 1.2.2.1 1.2.2.2
Tronco
REL-2_0
1.3.2Ramo “rel-2_1” 1.3.2.1 1.3.2.2
4-20
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Modelos de Funcionamento
• Há dois modelos de funcionamento para ramos
• Com a linha principal– Tronco evolui sempre– Ramos propagam para o
tronco– Ramos tornam-se obsoletos
em algum ponto
• Com a promoção de linhas– Ramos são “promovidos” à
medida que evoluem– Propagação é sempre para
o ramo promovido– Tronco e ramos antigos
tornam-se obsoletos
Linha principal
Promoção de linhas
4-21
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Quando Criar Ramos
• Variações sobre um mesmo tema– Crie ramos para armazenar variantes de um mesmo
sistema para clientes diferentes– Use ramos para guardar diferentes configurações de um
mesmo sistema para servidores distintos
• Correção de defeitos– Crie ramos para corrigir defeitos em liberações anteriores
de um sistema, enquanto ele evolui
• Alterações experimentais– Use ramos para realizar mudanças experimentais, que
podem ser descartadas ou parcialmente incorporadas
• Grandes mudanças– Crie ramos para implementar mudanças profundas no
sistema, que o deixarão instável por um período longo
4-22
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Lab4-2: Trabalhando com Ramos
• Criar um ramo sobre uma liberação existente
• Criar uma nova área de trabalho, sobre o ramo
• Submeter alterações no ramo• Fazer uma mescla do ramo para o tronco
4-23
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Exportando Projetos
• Em algumas situações, é necessário distribuir os arquivos mantidos sob controle de versões– Se a empresa atua como fornecedor, pode ser preciso
enviar arquivos para um cliente• Os comandos checkout e update criam áreas de
trabalho, com subdiretórios de controle CVS– Ao exportar, queremos somente os fontes
• O comando export extrai arquivos para distribuição– Atua diretamente no repositório
• cvs [op_glob] export [op_cmd] módulo...– op_glob são opções globais (-d é a mais usada)– op_cmd são opções de comando, similares a checkout
• As mais usadas são –D data, –r revisão e –k opção-k (p.e., -kv)
• A opção –d diretório também é usada, como em checkout– O argumento é o nome de um ou mais módulos
4-24
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Lab4-3: Exportando uma Liberação
• Exportar uma liberação de um projeto• Usar as revisões marcadas por uma
etiqueta• Controlar a substituição de palavras-chave
na exportação
4-25
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Recursos para Projetoscom Vários Usuários
• Criado para o uso concorrente, o CVS oferece recursos para projetos com muitos usuários
• Além das capacidades já conhecidas e do modelo copia-modifica-mescla, o CVS oferece:– A capacidade para funcionar em um modelo de edição
exclusiva de arquivos, com uma dentre duas formas:• Observando arquivos, é possível sugerir, mas não forçar, a
edição exclusiva de arquivos• Com o comando admin, pode-se implementar o modelo
trava-modifica-destrava, para garantir a edição exclusiva
– A divulgação de operações como check-ins e aplicações de etiquetas, por programas configurados em modules
– Um comando para acompanhar a atividade dos autores
4-26
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Observando Arquivos
• O CVS oferece comandos para avisar usuários quando arquivos são editados ou submetidos
• Esses comandos são úteis para:– Monitorar as atividades de membros da equipe– Acompanhar a edição de certos arquivos,
diminuindo a probabilidade de mesclas– Sugerir, mas não garantir, um modelo de edição
exclusiva
• Comandos envolvidos: watch, edit e unedit– Para seu funcionamento correto, é preciso
configurar os arquivos administrativos notify e users
4-27
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Mecânica da Observação
• Um usuário cria sua área de trabalho• Ele marca alguns arquivos para observação
– Isso é feito com o comando cvs watch on arquivos...– A operação avisa o CVS que o arquivo será observado– O gestor do projeto é em geral quem define isso
• O usuário se inclui na lista de observadores dos arquivos nos quais ele está interessado– Ele usa o comando cvs watch add sobre os arquivos
• Ele e outros usuários devem usar o comando edit antes de editar um arquivo observado– Os observadores serão notificados sobre a edição
• Ao terminar as alterações, o autor as submete (commit)– Caso queira descartá-las, usa unedit, que reverte as mudanças
e avisa os demais que o arquivo não está mais sendo editado
4-28
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Reservando Arquivos para Edição
• O modelo copia-modifica-mescla é bastante efetivo para a maioria dos projetos
• Porém, em alguns casos, pode ser preciso usar o modelo trava-modifica-destrava– Por exemplo, quando os arquivos sob o controle do CVS são
binários, criados com uma ferramenta e a mescla é impossível
• Para implementar edição exclusiva com o CVS:– Instale e configure o script rcslock, disponível na maioria das
distribuições do CVS• Ele deve ficar em um diretório acessível por todos os usuários e o
arquivo commitinfo deve ser configurado para chamá-lo– Para reservar um arquivo, use o comando admin com a
opção –l– Ao submeter alterações com commit, a trava será removida– Para desistir da reserva sem check-in, use admin com a
opção –u
4-29
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Divulgando Operações
• Outra forma de auxiliar projetos com vários usuários é divulgar operações relevantes– Por exemplo, check-ins e marcações de liberações
• Para divulgar check-ins:– Configure o arquivo loginfo para enviar e-mail para
uma lista, contendo a mensagem de log do check-in
• Para divulgar a aplicação de etiquetas:– Configure o arquivo modules, usando a opção –t
para especificar um programa para o envio de e-mail
– O programa só será invocado quando a etiqueta for aplicada com o comando rtag
4-30
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Acompanhando a Atividade do Repositório
• O CVS registra a atividade sobre o repositório no arquivo administrativo history– Para isso, esse arquivo deve existir e disponível para
escrita pelos usuários do CVS
• O comando history lista a atividade do CVS• cvs [op_glob] history [op_cmd] [arquivos...]
– op_glob são opções globais e op_cmd, opções de comando. As mais usadas são:
• -m módulo: relata o histórico somente de módulo• -D data: mostra somente o histórico a partir de data
– O argumento são zero ou mais arquivos (ou módulos)
• A saída de history pode ser configurada– Sua forma geral é uma tabela com tipos de operações,
datas usuários e arquivos afetados
4-31
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
O Comando admin
• O comando admin disponibiliza várias operações administrativas sobre o repositório– Algumas são perigosas, mantidas por razões
históricas
• cvs [op_glob] admin [op_cmd] [arquivos...]– op_glob são opções globais, op_cmd são opções do
comando, as mais usadas são:• -kopção-k: Redefine o modo de substituição de palavras-
chave; útil quando um arquivo binário é adicionado como texto
• –l rev e –u rev: Trava e destrava revisões de arquivos• –mrev:msg: Redefine a mensagem de log da revisão
– O argumento são zero ou mais arquivos ou diretórios• Cuidado: admin tem comportamento recursivo por default!
4-32
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Ferramentas para o CVS
• Com os conhecimentos adquiridos neste curso, é possível usar plenamente o CVS em qualquer projeto
• Porém, ferramentas auxiliares podem ser úteis:– Para tornar as atividades mais eficientes, com interfaces gráficas– Para ajudar usuários sem prática com a linha de comando
• Clientes gráficos:– CVSGUI: WinCVS (Windows), gCVS (UNIX), MacCVS (Macintosh)– Multi-plataforma, escritos em Java: jCVS e SmartCVS– Linux: Cervisia e LinCVS (Qt), Pharmacy (Gnome), tkCVS (Tcl/Tk)– Cliente integrado ao shell do Windows: TortoiseCVS– IDEs Java com cliente CVS integrado: Eclipse, JBuilder, NetBeans
• Ferramentas para distribuição e acesso remoto:– CVSUp, Chora, CVSviaFTP, CVSweb, jCVS Servlet, ViewCVS
• Conversores: rcs-to-cvs, sccs2rcs, VSS2CVS, pvcs2rcs
4-33
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Boas Práticas em GCS
• Como o tema de Gestão de Configuração é amplo, há várias boas práticas e padrões para a área– Livro: Software Configuration Management Patterns
(Berczuk)
• Muitas boas práticas aplicadas ao CVS foram citadas ao longo do treinamento– Manter a área de trabalho atualizada com update– Usar commit de acordo com a política em vigor– Aplicar etiquetas com tag:
• Para marcar liberações relevantes para o projeto• Antes de criar um ramo e antes de uma mescla de outro ramo
– Criar ramos (tag –b) quando uma nova linha de código for necessária: versão experimental, correção de defeitos, etc.
• Boas práticas gerais serão vistas nos próximos slides
4-34
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Boas Práticas: Área de Trabalho
• Não compartilhe áreas de trabalho– Cada autor deve ter sua área de trabalho exclusiva
• Não altere arquivos fora das áreas de trabalho• Controle a atualização de sua área de trabalho
– Não deixe que processos automáticos ou eventos externos atualizem a área sem a sua intervenção
• Mantenha a sincronia com a linha de código– Atualize a área com freqüência
• Faça check-ins com freqüência– Mas procure seguir a política da linha de código
4-35
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Boas Práticas: Linha de Código
• Atribua uma política a cada linha de código– Linhas mais experimentais podem ter um nível de
exigência menor quando à qualidade do código– Linhas mais maduras e estáveis devem ser
severas
• Defina um dono para cada linha de código– As políticas podem ser ambíguas ou pode haver
uma exceção: o dono é quem resolve
• Tenha uma linha principal– Entre linha principal e promoção de linhas, a
melhor abordagem é ter uma linha principal– Mantenha sempre a evolução dessa linha
4-36
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Boas Práticas: Ramos
• Crie ramos só quando necessário– Um ramo significa trabalho extra – tenha isso em
mente e só crie ramos quando realmente necessário
• Não crie cópias quando se deve criar ramos– Quando um ramo for necessário, use-o; não copie os
arquivos para outro diretório para evoluí-los
• Crie ramos diante de políticas incompatíveis– Versões experimentais, novos recursos, defeitos
• Postergue a criação de ramos– Deixe a criação do ramo para o último momento:
quanto menor a distância para uma mescla, melhor
• Crie ramos em vez de congelar a linha de código
4-37
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Boas Práticas: Mesclas de Ramos
• Faça as alterações que devem ser propagadas na linha que mudou menos desde a criação do ramo– Imagine uma alteração que terá que ser propagada para
diversos ramos (a correção de um defeito grave)– Faça essa alteração na linha que menos mudou desde
que o ramo foi criado – será mais fácil propagá-la
• Propague as mudanças cedo e com freqüência– Quanto menor a diferença entre as revisões, melhor: é
maior a probabilidade de se ter uma mescla automática
• Peça à pessoa certa para fazer a mescla– Escolha quem fez a alteração a ser propagada (origem)
ou quem conhece o código que irá recebê-la (destino)
4-38
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Boas Práticas: Compilação
• Código-fonte + Ferramentas = Produto– Não há lugar para passos manuais
• Faça o check-in do código original• Separe artefatos derivados do código original• Use ferramentas padrão na compilação
– Não use ferramentas esotéricas, elas podem não existir amanhã
• Se possível, integre o CVS à compilação– Os sistemas mais importantes podem ser integrados com o
CVS:• Ant: disponibiliza uma tarefa chamada cvs• make: comandos CVS podem estar em regras no Makefile
• Compile com freqüência• Guarde os logs e a saída da compilação
4-39
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Boas Práticas: Gestão de Mudanças
• Acompanhe pacotes de mudanças– Saiba quais arquivos mudaram em conjunto para atender uma
demanda (novo recurso, correção de defeito)– O CVS não oferece grande auxílio aqui, só mensagens de log
• Acompanhe propagações de pacotes de mudanças– Saiba como os pacotes são aplicados a outras linhas de
código
• Diferencie requisições de mudanças de pacotes de mudanças– Separe o que foi pedido daquilo que foi feito para atender o
pedido
• Atribua um dono a tudo– Linha de código, documento, produto, tarefa devem ter um
dono
• Mantenha a documentação atualizada– Crie documentos só quando necessário, isso ajudará!
4-40
www.mardenneubert.comwww.mardenneubert.com© 2005 Marden Neubert
Encerramento
Obrigado por participar deste treinamento!• Cobrimos praticamente todos os aspectos do
CVS:– Dimensionamento, instalação, configuração, uso– Todos os comandos (sim, vimos todos eles!)– Arquivos administrativos e variáveis de ambiente
• Agora é um bom momento para:– Tirar dúvidas– Compartilhas experiências– Fazer comentários, elogios e críticas
• Por favor, preencham os formulários de avaliação
• Meu contato: [email protected]