+1
Criando um projeto com controle de versão PDT Eclipse Galileo + SVN
Para exemplificar como funciona o controle de versão iniciamos criando um arquivo qualquer. No meu exemplo vou criar um arquivo index.html com o seguinte código:
Salve. Quando você cria arquivos que ainda não existem no repositório ele fica com uma interrogação junto ao ícone do arquivo indicando que este arquivo não está sobre controle de versão.
Vamos adicioná-lo ao controle de versão.
Clique sobre o arquivo ou sobre o diretório do projeto com o botão direito do mouse e depois em Team/Commit. Uma janela indicando o[s] arquivo[s] que estão prestes a serem ‘comitados’. Adicione um comentário se desejar – é melhor acostumar a sempre comentar os commits porque eles podem ser muito uteis no futuro – e clique em OK.
Neste momento o ícone foi alterado e caso esteja usando as configurações padrão haverão algumas informações adicionais ao lado do nome do arquivo que é a revisão e a data de criação da revisão.
Altere o conteúdo do arquivo criado. Ao salvar o arquivo o ícone dele conterá um asterísco (e não asterístico) indicando que existem diferenças entre o arquivo local e o presente no repositório. Para ver as diferenças clique com o botão direito sobre o arquivo e vá em Compare with/Latest From repository. Uma janela exibindo os dois arquivos será exibida mostrando as linhas que são diferentes. Essa janela é importante quando queremos ver o que foi alterado e caso queira pegar o conteúdo antigo pode-se navegar pelas diferenças exibidas com os ícones de setas na parte superior e substituir o conteúdo existente localmente com o conteúdo remoto clicando no ícone de copy current change from right to left (o segundo da esquerda para a direita).
Dê commit neste arquivo contendo alguma alteração. Uma nova revisão com o valor da antiga incrementado em 1 unidade será exibido ao lado do arquivo. É possível ver as revisões existentes para o arquivo juntamente com os comentários indicativos clicando com o botão direito sobre o arquivo e em seguida em Team/Show History. A janela de histórico será exibida.
Para voltar um arquivo para uma revisão usamos Replace With/Revision. Uma lista será exibida. Clique com o botão direito sobre a revisão desejada e depois em Get Contents. O arquivo será substituído localmente com o conteúdo da revisão escolhida.
Eventualmente conflitos podem aparecer devido a cópia local estar com conteúdo mais recente com o existente no repositório. Neste caso pode-se resolver clicando em Team/Mark resolved para escolher o conteúdo que interessa (cópia local existente, cópia do repositório ou revisão base), ou Team/Edit Conflits para editar os pontos conflitantes ponto a ponto.
Essas instruções servem tanto para arquivos únicos quanto para diretórios inteiros ou mesmo projeto inteiro.
Criando um branch/tag.
Após iniciar o desenvolvimento do projeto e supondo que todos os pontos ou arquivos necessários já estejam presentes pode-se criar um branch do projeto. Acostume-se sempre a efetuar update antes de qualquer alteração de versão.
Clique sobre o projeto com o botão direito do mouse e depois em Team>Branch/Tag. Como é o primeiro branch a ser criado o camindo deverá ser indicado na url. Adicione /branches/b1.0.0 ao caminho exibido e clique em NEXT. Se foi feito o commit antes de criar o branch o melhor é manter a seleção padrão. Caso sua cópia local seja mais recente que o repositório e você por algum motivo não deseja fazer o commit (isso acontece muito quando se trabalha em ambiente colaborativo) escolha Working Copy. É possível também escolher uma revisão específica. Deixe a opção switch working copy to new branch/tag marcada para que o sistema automaticamente alterne para o branch criado.
Os mesmos passos devem ser feitos para criar tags apenas alterando a letra b por v.
Padrão de nomenclaturas de versões
A nomenclatura que utilizei para o exemplo do branch foi b1.0.0.
Eu acostumei a usar a inicial do que vou criar (<u>b</u> para branch e <u>v</u> tag) seguido da versão a ser criado.
Como padrão uso X.Y.Z onde X é a versão do software. Esta é alterada quando o núcleo da aplicação sofre alterações que mudem o seu comportamento ou o seu visual, Y é alterado quando é adicionado alguma nova funcionalidade ou alguma melhoria em funcionalidade existente e Z é alterado quando feito alguma correção emergencial de bug (também chamado de fix).
Estes são os principais passos para a criação dos repositórios. No próximo artigo explicarei um pouco mais sobre controle de versão em projetos colaborativos. Até a próxima.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <title>Controle de Versão</title> </head> <body> <h2>Versão 1.0.0</h2> </body> </html>
Vamos adicioná-lo ao controle de versão.
Clique sobre o arquivo ou sobre o diretório do projeto com o botão direito do mouse e depois em Team/Commit. Uma janela indicando o[s] arquivo[s] que estão prestes a serem ‘comitados’. Adicione um comentário se desejar – é melhor acostumar a sempre comentar os commits porque eles podem ser muito uteis no futuro – e clique em OK.
Neste momento o ícone foi alterado e caso esteja usando as configurações padrão haverão algumas informações adicionais ao lado do nome do arquivo que é a revisão e a data de criação da revisão.
Altere o conteúdo do arquivo criado. Ao salvar o arquivo o ícone dele conterá um asterísco (e não asterístico) indicando que existem diferenças entre o arquivo local e o presente no repositório. Para ver as diferenças clique com o botão direito sobre o arquivo e vá em Compare with/Latest From repository. Uma janela exibindo os dois arquivos será exibida mostrando as linhas que são diferentes. Essa janela é importante quando queremos ver o que foi alterado e caso queira pegar o conteúdo antigo pode-se navegar pelas diferenças exibidas com os ícones de setas na parte superior e substituir o conteúdo existente localmente com o conteúdo remoto clicando no ícone de copy current change from right to left (o segundo da esquerda para a direita).
Dê commit neste arquivo contendo alguma alteração. Uma nova revisão com o valor da antiga incrementado em 1 unidade será exibido ao lado do arquivo. É possível ver as revisões existentes para o arquivo juntamente com os comentários indicativos clicando com o botão direito sobre o arquivo e em seguida em Team/Show History. A janela de histórico será exibida.
Para voltar um arquivo para uma revisão usamos Replace With/Revision. Uma lista será exibida. Clique com o botão direito sobre a revisão desejada e depois em Get Contents. O arquivo será substituído localmente com o conteúdo da revisão escolhida.
Eventualmente conflitos podem aparecer devido a cópia local estar com conteúdo mais recente com o existente no repositório. Neste caso pode-se resolver clicando em Team/Mark resolved para escolher o conteúdo que interessa (cópia local existente, cópia do repositório ou revisão base), ou Team/Edit Conflits para editar os pontos conflitantes ponto a ponto.
Essas instruções servem tanto para arquivos únicos quanto para diretórios inteiros ou mesmo projeto inteiro.
Criando um branch/tag.
Após iniciar o desenvolvimento do projeto e supondo que todos os pontos ou arquivos necessários já estejam presentes pode-se criar um branch do projeto. Acostume-se sempre a efetuar update antes de qualquer alteração de versão.
Clique sobre o projeto com o botão direito do mouse e depois em Team>Branch/Tag. Como é o primeiro branch a ser criado o camindo deverá ser indicado na url. Adicione /branches/b1.0.0 ao caminho exibido e clique em NEXT. Se foi feito o commit antes de criar o branch o melhor é manter a seleção padrão. Caso sua cópia local seja mais recente que o repositório e você por algum motivo não deseja fazer o commit (isso acontece muito quando se trabalha em ambiente colaborativo) escolha Working Copy. É possível também escolher uma revisão específica. Deixe a opção switch working copy to new branch/tag marcada para que o sistema automaticamente alterne para o branch criado.
Os mesmos passos devem ser feitos para criar tags apenas alterando a letra b por v.
Padrão de nomenclaturas de versões
A nomenclatura que utilizei para o exemplo do branch foi b1.0.0.
Eu acostumei a usar a inicial do que vou criar (<u>b</u> para branch e <u>v</u> tag) seguido da versão a ser criado.
Como padrão uso X.Y.Z onde X é a versão do software. Esta é alterada quando o núcleo da aplicação sofre alterações que mudem o seu comportamento ou o seu visual, Y é alterado quando é adicionado alguma nova funcionalidade ou alguma melhoria em funcionalidade existente e Z é alterado quando feito alguma correção emergencial de bug (também chamado de fix).
Estes são os principais passos para a criação dos repositórios. No próximo artigo explicarei um pouco mais sobre controle de versão em projetos colaborativos. Até a próxima.
Páginas:
1
2
Novo Comentário: