Isaque Alves

Olá, pessoal. Não sou professor, sou apenas um estudante de Sistemas de Informação indo para o 3º ano do curso (falta pouco!!).

Como colega de outros estudantes, percebo que apesar de todo o esforço de muitos professores em sala de aula ou laboratórios, muito pouco do que eles passam é realmente aproveitado.

Observei o seguinte: Há uma grande dificuldade em se apreender conceitos simples como ‘polimorfismo’, herança e até ocorrem confusões quanto aos termos overload e override. Além disso, a maioria dos estudantes parece perdido frente a conceitos como ‘encapsulamento’: não sabem decidir quando declarar um método ou atributo como público, privado ou protegido (public, private ou protected).

Isso é ruim… muito ruim.

Decidi então partilhar um pouco do que aprendi (Sei… existem muitos conceitos, muitos posts pela internet apresentando o mesmo assunto…), mas não vamos ficar só na teoria, na apresentação de conceitos ou códigos previamente elaborados.

Minha proposta aqui vai além, e meu objetivo é demonstrar claramente cada conceito com base em uma das melhores questões de avaliação de programação que eu já vi.

Leia mais…

Depois de um mó tempão sem postar nada, ocupado pracaramba, to de volta pra prosseguir com minha explanação.

Paramos na demonstração da inicialização do repositório:

isaquealves@localhost$ hg init

O comando acima cria uma estrutura para armazenamento das informações sobre o projeto em desenvolvimento, mas não registra nada. O controle de versão só começa quando executamos outro comando:

isaquealves@localhost$ hg add

ou

isaquealves@localhost$ hg addremove

É mais interessante usar o hg addremove apenas apartir da póxima revisão pois ele irá realizar sempre de uma vez uma rotina de checagem e detectará se há arquivos novos e se arquivos presentes na versão anterior foram removidos.

Após isso, executamos um commit:

isaquealves@localhost$ hg commit -m “Commit revisão 1.0.1″

ou simplesmente

isaquealves@localhost$ hg commit

Pra quem não gosta nem um pouco de ter que usar o fabuloso terminal de comandos, uma dica:

Há uma extensão para o nautilus que possibilita usar o mercurial apenas com o costumeiro ‘clique com o botão direito do mouse’…
Em particular uso o mercurial via terminal para obter clones de repositórios remotos, mas em meu desktop, dou preferência a usar o ‘nautilus-mercurial’ e o ‘tortoise-hg’.

Para instalar a extensão do nautilus, se você estiver usando o Ubuntu 9.04, use:
apt-get install nautilus-mercurial-tortoisehg
A versão oficialmente suportada até o momento em que escrevo este post é a 0.7.2.

Semana passada, após uma série de problemas indesejados com hardware de produção, decidi que iria mesmo utilizar um dos sistemas disponíveis para controle de versão. Inicialmente cogitei utilizar o SVN, que já conheço e utilizo, embora sem tanta frequência. Após uma boa pesquisa, e notando que o NetBeans (meu IDE favorito do momento) possuia suporte ao Mercurial, decidi experimentá-lo.
Sim. Decidi, mas não sem antes procurar entender os recursos que ele me ofereceria.

Por que o Mercurial?

Bem, também pensei isso:

- “Ora, por que arriscar com um sistema que ainda terei que aprender a usar?”

A resposta foi simples: Pela facilidade e reduzida quantidade de recursos a serem utilizados.

O Mercurial, ao contrário do Subversion (SVN) e do Concurrent Version System (CVS) não precisa de um processo servidor em execução para realizar efetivamente o controle de versão.

Por que então, não usar o GIT, famoso por ter sido escrito por Linus Torvalds?

Novamente o quesito simplicidade. O GIT é realmente muito bom, mas no momento, eu precisava de algo simples. então, o Mercurial foi a opção.

Não pretendo descrever os recursos do Mercurial nem traçar um paralelo em relação a outros CVS, apenas quero relatar a minha experiência.

Meu primeiro ‘repositório’

Vamos direto ao assunto.

Trabalho com desenvolvimento para web, e particularmente uso PHP para construir a parte lógica dos sistemas, preciso constantemente revisar algumas partes de código (acho que todo programador faz isso, ou não?). Tô enrolando de novo, não é? Foi mal…

Pois bem. Criei uma aplicação de teste para fazer esse primeiro repositório. (Lembrando que eu uso GNU/Linux, então “Terminal”,”emulador de terminal”, “linha de comandos”,”mkdir”, “touch”, “mkdirhier”, serão termos constantes aqui…).

Como vocês podem notar, é uma aplicação simples. Apenas esbocei uma possível estrtura, não usável talvez na ‘vida real’…
Observem o uso particular do comando mkdirhier:

isaquealves@localhost$mkdirhier application/{view/{css,html},libs/{js,php},doc/{html,css}}

Ele cria toda a estrutura de diretórios necessária para o inicio do trabalho.
Eu poderia ter usado mkdir -p, mas… Keep It Simple, Stupid…

Partindo do princípio de que eu tenho o mercurial instalados…
Agora estarei mostrando como criar o repositório. Por etapas, vou mostrar o conteudo de todos os diretorios, depois, criar um arquivo index.html em application/docs/html com o conteudo “Aqui ficará o conteudo da Documentação”, um arquivo index.php em application sem conteudo, um arquivo css e um html em application/view/css e application/view/html e inicializar o repositorio. Depois de inicializado vou confirmar a adição de todos os arquivos ao repositorio.

Até aqui, o único comando novo que apareceu foi o hg init. Esse comando inicia o repositório.
Os próximos passos serão clonar o repositório, adicionar os arquivos ao clone, o que eu demonstrarei numa próxima postagem. Por enquanto, fiquem com isso…