| layout | title | date | comments | categories | ||
|---|---|---|---|---|---|---|
post |
Olá, mundo! |
2012-07-14 13:19 |
true |
|
Opa, galera, beleza? Esse é o primeiro post aqui no meu blog. Estou usando o Octopress, falarei aqui também sobre ele.
Esse post é mais pra saber se eu tô fazendo isso direito. hehe
Até a próxima!
| layout | title | date | comments | categories | ||
|---|---|---|---|---|---|---|
post |
Introdução ao Controle de Versão com SVN - parte 1 |
2012-07-16 18:39 |
true |
|
Bom, resolvi começar com um post que escrevi a algum tempo e postei esses dias no webmatinal. Vamos falar sobre controle de versão e, para exemplificar, iremos utilizar o SVN pela linha de comando. Como usuário iniciante de Linux, venho tentando me adaptar ao ambiente já tem um tempo. Ainda sou muito noob, mas é assim mesmo.
Bom, sem mais lorotas, vamos ao que interessa. Uma das primeiras coisas (leia-se ferramentas) que tive contato logo quando comecei a estagiar/trabalhar com desenvolvimento foi o SVN. No começo, não entendia muito bem a coisa toda, achava que era só um lugar onde guardávamos o código. Leigo engano (e bota “leigo” nisso!). Com o tempo (e muitos conflitos de versão que explicarei mais adiante), percebi a verdadeira importância do controle de versão. Não é só um lugar onde nosso código fica. Achava isso por conta do modelo centralizado do SVN, onde é necessário um repositório central para guardar o código.
Acho importante entender alguns conceitos, pois PRECISAMOS ter um bom controle do código que escrevemos. Não só código, como qualquer documento que produzimos precisa estar sob algum controle de versão. Digo “PRECISAMOS” pra enfatizar a necessidade da utilização de versionamento. Isso nos proporciona um histórico do desenvolvimento do software (ou arquivo). Segundo o wikipédia:
Um sistema de controle de versão (ou versionamento), VCS (do inglês version control system) ou ainda SCM (do inglês source code management) na função prática da Ciência da Computação e da Engenharia de Software, é um software com a finalidade de gerenciar diferentes versões no desenvolvimento de um documento qualquer.
Para exemplos iremos utilizar o Subversion, ou SVN (como já citei acima). Ele é um software de controle de versão centralizado, isso quer dizer que necessita de um repositório central para armazenar seu código. A ideia é essa:
Essa imagem já nos traz dois dos principais comandos do SVN: commit e update. Para começar a falar dos comandos, vamos entender o que é uma working copy. Como já falamos, nosso código fica centralizado, ou seja, ele é armazenado em um servidor central. Para fazer as alterações no nosso código, precisamos primeiro baixar a última versão do código na nossa máquina para, então, efetuar as alterações e mandar de volta para o servidor. Quando baixamos o código do servidor para a nossa máquina, estamos criando uma “working copy”. Que fique claro que a maior parte do código no servidor deve ter sido testado!
Vejamos agora alguns comandos:
Já conhecemos alguns dos principais comandos do SVN, vamos brincar um pouco com um exemplo. Não vou falar da instalação do SVN aqui, isso é assunto para outro post. Para exemplificar, digamos que eu tenha um repositório (lugar no servidor onde eu armazeno meu código) limpo, zerado, novinho em folha e quero começar a desenvolver o projeto. Qual a primeira coisa que devemos fazer? Respondeu certo que falou “o checkout”. Mas, vamos primeiro a estrutura padrão do repositório.
Vamos, então, fazer o checkout e começar a desenvolver nosso projeto. Para o exemplo, não iremos utilizar o conceito de branches, vamos trabalhar direto no trunk, pois, como disse, falaremos sobre branches mais adiante. O código para o checkout:
{% codeblock %} $ cd /var/www/ $ svn checkout [URL do repositorio]/trunk nome_da_working_copy {% endcodeblock %}
O diretório /var/www/ é o diretório raiz do meu apache, onde estão os meus projetos. Primeiro eu vou pro meu diretório raiz e em seguinda uso o “svn checkout” se tudo estiver correto, o svn irá criar a pasta nome_da_working_copy no meu diretório de projetos, ficando assim: /var/www/nome_da_working_copy.
Pronto! Já tenho uma cópia do projeto. Agora, crie um arquivo na sua working copy chamado README.txt e coloque um texto qualquer dentro deste arquivo. Uma vez feito isso, vamos verificar o estado da nossa working copy. Como fazemos isso? Com o comando status.
{% codeblock %} $ cd /var/www/nome_da_working_copy/ $ svn status {% endcodeblock %}
Feito isso, o terminal deve retornar isso:
{% codeblock %} $ ? README.txt {% endcodeblock %}
Essa interrogação ai quer dizer que esse arquivo existe na sua working copy, mas não existe no repositório. Se fizermos o commit agora, nada será alterado no servido, ou seja, esse arquivo não será enviado para o repositório, porquê ele ainda não existe lá. Precisamos, então, adicionar esse arquivo no repositório. Para isso, utilizamos o comando add:
{% codeblock %} $ cd /var/www/nome_da_working_copy/ $ svn add README.txt {% endcodeblock %}
Agora, o SVN irá avisar que o arquivo foi adicionado ao servidor, mas ele ainda não pode ser encontrado lá, pois só existe na sua working copy. Terminadas as alterações, vamos fazer um commit e mandar essas alterações para o repositório. Esse comando é sempre utilizado com o parâmetro “-m” seguido de uma mensagem embrulhada por “”, como mostra o exemplo:
{% codeblock %} $ cd /var/www/nome_da_working_copy/ $ svn commit -m "criação do arquivo README.txt para descrição do projeto" {% endcodeblock %}
Pronto! Nosso arquivo README.txt agora está no repositório com nossas alterações. Digamos agora que outro desenvolvedor alterou esse arquivo (na working copy dele) e fez o commit com as alterações. Agora, você quer alterar esse arquivo novamente. Se você fizesse isso direto na sua working copy e fosse fazer um commit, daria erro, pois o seu arquivo está numa versão diferente do que se encontra no repositório. Isso é chamado de “conflito de versões”. Para alterar o arquivo, primeiro é necessário possuir a última versão do mesmo. Para isso, usamos o comando update antes de fazer qualquer alteração no arquivo. (atenção: esse comando deve ser executando antes de qualquer commit, os conflitos devem ocorrer na sua working copy, você resolve e manda pro servidor):
{% codeblock %} $ cd /var/www/nome_da_working_copy/ $ svn update {% endcodeblock %}
O SVN nos trará a nova versão do arquivo README.txt. Agora, nós alteramos esse arquivo e adicionamos mais conteúdo. Ao fazer o status irá aparecer um “M” no lugar da “?” (interrogação), indicando que o arquivo foi alterado na sua working copy. Diferente da criação de um arquivo, na alteração não precisamos adicionar o arquivo ao repositório novamente. Basta apenas enviar as alterações. Para isso, vamos usar o commit novamente:
{% codeblock %} $ cd /var/www/nome_da_working_copy/ $ svn commit -m "alteração do arquivo README.txt para acrescentar mais conteúdo." {% endcodeblock %}
Lembre-se sempre de descrever o commit na mensagem para que, posteriormente, possamos saber o que foi feito no commit apenas lendo a mensagem, sem ter que olhar quais arquivos foram alterados no commit e quais alterações foram feitas nesses arquivos.
Bom, visto que é o meu primeiro post aqui, acho que já falei bastante, né?! (hehe) Mas por ora, ficamos por aqui. Espero não ter falado nenhuma bobeira por aqui, mas se falei, sintam-se à vontade para corrigir nos comentários. Nos vemos no próximo post, neste mesmo canal. (hehe)
Até a próxima!