domingo, 2 de fevereiro de 2014

Tutorial EGit - Parte 02 - Importando projeto do Github.com

Neste segundo tutorial da série Egit mostraremos como criar um repositório no Github.com e clonar um projeto para o Eclipse.

O Github é um serviço de compartilhamento de código-fonte gratuito. Ele implementa o sistema de controle de versões GIT.

Passo 01 - Após criar uma conta no Github vá para a página inicial https://github.com/. Clique em "Create a new repo" como demonstrado na figura abaixo:


Passo 02 - Digite o nome desejado para o repositório e então clique em "Create repository". OBS: Somente repositórios públicos podem ser criados gratuitamente. Repositórios privados estão sujeitos a cobrança por parte do site.


Passo 03 - No Eclipse, clique no menu "File" e escolha a opção "Import...".


Passo 04 - Expanda a aba "Git" e escolha "Projects from Git". Clique em "Next >".


Passo 05 - Escolha "Clone URI". Clique em "Next >".


Passo 06 - Vá na página do seu repositório no Github.com e copie a URL de clonagem do seu repositório. Ela é algo do tipo https://github.com/<nome do usuário github>/<nome do repositório>.git.


Passo 07 - No Eclipse, cole a URL de clonagem e adicione suas informações de login. Marque a opção "Store in Secure Store" para o Eclipse lembrar sua senha. Clique em "Next >"


Passo 08 - Aparecerá uma tela de seleção de branches. Como o repositório está vazio, não aparecerá nenhuma neste caso. Clique em "Next >".


Passo 09 - Escolha o diretório local para o armazenamento das versões. Clique em "Next >".


Passo 10 - Selecione a opção "Import existing projects". Clique em "Next >".


Passo 11 - Clique em "Finish".


Com estes 11 passos, o tutorial está concluído. O projeto agora deve estar adicionado ao seu Eclipse e pronto para ser trabalhado.

quarta-feira, 29 de janeiro de 2014

Comparação do Git com outros SCV

O foco dos trabalhos relacionados ao blog se limitou principalmente ao Git. Entretanto ele é apenas um sistema de controle de versão existente no mercado. Devido a suas características e principalmente por ser um sistema de controle de versão distribuído, ele vem ocupando uma grande parcela no mercado. Mas assim como ele existem vários outros que ainda são muito utilizados e estão disponíveis.

O primeiro deles que ainda é muito utilizado, apesar de estar em decadência, é o Subversion. Ele foi fundado pela Apache como o objetivo de substituir o antigo CVS. Assim como grande parte dos software da Apache, ele é um software de licença livre e foi lançado em 2004. Uma das suas principais características é ser um sistema de controle de versão centralizado. Não que isso seja uma desvantagem, mas atualmente o que mais se procura é um sistema de controle de versão distribuído devido a sua mobilidade. Entretanto isso está mais ligado as políticas da empresa ou características do projeto do que uma comparação de qual dos dois tipos é o melhor. Apesar disso o Subversion ainda é o sistema de controle de versão mais utilizado. Ele possui facilidade em seu uso, cada cliente possui uma cópia dos arquivos do projeto versionado e o sincronismo com o repositório depende do servidor.

O segundo sistema de controle de versão também muito utilizado é o ClearCase. Na verdade ele abrange muito mais que o controle de versão. Ele é considerado um sistema de gerenciamento de configuração. Desenvolvido pela IBM, ele faz parte da família Rational. Além de realizar o controle de versão ele faz o gerenciamento de área de trabalho, realiza o suporte para desenvolvimento paralelo, realiza a segurança de IP efetiva e realiza auditoria de compilação. Assim como praticamente todas as ferramentas da IBM, o ClearCase é uma solução paga, entretanto tem um grande poder de gerenciamento. Além disso a IBM afirma que o ClearCase é uma solução flexível (atende desde pequenas equipes até grandes equipes geograficamente distribuída), entretanto não é isso que se aplica na prática. Não se vê o ClearCase em pequenas empresas. Possivelmente pelo fato do alto custo.

O terceiro sistema de controle de versão também muito utilizado é o Mercurial. Assim como o Git, ele se enquadra em um sistema de controle de versão distribuído, como também se assemelha por ser um software de licença livre e é compatível com diversas plataformas. Na verdade não há diferença perceptível entre os dois. Quando o objetivo é escolher entre os dois para o uso em um projeto as opiniões são mais subjetivas do que técnicas. 


Além desses mencionados, existem outros como o Visual SourceSafe da Microsoft, como também o CVS, entre outros.

terça-feira, 28 de janeiro de 2014

Tutorial EGit - Parte 01 - Instalação

O EGit é um plugin desenvolvido para a IDE Eclipse. Ele permite o uso do sistema de controle de versão GIT na plataforma Eclipse.

Neste tutorial será utilizado como exemplo a versão Kepler do Eclipse.

Passo 01 - Com o Eclipse aberto clica no menu "Help" e escolhe a opção "Install New Software..."


Passo 02 - Na janela que abre, clica no botão "Add...". Aparecerá uma nova janela onde deverá ser preenchida a URL de instalação do EGit: http://download.eclipse.org/egit/updates. Após isso clica em OK


Passo 03 - Nessa janela aparecerão os arquivos do EGit para download. Selecione os demonstrados na figura abaixo e em seguida clica em "Next >"


Passo 04 - Seleciona a opção de "Aceitar os termos da licença" e clica em "Finish".


Feitos esses passos, o EGit fará o download e instalação no Eclipse. Após isso é só reiniciar o Eclipse e o EGit estará pronto para o uso.

Apresentação sobre Sistemas de Controle de Versão

Abaixo seguem os slides da apresentação feita em 06/01/2014 acerca dos Sistemas de Controle de Versão.

domingo, 19 de janeiro de 2014

Sistema de Controle de Código Fonte (Source Code Control System - SCCS)

O SCCS é um sistema de controle de revisão inicial, voltado para o código-fonte do programa e outros arquivos de texto.  Ele  é um sistema completo de comandos que permite que usuários específicos possam controlar e rastrear as alterações feitas em um arquivo SCCS. Arquivos SCCS permitem que várias versões do mesmo arquivo possam existir simultaneamente, o que pode ser útil no desenvolvimento de um projeto que requer muitas versões de arquivos grandes.

Os comandos SCCS suportam  um conjunto de caracteres multibyte (Multibyte Character Set  - MBCS), e formam um sistema completo para criar, editar, converter ou alterar os controles sobre os arquivos SCCS. Um arquivo SCCS é qualquer arquivo de texto controlado com comandos SCCS. Todos os arquivos SCCS tem o prefixo s., O que os diferencia de arquivos de texto normais.

Se você quiser olhar para a estrutura de um arquivo de SCCS, deve-se  usar o comando pg ou um comando semelhante ao exibir seu conteúdo. No entanto, não se deve usar um editor para alterar diretamente o arquivo, pois pode danificá-lo.

Para alterar o texto em um arquivo SCCS, use um comando SCCS (como o comando get) para obter uma versão do arquivo para edição, e depois usar qualquer editor para modificar o texto. Depois de alterar o arquivo, use o comando delta para salvar as alterações. Para armazenar as versões separadas de um arquivo, e controlar o acesso ao seu conteúdo, os arquivos SCCS tem uma estrutura única.

Um arquivo CCSC é composto de três partes, vistas a seguir.

Tabela Delta

Em vez de criar um arquivo separado para cada versão de um arquivo, o sistema de arquivos SCCS apenas armazena as alterações para cada versão de um arquivo. Essas mudanças são conhecidas como deltas. As alterações são controladas pela tabela de delta em cada arquivo SCCS.

Cada entrada na tabela delta contém informações sobre quem criou o delta, quando o criou, e por que eles criaram. Cada delta tem um SID específico (número de identificação) de até quatro dígitos. O primeiro dígito é o lançamento, o segundo dígito do nível, o terceiro dígito do ramo, e o quarto dígito da sequencia.
Cada vez que um novo delta é criado, a ele é dado o próximo maior número SID por padrão. Essa versão do arquivo é construída usando todos os deltas anteriores. Normalmente, um arquivo SCCS cresce em sequencia, de modo que cada delta é identificado apenas por seu lançamento e nível. No entanto, um arquivo pode ramificar e criar um novo subconjunto de deltas. O arquivo, em seguida, tem um tronco, com deltas identificados pela liberação e nível, e um ou mais ramos, que têm deltas contendo todas as quatro partes de uma SID. Em um ramo, os números de versão e nível são fixos, e novos deltas são identificados, alterando os números de sequencia.

Controle e acompanhamento de flags em arquivos SCCS

Após tabela delta em um arquivo SCCS, uma lista de sinalizadores começando com o @(arroba) definem as várias opções de acesso e monitoramento do arquivo SCCS.  Algumas das funções flags SCCS incluem:
  • Designação usuários que podem editar os arquivos
  • Bloquear certos lançamentos de um arquivo de editar
  • Permitindo a edição conjunta do arquivo
  • Mudanças de referência cruzada para um arquivo


Corpo de um arquivo SCCS

O corpo do arquivo SCCS contém o texto para todas as diferentes versões do arquivo. Consequentemente, o corpo do arquivo não parece ser um arquivo de texto padrão. Os caracteres de controle entre parênteses fazem parte do texto e especificam quais deltas criados ou excluídos dele. Quando o sistema SCCS constrói uma versão específica de um arquivo, os caracteres de controle indicam as partes do texto que correspondem a cada delta. As peças selecionadas do texto são então usadas para construir essa versão específica.

Fontes:

en.wikipedia.org/wiki/Source_Code_Control_System
publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=%2Fcom.ibm.aix.genprogc%2Fdoc%2Fgenprogc%2Fsccs.htm

segunda-feira, 6 de janeiro de 2014

Melhores práticas no uso dos Sistemas de Controle de Versão

Este post apresenta um conjunto de boas práticas que podem ser aplicadas tanto na utilização de Sistemas de Controle de Versão centralizados como também na utilização dos distribuídos.

Descreva o que foi realizado para cada commit
Escrever uma boa mensagem de commit leva pouco tempo. Em contra partida, evita a perda de tempo na busca de alterações relacionadas a determinado assunto.

Cada commit deve ter um único propósito
Pode acontecer que durante o desenvolvimento de uma tarefa, perceba-se outra questão que precisa de correção. Primeiro deve se commitar os arquivos referentes a essa questão recém descoberta e depois os arquivos relacionados à tarefa de origem. Com isto, caso seja necessário desfazer alguma funcionalidade, somente esta funcionalidade será desfeita e não as outras que foram indevidamente relacionadas.

Evite commits indiscriminados
Como regra geral, não execute commit sem fornecer os arquivos específicos para commitar. Se você não fornecer nenhum nome de arquivo, então o commit irá submeter cada arquivo alterado e pode acontecer de mudanças temporárias para fins de depuração acabem também sendo submetidas.

Compartilhe suas alterações frequentemente
Depois de ter realizado a tarefa por completo, você deve compartilhar essas alterações com os seus colegas o mais rápido possível.

Comunicação com seus colegas de trabalho
O sistema de controle de versão pode frequentemente mesclar as alterações que diferentes pessoas fazem simultaneamente. No entanto, quando duas pessoas editam uma mesma linha, surge um conflito que só pode ser resolvido manualmente. Para evitar isso, é aconselhável o diálogo com seus colegas de trabalho de modo que um possa commitar antes que o outro comece a modificar. 

Não submeter os arquivos gerados
O controle de versão é destinado aos arquivos que as pessoas editam. Logo, os arquivos gerados não devem estar nos commits. Um exemplo de arquivos gerados são os arquivos binários que resultam da compilação dos arquivos de classe.  

Entenda sua ferramenta de mesclagem
A parte menos agradável de trabalhar com controle de versão é a resolução de conflitos . Se você seguir as melhores práticas, raramente você vai ter que resolver conflitos.  Mas quando estes aparecerem, você deve certificar-se de que você compreende a sua ferramenta de mesclagem, evitando assim a introdução de mais erros.

Fonte: http://homes.cs.washington.edu/~mernst/advice/version-control.html