CVS - Slides Parte 1 - Introdução
•Als PPT, PDF herunterladen•
0 gefällt mir•957 views
O documento introduz conceitos básicos de gestão de configuração e do sistema de controle de versões CVS. Explica que o CVS permite o trabalho concorrente em arquivos, armazenando versões anteriores. Também define termos como repositório, módulo, área de trabalho, check-out, check-in e revisão.
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (14)
Ähnlich wie CVS - Slides Parte 1 - Introdução
Ähnlich wie CVS - Slides Parte 1 - Introdução (20)
CVS - Slides Parte 1 - Introdução
- 1. Introdução a Gestão de Configuração e CVS Módulo 1 Foco: Geral
- 10. Fases, Disciplinas e Iterações
- 12. Arquitetura
- 14. Ilustração do Cenário Básico
- 16. Ilustração do Cenário Complexo
- 31. Liberação: Antes da Marcação
- 32. Liberação: Após a Marcação
Hinweis der Redaktion
- 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.
- Este slide mostra nossa agenda para este primeiro módulo do treinamento.
- 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.
- 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.
- 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.
- 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.
- 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.
- É 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.”
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 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.
- 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:\\Trabalho\\alomundo . Examinamos então o histórico do arquivo AloMundo.java : C:\\Joao\\alomundo> cvs log AloMundo.java Podemos também verificar o status desse arquivo e verificar que ele está atualizado: C:\\Joao\\alomundo> 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:\\Joao\\alomundo> 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?
- 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 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.
- 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.
- 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 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 .
- 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.
- 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 .
- 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 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.
- 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.
- 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.
- 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.
- 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.
- 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 é 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.
- 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 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...)
- 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.
- 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.
- 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.
- 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.
- Para fechar nossa visão geral de gestão de configuração e CVS, vamos passar por alguns recursos gerais que o CVS oferece. Isso vai nos dar uma noção melhor do funcionamento do CVS e ajudar a entender alguns comandos, opções e arquivos de configuração. Em primeiro lugar, uma das características que torna o CVS simples e poderoso é o fato do seu repositório ser uma árvore de diretórios normal em um sistema de arquivos. Com isso, permissões e segurança podem ser controladas usando-se os recursos do sistema operacional onde o repositório está localizado. Os históricos, por sua vez, são arquivos comuns, o que nos deixa aberta a possibilidade de editá-los diretamente para contornar problemas. A grande maioria dos comandos CVS têm por default um comportamento recursivo. Isto significa que, quando executados sobre um diretório, eles se aplicam a todos os arquivos debaixo daquele diretório, recursivamente. Estes mesmos comandos, quando executados sem argumentos, aplicam-se ao diretório corrente e, portanto, a todos os arquivos nele e em subdiretórios dele. Isso é interessante para diversos comandos, como update e commit , mas pode ser perigoso para outros. É possível mudar esse comportamento usando-se a opção –l (a letra “ele”, de local). Essa opção pode inclusive ser configurada para se aplicar a todos os comandos, colocando-a no arquivo de configuração pessoal .cvsrc , que veremos adiante. Nesse caso, para desligá-la, a opção –R deve ser usada. Os arquivos que controlam a área de trabalho (aqueles sob os diretórios CVS) podem guardar algumas opções para que elas não precisem ser especificadas a cada comando. As opções que têm essa característica são chamadas de “aderentes”. Em inglês, usa-se o termo sticky option . Exemplos de opções com essa característica são: a especificação de etiquetas e ramos a serem usadas na área de trabalho (opção –r ), idem para datas (opção –D ), ou para palavras-chave (citadas a seguir, opção –k ). Para “limpar” essas opções, usa-se a opção –A em update .
- O CVS possui um recurso chamado substituição (ou expansão) de palavras-chave, que permite a inclusão automática de informações sobre revisões no conteúdo dos arquivos. A motivação para esse recurso é a seguinte. Enquanto os arquivos estão na cópia de trabalho, é possível obter dados através dos comandos log e status . Mas, quando os arquivos são distribuídos, essa informação é perdida. Além disso, é mais conveniente ver algumas informações (como a revisão atual, a data da última modificação ou o último autor a modificá-lo) no próprio arquivo do que na linha de comando. Para contornar esses problemas, o autor pode inserir nos arquivos palavras-chave no formato $ PalavraChave $ , como $Revision$ , $Author$ ou $Date$ . Sempre que uma revisão for criada, a palavra-chave é substituída pela informação correspondente, segundo critérios de controle. Pode-se controlar a substituição de palavras-chave – por exemplo, desabilitá-la para arquivos binários – através de modos de substituição. Cada arquivo tem um modo default de substituição, registrado no repositório, e um modo local de substituição, associado a cada cópia de trabalho. O modo de substituição de um arquivo é apelidado opção-k , pois é especificado pela opção –k . Outra característica interessante do CVS são os arquivos ignorados. Como vimos, alguns arquivos não devem ser colocados sob controle de versões, tais como arquivos resultantes de compilação. Idem para arquivos de back-up, arquivos de saída de comandos, etc. Não queremos que o CVS sequer veja esses arquivos. Para isso, é possível fazer com que o CVS ignore arquivos de acordo com padrões de nome. Por default, o CVS já ignora diversos padrões ( *.o , *~ , etc.) e podemos adicionar outros padrões a essa lista. Também conseguimos configurar outras características de tratamento de arquivos de acordo com padrões de nome. O melhor exemplo é o de arquivos binários, que não devem passar por substituição de palavras-chave e nem pela substituição de fins-de-linha (o CVS armazena os históricos de acordo com a convenção de fins-de-linha do sistema onde o repositório se encontra). Esse recurso do CVS nos permite por exemplo, dizer que todos os arquivos *.doc devem ser importados e tratados como binários.
- Como já vimos, o modelo de funcionamento padrão do CVS é permitir que usuários alterem simultaneamente um mesmo arquivo. É possível também que usuários escolham ser avisados sobre quem está editando certos arquivos, para que eles possam se comunicar e evitar conflitos no momento do check-in. Isso é feito através do comando watch . Com a execução desse comando, o arquivo passa a ser observado por um ou mais usuários. Com isso, a capacidade de alteração simultânea do CVS é mantida, mas o arquivo fica com permissão de somente leitura nas áreas de trabalho e os usuários têm que explicitamente informar que irão editar um arquivo observado, através do comando edit . Os usuários observadores são notificados sobre eventos relativos a arquivos observados. O CVS representa revisões por números separados por pontos. Apesar dessa numeração ter sua lógica, nem sempre é interessante usá-la. Para isso, o CVS usa etiquetas, que associam nomes mais relevantes a revisões e, mais interessante, aplicam-se a vários arquivos. Por outro lado, às vezes queremos obter ou comparar revisões pela data em que foram criadas. O CVS permite que essas três alternativas sejam usadas para se obter revisões, em diversos comandos. Números de revisões e etiquetas são especificados pela opção –r , enquanto que datas, pela opção –D . Entre os comandos que reconhecem essas opções estão update , diff , log , export . O CVS consulta algumas variáveis de ambiente para configurar certos comportamentos. Como exemplos estão programas a serem usados, caminhos e outros detalhes. Veremos adiante uma lista mais completa dessas variáveis e seus efeitos. O mais interessante sobre esse recurso é que, quando o CVS está funcionando no modo cliente/servidor, essas variáveis são lidas no ambiente do cliente e passadas ao servidor. Com isso, cada usuário pode configurar uma parte do comportamento do servidor à sua maneira.