CVSNT no JDEVELOPER10g (Um dia de Trabalho) - Parte II

 

Introdução

Dando continuidade, abordaremos o trabalho diário com cvsnt no jdev10g, caso você não tenha visto, no final desta página existe o link para a primeira parte.

 

Observações

Alguns poderiam me questionar o porquê de não utilizar o subversion? eis as respostas:

 

1.1- jdeveloper apresenta algumas instabilidades e bugs no uso com subversion.

 

1.2- cvsnt é simples de instalar (em windows) , fácil de usar, muito estável e quase totalmente suportado pelo jdev, visto que, algumas características existentes no cvsnt não estão disponíveis no subversion (veja uma comparação).  

 

1.3- não reprovo o subversion e não sou adepto desta ou daquela tecnologia :), apenas apresentarei uma alternativa viável, segura e testada para que, você leitor, não perca o tempo que eu perdi até encontrar uma solução ideal :) visando produtividade, robustez e controle.

 

1.4- seguirei como modelo um tutorial do subversion com jdev10g para que possa servir de parâmetro para você no que couber.  

 

1.5- para os iniciantes em jdeveloper10g  sugiro uma lida nos artigos do autor Eduardo Santana.

 

Mãos a Obra!

 

dfcvsp2fig01.jpg
Figura 1 – Aplicação agora sobre controle, veja os ícones. 

 

Pelo fato de você ter permitido ao assistente “Checked Out” os arquivos importados, estes arquivos são exibidos no navegador e eles possuem um número de versão inicial, conforme figura acima.

 

No CVSNT, o número de versão refere-se ao repositório inteiro, não a arquivos individuais. Um número de versão próximo a um arquivo representa a última revisão na qual o arquivo foi modificado. Numa importação   nova e “zerada”, todos os arquivos terão seu número de versão configurado para “1.1.1.1”, sendo incrementado em atualizações posteriores. Quando importando em um repositório já preenchido, o número de versão será atribuído dependendo do conteúdo existente, mas será o mesmo para todos os novos arquivos importados.            

Em jdev10g, você pode ver informações de versão do arquivo clicando com o botão direito nele.

 

Os arquivos agora visíveis no Aplication Navigator, representam sua “Cópia de Trabalho” e estão prontos para o trabalho e sob controle do CVSNT!

 

Checking Out Arquivos

“Cheking Out” é uma tarefa executada quando você deseja criar uma “cópia local” de arquivos e pastas que estão sendo armazenados(remotamente)  no repositório do servidor CVSNT, nestas “cópias locais”, fora do servidor CVSNT, que você trabalha.

 

Caso você tenha importado o projeto com a opção “Perform Checkout” (conforme Parte 1)  selecionada, os arquivos importados já foram “Checkout”s. Confome a figura 1 acima.

 

Caso Contrário, clique em Versionning > Chekout Module...  e a seguinte janela aparecerá...

 

dfcvsp2fig02.jpg
Figura 2 – Fazendo o Check Out de um módulo

 

na janela acima clique em Get Refresh Module List para atualizar a lista de sistemas sobre controle no servidor e então escolhemos o módulo(pode representar também um sistema completo) e clicamos e OK.

 

Observações:

1-Atente pata o fato de que estou escolhendo a pasta pai “mywork”, e não a pasta “test”, se você escolher a pasta test, o resultado será um projeto igual dentro de outro :<(

 

2- você pode escolher qual revisão baixar(Check out) marcando Use Revision Number or Tag e digitando o número ou texto da revisão e  clicando em OK!, porém até a revisão 10.1.3.2 do jdev10g o número de versão não funciona, então você só pode usar o nome da tag :( .

 

3- Para baixar a versão mais recente deixe padrão e clique em OK! :)

 

O Resultado será semelhante a figura 3


dfcvsp2fig03.jpg 

Figura 3 - Resultado de fazer um Check Out de um projeto que já existe no jdev10g

 

Perceba que temos duas aplicações, uma mais nova e outra mais antiga, logicamente delete a mais antiga, porém não será deletada fisicamente, você terá que fazer manualmente no navegador de arquivos.

 

Adicionando e “Comitando” arquivos

Quando você cria novos arquivos, você DEVE adicioná-los ao servidor CVSNT para utilizar as vantagens de versionamento de arquivos e pastas e torná-las disponíveis a outros desenvolvedores. Você faz isso utilizando “Add” Comando, seguido pelo “Commit” Comando.

 

No Aplication Navigator crie um novo arquivo java chamado Class3.java, como fragmento de sua aplicação versionada, conforme a figura 4 abaixo:

 

dfcvsp2fig04.jpg
Figura 4 – Class3.java

 

Você percebeu que o arquivo não contêm um número de versão e o seu ícone é diferente, isto indica que o arquivo é desconhecido para o sistema de controle de versão e que você deve adicioná-lo.

 

Perceba Também que a janela Pending changes aparece na parte de baixo da janela exibindo a classe “Class3.java” como candidata ao versionamento, conforme figura 5 abaixo:

 

dfcvsp2fig05.jpg
Figura 5 – class3.java como candidata ao versionamento

 

Clique nos arquivos a serem adicionados e em seguida no sinal “de mais” (+), ou clique com o botão direito no(s) arquivo(s) e marque a opção Add...  ou  Add All..., conforme a figura 6 abaixo:

 

dfcvsp2fig06.jpg
Figura 6 – Add Command

 

Perceba que o arquivo deixa de ser “candidato” e agora se torna “eleito” :) , ou seja, agendado para adição, através da aba “Outgoing:”

 

clique na aba “Outgoing:” e clique com o botão direito novamente em Class3.java, você verá a opção de acrescentar um comentário(Obrigatório) e logo após dê um commit, conforme a figura 7.

 

O comentário será visível quando você visualizar o Histórico de Versionamento ( Versioning History ) de um arquivo e ajudará você e outros desenvolvedores  no projeto a identificar uma versão de outra.

 

dfcvsp2fig07.jpg
Figura 7 – Comente e Commit

 

Pronto! seu arquivo agora está sob controle de versão no repositório CVSNT

 

Dica: Em um ambiente de desenvolvimento, evite conflitos desnecessários e o conseqüente re trabalho para resolvê-los, você deve dar um Update em seus arquivos antes de acionar um Commit nos mesmos.

 

Atualizando Arquivos

“Updating” é o processo de atualização de seus arquivos locais com os arquivos do servidor, ou seja, tenha uma cópia idêntica do arquivo ou pasta que está no servidor.

 

Você pode dar um Update em seus arquivos clicando com o botão direito nele ou em seu “diretório pai” e em seguida...  Versioning > Update ou  ctrl+alt+j, marcando a opção “Overwrite Local Changes”.

 

Você saberá que existe uma versão mais atualizada de um arquivo no repositório quando tentar dar um Commit em sua versão local do arquivo e aparecer um erro informando que não é possível proceder com o commit, conforme figura 8 abaixo:

 

dfcvsp2fig08.jpg
Figura 8 – Conflito

 

Dê um Update no arquivo e o erro não aparecerá mais, porém você terá que resolver o conflito.

 

Outra forma de saber se sua cópia local está atualizada é clicando em Refresh na aba Incomming, conforme figura 9 abaixo: 

 

dfcvsp2fig09.jpg
Figura 9 – exibindo que  Class3.java foi modificada por outro desenvolvedor

 

Você pode atualizar sua inteira cópia de trabalho, diretórios únicos, pacotes ou arquivos individuais

 

Editando Arquivos

Você edita suas cópias de trabalho diretamente em jdev10g ou usando uma ferramenta externa. Ambos binário e arquivos texto podem ser controlados pelo sistemas de versão, portanto, você pode usar editores de texto, programas gráficos ou qualquer outra ferramenta.

 

Você não precisa registrar uma “edição de arquivo”, em outras palavras, você não precisa obter um “edit”  como ocorre em outros Sistemas de Versionamento. Quando você modificada um arquivo e salva este arquivo, CVSNT automaticamente detecta esta mudança e modifica o status de versionamento do arquivo no Jdev10g na aba Pending Changes.

 

Dica: Para ter certeza que você está vendo o status mais atual do Arquivo no Jdev10g, clique em Refresh  no Aplication Navigator da barra de ferramentas.

 

Quando mais que um desenvolvedor está trabalhando no mesmo arquivo, precisa haver uma forma de prevenir conflitos. A forma preferível para solucionar isto é o “modelo copia-modifica-merge”. Neste modelo  cada desenvolvedor trabalhando num arquivo pega uma cópia dele, modifica-o, e então merge com outras cópias de outros desenvolvedores. Isto pode aparentar, como se ocorre-se conflitos a todo tempo, mas na prática raramente ocorre, porém quando ocorre há uma forma eficiente de resolvê-lo.

 

Fim da parte 2 – nos vemos na parte final 3 :)

 

OBS: Este artigo, bem como o código-fonte, é de livre divulgação, desde que, citada a fonte

Dave Fernandes – Analista Programador Java - UFPA

Blog: http://consubr.blogspot.com

Email: consubr@yahoo.com.br