Instalando o Mercurial

    Boa noite, agora que conhecemos as vantagens de se utilizar o sistema de versionamento Mercurial, leia a postagem "Conhecendo o Mercurial", iremos aprender como instala-lo. Esse processo será visto nos três sistemas operacionais mais utilizados no mundo, o Microsoft Windows, GNU/Linux e o MacOS.

Fonte: http://i.ytimg.com/vi/67o4cqiyDnE/hqdefault.jpg

Windows:

    Para instalar o Mercurial no Windows é necessário apenas instalar o TortoiseHg, que é uma ferramenta gráfica, que ela se encarregará de instalar os pacotes do Mercurial, bem como outras ferramentas gráficas úteis para o dia a dia.

Show Log do TortoiseHg no Windows. Fonte: http://tortoisehg.bitbucket.org/manual/0.9/_images/log.png

Linux:

    No linux é aconselhavel fazer sua instalação utilizando o gerenciador de pacotes do próprio sistema operacional. Caso não encontre, é possível instalar a partir do código-fonte mais atual (baixe aqui).

    Caso queira utilizar o modo gráfico você poderá utilizar o TortoiseHg, mas será necessário instalar a biblioteca PyQt.

Show Log do ToroiseHg no Linux. Fonte: http://blog.g0blin.co.uk/wp-content/uploads/2011/03/thg2.0-ubuntu-10.10.png

MacOS:

    A solução mais indicada para o MacOS é o MacHg. Ele vem empacotado com o próprio Mercurial, de modo que torna desnecessário se preocupacar com isso.

    O TortoiseHg também pode ser instalado no MacOS, para utiliza-lo bastar seguir os passos aqui.

Show Log do TortoiseHg no MacOS. Fonte: http://blog.fogcreek.com/wp-content/uploads/2011/12/tortoisemac.png

Fonte: http://mercurial.aragost.com/kick-start/pt_BR/basic/

Conhecendo o CVS (Concurrent Versions System)

 Boa tarde, hoje iremos conhecer um pouco sobre a ferramenta de controle de versão CVS (Concurrent Versions System) .

Uma das suas funções é guardar históricos de mudanças. Uma grande característica do CVS é que ele não faz look de arquivos. Ele permite que mais de um desenvolvedor trabalhe no mesmo arquivo.

Colaboração simultânea é possível através do modelo  COPIAR-ALTERAR-JUNTAR. 

• COPIAR : Os desenvolvedores pedem uma cópia local para o servidor.
• ALTERAR : O desenvolvedor A altera sua cópia local e envia para o servidor.
• JUNTAR (merge) : O desenvolvedor B envia sua alteração para o servidor e é informado sobre o conflito. 

O CVS utiliza uma arquitetura cliente-servidor: um servidor armazena a(s) versão(ões) atuais do projeto e seu histórico, e os clientes se conectam a esse servidor para obter uma cópia completa do projeto, trabalhar nessa cópia e então devolver suas modificações. Tipicamente, cliente e servidor devem estar conectados por uma rede local de computadores, ou pela Internet, mas o cliente e o servidor podem estar na mesma máquina se a configuração do CVS for feita de maneira a dar acesso a versões e histórico do projeto apenas a usuários locais. O servidor geralmente roda sistema ao estilo Unix, enquanto o cliente CVS pode rodar qualquer sistema operacional.

Terminologias do CVS:

• Checkout: normalmente é usado para denominar o primeiro download de um módulo inteiro a partir do repositório CVS.
• Commit: envio das modificações feitas pelo usuário ao repositório CVS.
• Export: é o download de um módulo inteiro a partir de um repositório CVS, sem os arquivos administrativos CVS. Módulos exportados não ficam sob controle do CVS.
• Import: geralmente é usado para designar a criação de um módulo inteiro dentro de um repositório CVS através do upload de uma estrutura de diretórios.
• Module: é uma hierarquia de diretórios. Geralmente um projeto de software existe como um simples módulo dentro do repositório.
• Release: é a versão de um produto inteiro.
• Revision: é a numeração atribuída pelo CVS a cada modificação de um arquivo.
• Tag: é um nome simbólico dado para um conjunto de arquivos em um instante específico durante o desenvolvimento.
• Branch: é uma ramificação no desenvolvimento, usada para descrever o processo de divisão dos arquivos de um projeto em linhas de desenvolvimento independentes. Podendo servir para teste de uma nova funcionalidade ou para projetos destinados a um cliente específico.
• Update: atualização da cópia local do trabalho através do download das modificações feitas por outros usuários no repositório.
• Merge: é a fusão de modificações feitas por diferentes usuários na cópia local de um mesmo arquivo. Sempre que alguém altera o código, é necessário realizar um update antes do commit, de modo que seja feito o merge — ou a fusão — das mudanças.

Limitações do CVS:

• Os arquivos em um repositório CVS não podem ser renomeados a partir do cliente, eles devem ser explicitamente removidos e readicionados. Entretanto, com acesso ao servidor os arquivos podem ser renomeados. No servidor, cada arquivo na estrutura de diretório do cliente possui um equivalente seguido de ,v. Exemplo: o arquivo index.html no cliente é gravado no servidor como index.html,v. A ação de renomear no servidor gera no cliente um processo de exclusão do arquivo antigo e criação de um novo e o histórico de atualizações é mantido.
• O protocolo do CVS não permite que os diretórios sejam movidos ou renomeados. Cada arquivo do subdiretório em questão deve ser individualmente removido e readicionado.
• Não permite "checkout" reservados (permite que dois usuários alterem o mesmo arquivo ao mesmo tempo) e em alguns casos pode ser mais custoso resolver o conflito do que evitar que ele ocorra.

Alguns dos principais desenvolvedores que trabalharam no CVS são atualmente responsáveis pelo Subversion (SVN), lançado no começo de 2004 e cujo objetivo é substituir o CVS ao lidar com algumas de suas limitações.

Sistemas de Controle de Versionamento: Centralizados x Distribuídos

Já sabemos que o controle de versionamento permite, entre outras características, que várias pessoas trabalhem simultaneamente num mesmo projeto, onde cada pessoa trabalha localmente e decide quando disponibilizar as alterações efetuadas para os demais colaboradores no projeto.

Existem entretanto diferentes modelos de sistema de versionamento, neste post traremos então as principais caraterísticas e diferenças entre os dois modelos existentes: Centralizado e Distribuído. A tabela abaixo apresenta um mini comparativo com alguns desses sistemas:

SCV	CENTRALIZADOS	DISTRIBUÍDOS
ABERTOS	Subversion, CVS, OpenCVS.	GIT, Bazaar, Mercurial.
PROPRIETÁRIOS	ClearCase (IBM), SourceSafe (Microsoft), Serena.	BitKeeper, TeamWare.

Sistemas de controle de versão distribuídos são: mais modernos, rodam mais rápido, menos propensos a erros, têm mais funções e são um pouco mais complexos também, entretanto, as vezes essa complexidade extra faz com que muitos usuários optem por versões centralizadas.

A principal diferença entre os sistemas está no número de repositórios, enquanto que na centralizada há apenas um repositório central e, na distribuída há vários repositórios, como ilustrado nas figuras abaixo. No centralizado cada usuário tem sua própria working copy, após cada commit realizado por um usuário, outros terão acesso às mudanças através do comando update. No distribuído cada usuário além de uma working copy tem também seu próprio repositório.

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

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

Podem haver conflitos em ambos os sistemas, ocorrem quando há edições simultâneas num mesmo arquivo por usuários diferentes. Nos sistemas distribuídos há uma operação explícita chamada merge , que pode tentar mesclar as mudanças simultâneas automaticamente ou requisitar intervenção manual através do uso da merge tool. Nos sistemas centralizados é mais difícil resolver conflitos devido a falta dessa operação, o merge ocorre implicitamente toda vez que um update é requisitado.

Mais informações acerca de como evitar e gerenciar conflitos serão tratados numa próxima postagem, em breve, fiquem ligados!

O vídeo abaixo é uma defesa ao uso dos sistemas distribuídos, como Git e Mercurial, em detrimento dos centralizados, como o Subversion:

Referências:

Version control concepts and best practices. Disponível em:

https://homes.cs.washington.edu/~mernst/advice/version-control.html. Acesso em <17/02/2016>.

Link para o vídeo aqui publicado: https://www.youtube.com/watch?v=_yQlKEq-Ueg. Acesso em <20/02/2016>.

Conhecendo o Mercurial

     Boa tarde, hoje iremos conhecer um pouco sobre a ferramenta de controle de versão Mercurial.

   O Mercurial é uma ferramenta gratuita, possuindo uma arquitetura de controle de versão distribuída, similar ao GIT, podendo ser utilizada em projetos de tamanhos variados. Foi desenvolvido em Phyton, com exceção do Diff (componente responsável pela comparação de duas versões do mesmo documento) que foi implementado na linguagem C. Possui um shell próprio que permite trabalhar com linhas de comandos e uma interface gráfica intuitiva.

   Feito inicialmente apenas para o sistema operacional Linux a ferramenta terminou ganhando versões compatíveis com outros sistemas operacionais, como o Microsoft Windows e o MacOS.

Fonte: https://upload.wikimedia.org/wikipedia/commons/thumb/9/9a/New_Mercurial_logo.svg/2000px-New_Mercurial_logo.svg.png

Principais vantagens da ferramenta

Arquitetura distribuída

   Sistemas de Controle de Versão tradicional como o Subversion são tipicamente cliente-servidor, com um servidor central para armazenar as revisões do projeto. Em contraste, Mercurial é verdadeiramente distribuído, dando a cada desenvolvedor uma cópia local e a história de desenvolvimento inteira. Isso permite o trabalho independente de acesso a rede ou ao servidor central. Commit, branch e merge são rápidos e baratos.

Rápido

   Implementações e estrutura de dados Mercurial são projetados para serem rápidos. Você pode gerar diffs (diferenciações) entre versões, ou retornar versões em segundos. Portanto Mercurial é perfeitamente adequado para projetos grandes como o OpenJDK ou NetBeans.

Plataforma Independente

   Mercurial foi escrito com independência de plataforma. Tendo sido escrito em Python, com uma pequena parte em C por razões de performance. Como resultado, versões binárias estão disponíveis nas principais plataformas.

Extensível

   A funcionalidade do Mercurial pode ser aumentado com extensões, seja ativando os oficiais que são fornecidos pela Mercurial ou baixando alguns do wiki ou escrevendo o seu próprio. Extensões são escritos em Python e pode alterar o funcionamento dos comandos básicos, adicionar novos comandos e acessar todas as funções essenciais da Mercurial.

Facilidade de uso

   Mercurial Sports é um conjunto de comandos consistente em que a maioria dos usuários de Subversion podem se sentir em casa. Ações potencialmente perigosas estão disponíveis através de extensões que você precisa habilitar, tendo uma interface básica fácil de usar, fácil de aprender e difícil de quebrar. Você pode obter o Quick Start em poucos minutos.

Código aberto

   Mercurial tem licença de software livre sob os termos do GNU General Public License Versão 2 ou qualquer outra versão.

Fonte: https://www.mercurial-scm.org/about

Um pouco mais sobre Sistemas de Controle de Versão

Os sistemas de controle de versão, mais comumente chamados SCM, funcionam como aplicativos computacionais responsáveis pelo controle e gerenciamento de diferentes versões na implementação de um determinado documento. Na sua grande maioria esses sistemas são implantados com a finalidade de controlar e gerenciar o desenvolvimento de projetos de software, proporcionando a manutenção das suas versões, de um histórico e desenvolvimento dos códigos fontes e consequentemente da documentação de todo o projeto.

Esse tipo de ferramenta se mostra bastante presente em organizações e empresas de âmbito tecnológico e de desenvolvimento de projetos de software, sendo também bastante utilizado para o desenvolvimento de ferramentas open source (código aberto). Sua utilidade pode ser denotada por diversos aspectos, seja ele para pequenos projetos, como também para projetos de maior escala comercial.

Existem vários sistemas que oferecem estas funcionalidades como:

• CVS, ou Concurrent Version System (Sistema de Versões Concorrentes) e o SVN, mais conhecido como Subversion, esses dois últimos no ambiente livre

• Também existem sistemas de controle de versão pagos. Dentre eles, temos sistemas comerciais como: Clearcase da IBM ou o SourceSafe da Microsoft. 

A grande maioria dos projetos de desenvolvimento de softwares livre optam pelo Subversion, que é a evolução do inveterado CVS, no entanto podemos citar uma exceção a essa "regra", que é a ferramenta chamada Bitkeeper, que apesar de ser comercial, foi por muito tempo utilizado para o gerenciamento e controle de versões do Kernel Linux, até o surgimento do GIT. Muitas organizações comerciais também utilizam o SVN, apesar de algumas dessas empresas preferirem realmente uma solução paga, daí partem em optar pelos produtos mencionados acima. A escolha por empregar uma solução comercial comumente se dá por questões de garantias, visto que as soluções livres não se responsabilizam por bugs, erros ou perdas de informações no software, em contra partida podemos elevar as melhores condições de empregabilidade, segurança e desempenho das ferramentas livres.

Já está comprovado que a utilização de Sistemas de Controle de Versão traz uma maior segurança para os projetos, um maior controle e uma maior facilidade na necessidade de reverter um código que não está funcionando por exemplo a um estado anterior, o qual era funcional.

Os principais proveitos em se empregar um sistema de controle de versão para monitorar as alterações realizadas durante as implementações de um determinado software são: controle e gerenciamento de históricos de alterações; identificação e restauração de versões estabilizadas; ramificações que ajudam na divisão do projeto, facilitando assim o trabalho de desenvolvimento em paralelo e principalmente o sincronismo oferecido para a equipe de trabalho.

Fonte: https://www.vivaolinux.com.br/artigo/GIT-Controle-de-versoes-distribuido-para-projetos-de-software

Benefícios e principais características do GIT

Boa tarde,
Nessa postagem, trarei alguns benefícios da utilização do Git e também algumas de suas características.
O nome “git”, gíria para “estúpido”, em inglês, aparentemente é uma brincadeira do seu autor, Linus Torvalds, que é também desenvolvedor do kernel do sistema operacional Linux. As vantagens do Git sobre os demais sistemas de controle de versão têm em comum a preocupação com a segurança. 

Entre elas, estão a possibilidade de desenvolvimento distribuído ou local – você mesmo pode usar para gerenciar alterações que tenha executado, por exemplo, para um TCC, ainda que não esteja trabalhando em grupo – um auto-merge eficiente (ou inteligente), que permite a mescla de alterações sem que o usuário tenha que se preocupar com isso e revisões incrementais, aonde todo commit gera uma tag automática, uma espécie de “retrato” do projeto naquele exato instante em que foi comitado.

Outra característica interessante do Git é a chave pública para autenticação, que dispensa o uso de usuário e senha a todo o momento em que uma nova versão do documento for gerada no servidor. 

Fonte: http://www.gonow.com.br/blog/2011/11/12/tutorial-do-git-ferramenta-gratuita-para-controle-de-versao-de-documentos/

Terminologias no Controle de Versionamento

Boa noite,

       Esta postagem tem o intuito de trazer definições acerca do controle de versionamento, de modo a sanar possíveis dúvidas do leitor quanto ao tema, como também garantir total compreensão do mesmo quanto a demais postagens desse blog que possam vir a utilizar determinadas terminologias. Os termos serão apresentados em inglês, pois é nessa língua que os desenvolvedores costumam lidar com elas, e referem-se ao controle de versionamento centralizado, como é o caso do Apache Subversion (em breve faremos uma postagem a respeito das diferenças entre controle centralizado e distribuído). 

       Antes das definições, segue tirinha que faz uma brincadeira com aqueles que não conhecem ou não gostam de usar ferramentas de controle de versão, nela, um programador utiliza pendrives para seu controle de versionamento pessoal:

Fonte: http://www.snipe.net/wp-content/uploads/2009/03/138_Version_Control-1306631688.png

• Repositório (Repository): Local onde todo o trabalho, e também seu histórico, dos desenvolvedores é armazenado. Um repositório atua como servidor, enquanto uma ferramenta de controle de versionamento atua como cliente. Clientes conectam-se a repositórios para armazenar, disponibilizar mudanças para outros clientes, ou recuperar mudanças e atualizações fornecidas por outros clientes.
• Trunk: Diretório onde toda a atividade principal dos desenvolvedores geralmente acontece.
• Tags: Permitem dar nomes a fases específicas de um projeto, a versões dele, por exemplo: "VERSÃO_INSTALADA_ATUALMENTE_NO_CLIENTE".
• Branches: Um Branch, ou ramo em português, pode ser usado para se criar uma outra linha de desenvolvimento, muito útil para se separar o desenvolvimento de versões futuras do processo de correção de bugs de versões atuais. Afigura abaixo ilustra o processo de ramificação (branching).

Fonte: http://i.stack.imgur.com/oBsKl.gif

• Working Copy: Funciona como um snapshot do repositório. O repositório é compartilhado por todos do projeto, mas não é modificado diretamente por ninguém, os envolvidos no projeto trabalham diretamente e isoladamente em suas "cópias de trabalho", que são obtidas de um repositório através de "checkout", uma próxima postagem trará mais informações acerca do seu uso.
• Commit: Brasileiro costumam usar esse termo como "comitar", uma palavra aportuguesada que significa, em programação, enviar as mudanças realizadas em uma working copy para os demais participantes de um projeto de desenvolvimento. É preciso usar o commit com cautela, de modo a não causar problemas inesperados, como a garotinha do meme abaixo.

Fonte: http://cdn.meme.am/instances/500x/64226295.jpg

Referências:

What is a Version Control System? Disponível em <http://www.tutorialspoint.com/svn/svn_basic_concepts.htm>. Acesso em 07/02/1016.

Sistema de Controle de Versão Subversion (SVN)

       Controle de versão é a arte de gerenciar mudanças em informações, para programadores, é um paradigma obrigatório a ser seguido para assegurar a saúde do código-fonte, ainda mais em grandes equipes atuando cada qual em partes distintas de um projeto. 

       O Subversion, ou simplesmente SVN, é uma ferramenta de controle de versão muito poderosa que permite, além do desenvolvimento colaborativo a partir de um repositório único, merge de conteúdo, armazenamento de logs e geração de estatísticas diversas.

Você, desenvolvedor, precisa de uma máquina
 do tempo para o seu código .

Atuando como a máquina do tempo do desenvolvedor, ferramentas como o SVN permitem retornar o código a um estado anterior, facilitando a análise da implementação realizada e a mesclagem de implementações distintas de períodos diferentes, para a criação de uma única versão.