Apresentação do Seminário

Segue link do Dropbox, de onde pode ser baixada/visualizada nossa apresentação do seminário.

Apresentação em PDF

Vantagens e Desvantagens do Controle de Versão Distribuído

Controle de versão distribuído (Distributed Version Control Systems – DVCS) é a mais nova geração de sistemas de controle de versão de software. Apesar de o conceito existir já há algum tempo, recentemente as ferramentas se tornaram maduras o suficiente para chamar a atenção de diversos projetos open source, que migraram ou expandiram seu suporte do Subversion (centralizado) para o Mercurial, Git e Bazaar (distribuídos) por exemplo.

Benefícios do Controle de Versão Distribuído

As vantagens estão relacionadas à distribuição do processamento, redundância/replicação de repositórios e as novas possibilidades de colaboração entre desenvolvedores.

Do ponto de vista do desenvolvedor

• Rapidez. As operações são processadas localmente. Não é necessário passar pela rede e contatar o servidor central para fazer um commit, log ou diff por exemplo.
• Autonomia. A conexão com a rede só é necessária para trocar revisões com outros repositórios. Fora isso, trabalha-se desconectado e em qualquer lugar, como num cliente por exemplo.
• Ramos privados. Além de um repositório próprio, o trabalho local é feito em um ramo privado que não interfere, nem sofre interferência dos demais, mesmo nas operações de sincronização entre repositórios. O momento de combinar um ramo com outro é uma decisão do desenvolvedor e não obrigatório antes de cada commit, como acontece no centralizado.
• Facilidade de Mesclagem. Só a facilidade de criação de ramos não seria suficiente se não fosse o rastreamento automático usado pelos DVCS, que torna o processo de mesclagem muito mais simples e indolor. Observação: No Subversion, o rastreamento automático de merges começou a partir da versão 1.5

Do ponto de vista da gerência/coordenação

Parte das decisões gerenciais envolve manter livre o caminho da equipe para que possam trabalhar da melhor maneira possível. Outras decisões importantes são sobre redução de custos. Nestes dois casos específicos, o modelo distribuído oferece as seguintes vantagens:

• Confiabilidade. No sistema centralizado, uma pane no servidor interrompe todo o desenvolvimento. Já no sistema distribuído, além de a equipe poder continuar seu trabalho (observação: veja a seção “controle de mudança ainda é centralizado” mais abaixo), os repositórios dos desenvolvedores funcionam como cópias de backup de todo o projeto.
• Redução de custos com servidor. A carga de processamento fica distribuída nas próprias máquinas dos desenvolvedores. O repositório “central”, quando existe, tem o papel do repositório “oficial” e não como processador central das requisições.

Em que situações o controle de versão distribuído não vai tão bem?

Nem tudo são flores com o modelo distribuído de controle de versão.

Maior complexidade

No centralizado, os desenvolvedores trabalham no mesmo ramo, seja esse ramo o principal ou um ramo de manutenção.

Essa forma de trabalho é mais simples de se entender. Mesmo que limitadamente, uma pessoa com pouco conhecimento de controle de versão consegue trabalhar com o resto da equipe.

O modelo distribuído é mais complicado. A arquitetura peer-to-peer, ramos privados e as mesclagens aparentemente desordenadas podem tornar o grafo da evolução do projeto confuso à primeira vista.

Ao contrário do centralizado, não adianta só commit e update para funcionar “no tranco”. Todos os desenvolvedores da equipe precisam ter um conhecimento maior do modelo, da ferramenta e, de preferência, também de um processo de desenvolvimento que padronize fluxos de trabalho a serem seguidos. Só assim, o grafo acima deixa de ser apenas um emaranhado e passa a representar muito claramente o fluxo do trabalho.

Resumo das Características do Controle de Versão Distribuído

Referências:

1. Conceitos Básicos de Controle de Versão Centralizado e Distribuído
2. Distributed Revision Control

Portal LibreSource

É um portal Web utilizado para gerenciar projetos colaborativos. É baseado em Java/J2EE e é mais um conjunto de ferramentas colaborativas visual para ajudar a facilitar projetos e equipes. Enquanto os outros sistemas discutidos até agora têm sido concebidas em mais uma “linha de comando” nível, LibreSource está mais centrado nas ferramentas que não possuem uma grande curva de aprendizado.

Tem elementos de construção, tais como páginas Wiki, fóruns, trackers, Synchronizers, Subversion repositórios, arquivos, faça o download de áreas, formulários, mensagens instantâneas e muito mais. Pense em colaboração LibreSource como um hub para a elaboração de projectos.

LibreSource é perfeito para o desenvolvedor ou designer que não querem aprender lotes de jargão técnico e quer se concentrar mais na comunicação com os membros do projeto. Basta instalar o pacote e começar a colaborar, sem grande virada de uma curva de aprendizado.

Recursos para LibreSource:

• LibreSource Documentação – Toneladas de artigos e tutoriais para ficar familiarizado com LibreSource.

Referências :

http://www.artenum.com/EN/Products-LibreSource.html

http://dev.libresource.org/home/doc/libresource-user-manual

Resumo das Principais diferenças entre GIT e SVN

Lista das principais:

• Git é muito mais rápido do que o Subversion.
• Subversion permite que você verifique para fora apenas uma sub-árvore de um repositório; Git requer que você clone todo o repositório (incluindo a história) e crie uma cópia de trabalho que espelha, pelo menos, um subconjunto dos itens sob controle de versão.
• Repositórios do Git são muito menores que Subversions (para o projeto Mozilla, 30x menor)
• Git foi projetado para ser totalmente distribuído desde o início, permitindo que cada desenvolvedor tenha comando local.
• Ramos git são mais simples e menos  pesado do que o Subversion.
• Ramos git transportam toda a sua história.
• Mesclando no Git não exige que você se lembre da revisão que você mesclou (esse benefício foi evitado com o lançamento do Subversion 1.5).
• Git fornece uma melhor auditoria de ramo e mesclar eventos.
• Formatos de arquivo repo do Git são simples, de modo a reparação é fácil e corrupção é raro.
• Fazer o backup de repositórios Subversion central é potencialmente mais simples - uma vez que você pode escolher para as pastas distribuídas dentro de um repo no git.
• Clones repositório git atuam como backups repositório completo.
• UI do Subversion é mais maduro do que o Git.
• Andando por versões mais simples no Subversion, porque ele usa números sequenciais de revisão (1,2,3, ..); Git usa imprevisíveis SHA-1 hashes. Caminhar para trás no Git é fácil usando o "^" sintaxe, mas não há nenhuma maneira fácil de andar para a frente.

Referência:

https://git-scm.com/doc

https://subversion.apache.org/docs/

Os 3 Controles de Versão Mais Utilizados no Mercado

Os mais utilizados no mercado de desenvolvimento
CVS:

 CVS é o “patriarca” dos sistemas de revisão de controle. Foi libertado em 1986. CVS é o padrão de facto e está instalada praticamente em toda parte. No entanto, o código base não é tão inteiramente caracterizado como SVN ou outras soluções.

A curva de aprendizado não é muito íngreme para o CVS, e este é um sistema muito simples para ter certeza que arquivos e revisões seram de fato atualizados. Embora CVS possa ser uma tecnologia “antiga”, ainda é muito útil para qualquer designer ou desenvolvedor fazer o backup de arquivos e de partilha.

Tortoise CVS é um grande cliente para CVS em Windows, e existem diversas IDEs, como o Xcode(Mac), Eclipse, NetBeans e Emacs, que utilizam o CVS.

Subversion:

É provavelmente o sistema de controlo de versões com a mais ampla aprovação. A maioria dos projetos open-source o tem como um repositório Subversion, porque outros projetos maiores, como o SourceForge, Apache, Python, Ruby e muitos outros, também utilizam. Código do Google usa Subversion exclusivamente para distribuir código.

Devido a popularidade do Subversion, muitos clientes estão disponíveis. Para os usuários do windows o Tortoise SVN é o candidato, tendo um navegador para visualizar, editar e modificar o seu código baseno Subversion. Se estiver em um Mac, Versões, é um elegante cliente, que prevê uma “agradável maneira de trabalhar com Subversion.” Xcode da Apple, é desenvolvedor ambiente e Subversion cliente, que vem com Leopard em um Mac.

Git

É a mais nova estrela no mercado do controle de versão. Inicialmente desenvolvido pelo criador do kernel do Linux Linus Torvalds, Git tomou recentemente o desenvolvimento da comunidade da Web. O “desenvolvimento globalizado” oferece um tipo muito diferente da versão que é um controle no Sistema de controle de versão distribuída.

Empresas e seus SCVs

Boa noite,

   é indiscutível a necessidade de se utilizar sistemas de controle de versões, mas quais empresas utilizam o Git, o SVN, o Bazaar e o Mercurial? Esse post será destinado apenas a listar algumas empresas que utilizam esses SCVs no desenvolvimento de seus softwares.

    Começaremos pelo SVN, por ser um sistema mais antigo e simples de se utilizar, ele ainda tem uma posição de destaque no cenário mundial quanto a sua utilização, entre as empresas que o utilizam estão:

• Debian
• Zope
• KDE
• Mono
• Conectiva Linux

Fonte: http://i30.fastpic.ru/big/2012/0213/34/babcfc937ab2ba9389b93cccec46cb34.jpg

    Já o Git vem ganhando notoriedade ao longo desses anos, por apresentar inúmeras vantagens, algumas empresas que o utilizam são:

• Adobe Systems
• Facebook
• BBC News
• Globo.com
• Google
• Twitter
• Banco Central do Brasil (Bacen)

Fonte: http://salarioconcursopublico.com.br/wp-content/uploads/2014/07/logo-bacen.jpg

    O Bazaar é utlizado por vários projetos, há uma tabela completa no site oficial com uma lista desses projetos, essa lista pode ser visualizada aqui. Dentre os projetos mais conhecidos estão:

• Linux Foundation
• MySQL
• Squid
• Unetbootin
• MariaDB
• Emacs
• APT 

Fonte: https://upload.wikimedia.org/wikipedia/commons/e/ee/LF_logo.png

    Por fim algumas empresas que utilizam o Mercurial, um SCV mais novo, com as vantagens do Git e com a facilidade do SVN:

•  Mozilla
• NetBeans
• OpenOffice
• Python
• OpenJDK
• OpenSolaris

Fonte: http://luissoares.com/wp-content/uploads/2014/03/netbeans-logo1.png

    No estado de Sergipe temos uma clara divisão entre o SVN e o Git, com algumas aparições do TFS (Team Fundation Source), a seguir algumas empresas e seus sistemas de versões utilizados:

• Secretaria do Estado da Educação (SEED) - Migrou do TFS para o SVN
• InfoW - Migrou do TFS para o Git
• SM Soluções - SVN
• Avatar B2B - Git
• Infox - SVN
• Serveloja - Git

Fonte: https://yt3.ggpht.com/-FKwxVI_zKFE/AAAAAAAAAAI/AAAAAAAAAAA/SRyW6_UL_jA/s100-c-k-no/photo.jpg

Fontes: http://www.neuroniodigital.com.br/empresas-no-github/
https://government.github.com/community/
https://www.mercurial-scm.org/wiki/ProjectsUsingMercurial
http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/subversion.php?pagNum=0

Integração dos Sistemas de Gerenciamento de Projetos com os SVCs

Boa noite,

    depois do primeiro dia de apresentações dos trabalhos da disciplina, onde vimos entre outros temas, sistemas de gerenciamento de projetos, pareceu interessante falar um pouco sobre as integrações entre os SCVs e tais sistemas. Isso faz com que todas atividades de desenvolvimento sejam comentadas a cada commit e os arquivos utilizados sejam explicitados.

    Iremos falar de dois sistemas bastante utilizados, o JIRA e o Redmine,  tendo sido esse segundo utilizado como estudo de caso na apresentação.

JIRA 

    É um software comercial desenvolvido pela empresa Australiana Atlassian. Sendo uma ferramenta que permite o monitoramento de tarefas e acompanhamento de projetos garantindo o gerenciamento de todas as suas atividades em único lugar. 

    Quando os sistemas de controle de versão são integrados ao JIRA o usuário precisa apenas informar o código da issue que automaticamente a mensagem do commit e a lista de arquivos alterados são vinculados.

     Além dos commits, os branches são associados automaticamente caso possuam um mesmo nome de issue, o mesmo vale para builds e deployments.

    O JIRA possui integração com o Bitbucket Server (gerenciado de repositórios git), bamboo, FishEye, Subversion (SVN) e o Perforce.

Fonte: https://confluence.atlassian.com/download/attachments/438993267/Stash27_commits_in_JIRA.png?version=1&modificationDate=1376987906540&api=v2&effects=border-simple,blur-border

Redmine

    Trata-se de software livre, gerenciador de projetos baseados na web e ferramenta de gerenciamento de bugs. Contém calendário e gráficos de Gantt para ajudar na representação visual dos projetos e seus deadlines (prazos de entrega).

    Permite também integração com alguns sistemas de controle de versão: Subversion (SVN) e Git. Para efetuar essa integração basta seguir os passos descritos aqui, concluída esta etapa basta apenas incluir refs#CodigoRedmine antes de cada commit para que ocorra a associação.

   Comparado ao JIRA a integração do Redmine é bastante limitada, uma vez que é direcionada apenas para commits, mas ainda assim é uma boa integração para o gerenciamento do projeto.

Fontes: https://confluence.atlassian.com/jira/integrating-jira-with-subversion-185729573.html
http://www.redmine.org/projects/redmine/wiki/ThirdPartyTools

Apanhado geral sobre Git

Boa tarde a todos, nesta postagem vou trazer um apanhado geral do do que já foi visto que está muito bem demonstrado nesses slides que encontrei pesquisando sobre o tema.

Espero que sirva como uma boa revisão.

Fonte: http://pt.slideshare.net/willianfernandes/git-em-ambiente-subversion

Surgimento do Git

Boa tarde a todos,

Já vimos bastante sobre o Git e as principais funções básicas que podem ser feitas com ele, mas como surgiu essa ferramenta que hoje é utilizada por tantas pessoas e empresas no mundo. 

Então vamos lá, espero que vocês gostem.

O Git começou com um tanto de destruição criativa e controvérsia acirrada. O kernel (núcleo) do Linux é um projeto de software de código aberto de escopo razoavelmente grande. Durante a maior parte do período de manutenção do kernel do Linux (1991-2002), as mudanças no software eram repassadas como patches e arquivos compactados. Em 2002, o projeto do kernel do Linux começou a usar um sistema DVCS proprietário chamado BitKeeper.

Em 2005, o relacionamento entre a comunidade que desenvolvia o kernel e a empresa que desenvolvia comercialmente o BitKeeper se desfez, e o status de isento-de-pagamento da ferramenta foi revogado. Isso levou a comunidade de desenvolvedores do Linux (em particular Linus Torvalds, o criador do Linux) a desenvolver sua própria ferramenta baseada nas lições que eles aprenderam ao usar o BitKeeper. Alguns dos objetivos do novo sistema eram:

• Velocidade;
• Design simples;
• Suporte robusto a desenvolvimento não linear (milhares de branches paralelos);
• Totalmente distribuído;
• Capaz de lidar eficientemente com grandes projetos como o kernel do Linux (velocidade e volume de dados).

Desde sua concepção em 2005, o Git evoluiu e amadureceu a ponto de ser um sistema fácil de usar e ainda assim mantém essas qualidades iniciais. É incrivelmente rápido, bastante eficiente com grandes projetos e possui um sistema impressionante de branching para desenvolvimento não-linear.

Fonte: https://git-scm.com/book/pt-br/v1/Primeiros-passos-Uma-Breve-Hist%C3%B3ria-do-Git

Comparando o SVN, Git e o Mercurial

 Boa tarde,

   nesse post traremos algumas comparações entre os sistemas de versionamentos SVN, Git e Mercurial, bem como seus prós e contras. Na tabela comparativa de logo mais também aparecerá o GNU Bazzar e o Team Fundation Server (TFS) isso porque o primeiro já foi citado em postagens anteriores e o segundo foi mencionado em uma apresentação da disciplina.

Pontos positivos e negativos do SVN, Git e Mercurial:

SVN
Prós:

•  Sistema mais recente baseado em CVS
• Inclui operações atômicas
• Operações de branch mais simples
• Ampla variedade de plugins para IDEs
• Não utiliza o modelo P2P

Contras:

• Ainda contém erros relativos a renomeação de arquivos e diretórios
• Comandos de gerenciamento de repositórios insuficientes
• Velocidade mais lenta se comparado aos outros dois (Git e Mercurial)

Git
Prós

• Aumento na velocidade de operações
• Operações de branch mais simples
• Árvore de histórico completa disponível offline
• Sistema distribuído e modelo P2P

Contras:

• Difícil aprendizado para quem migra do SVN
• Não ideal para desenvolvedores individuais 
• Suporte limitado para Windows quando comparado ao Linux

Mercurial
Prós:

• Mais fácil de aprender do que o GIT
• Melhor documentação
• Modelo distribuído

Contras:

• Sem merge entre dois parentes
• Base de extensões  em vez de scripts

Tabelas comparativas:

Modificado de https://en.wikipedia.org/wiki/Comparison_of_version_control_software

Modificado de https://en.wikipedia.org/wiki/Comparison_of_version_control_software

 **Todos os SCV mencionados estão em atividade.

 Fontes: http://biz30.timedoctor.com/git-mecurial-and-cvs-comparison-of-svn-software/
https://en.wikipedia.org/wiki/Comparison_of_version_control_software

Criando Tags e Utilizando Branchs

Bom dia,

   Hoje iremos ver um pouco sobre como os sistemas de versionamentos trabalham com marcações (Tags) de commits estáveis e ramificações de desenvolvimento.

   Essas funcionalidades fazem com que seja possível retornar a uma versão estável em uma eventual necessidade, por exemplo quando uma versão é lançada mas o desenvolvimento de novas funcionalidades continua, caso esse lançamento possua um erro é possível retomar o código específico utilizado, sem que se percam as novas funcionalidades já criadas, permite ainda que a correção seja feita apenas no ambiente específico e seja aplicada na linha de desenvolvimento, evitando assim a repetição de trabalho.

   Veremos como utilizar essas funcionalidades no SVN, Git e Mercurial.

TAG

   Criar Tags (marcações) em pontos específicos do histórico do código é uma funcionalidade importante e está disponível na maioria dos sistemas de controle de versão. Geralmente essas marcações são utilizadas no momento de lançamento de releases (v1.0, v2.0 e assim por diante).

Fonte: http://betterexplained.com/wp-content/uploads/version_control/tagging.png

• SVN: para criar um Tag basta executar o comando svn copy informando o diretório de origem, o diretório de destino e o nome da marcação.

Retirado de http://svnbook.red-bean.com/en/1.7/svn.branchmerge.tags.html

• Git: possui três tipos de tags: anotadas, assinadas e leves. Nesse post iremos apenas observar a criação de uma marcação anotada, assim chamada por possuir uma chave de verificação, com o nome da pessoa que criou, email e data. O comando utilizado para criação é tag -a 'Nome da Tag' -m 'Descrição da Tag'.

Retirado de https://git-scm.com/book/pt-br/v1/Git-Essencial-Tagging

• Mercurial: criações de tag no Mercurial é similar as criações do git, apesar de não possuir a mesma variedade de tipos. O seu comando é hg tag 'Nome da Tag' -m 'Descrição da Tag'.

Retirado de https://www.mercurial-scm.org/wiki/Tag

Branch

Branch (ramificações) é a criação de uma cópia do código a partir de um ponto específico, podendo ser um tag ou não, onde o usuário poderá trabalhar de maneira independente sem que o código original seja afetado por suas alterações.

Fonte: http://lh6.ggpht.com/_prPJEj560s4/SWSBrkjPk6I/AAAAAAAAAOk/bkwir4Nhicc/BranchingAndTagging4.gif

• SVN: o comando para criar branch é similar ao de criação de uma tag, mas a tag é apenas uma marcação e o branch é uma cópia do arquivo. O comando utilizado é o svn copy.   

Retirado de http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html

• Git: criações de branchs no Git é muito mais simples, necessitando de dois comandos, um para criar o branch e outro para mudar o ambiente de trabalho, os comandos utilizados são git branch 'Nome do Branch' e git checkout 'Nome do Branch' agora todo commit realizado será feito no branch e não mais na linha de origem do branch.

Retirado de https://git-scm.com/book/pt-br/v1/Ramificação-Branching-no-Git-Básico-de-Branch-e-Merge

• Mercurial: necessita apenas de um comando para criar um branch, seu funcionamento é similar ao Git. O comando é hg branch 'Nome do Branch' não precisando explicitar a alteração de ambiente.

Retirado de https://www.mercurial-scm.org/wiki/Branch

Fontes: https://www.mercurial-scm.org/wiki/Tag
https://git-scm.com/book/pt-br/v1/Git-Essencial-Tagging
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.tags.html
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html
https://git-scm.com/book/pt-br/v1/Ramificação-Branching-no-Git-Básico-de-Branch-e-Merge
https://www.mercurial-scm.org/wiki/Branch

Comandos Básicos do Mercurial

Bom dia,

   Nessa postagem iremos conhecer alguns comandos básicos do Mercurial (clone, init, add, commit, log, push e pull). Esses comandos são utilizados rotineiramente por quem faz uso de algum sistema de versionamento distribuído. Para dar início é necessário ter o Mercurial instalado em seu computador (veja a postagem Instalando o Mercurial).

Clone

   O primeiro comando que iremos conhecer é o Clone, que serve para fazer uma cópia de um projeto de um servidor qualquer para sua máquina. A partir dessa cópia poderemos alterar o código, gerar versões, efetuar commits entre outras atividades.

   Para utilizá-lo, basta escrever clone "URL repositório".

Init

   Caso você esteja criando um novo projeto e queria versioná-lo, precisa utilizar o comando init, que faz com que o mercurial reconheça aquela pasta como uma pasta de versionamento.

   Acesse a pasta, no diretório raiz que seja versionar e utilize o comando init.

Add

   Agora que você possui um repositório local, independente de ter sido através do Init ou do Clone, você poderá adicionar novos arquivos a esse repositório, para que ele possa versionar suas alterações. O comando que adiciona esse arquivo é o Add. Esse comando só pode ser utilizado para arquivos "desconhecidos" do repositório.

Commit

   Com o arquivo adicionado, alterado ou removido devemos registrar essa alteração, ou como se fala no Brasil, Commitar essa alteração, para que o sistema consiga identificar e gravar essa alteração. Para isso utilizamos o comando Commit, que pode ou não vir acompanhando de uma mensagem, aconselhamos sempre incluir uma mensagem informando o que foi feito no commit, para facilitar em eventuais consultar.

Log

   Para verificar as alterações feitas em sua cópia local, bem como saber datas, arquivos e autores das alterações, você poderá utilizar o comando Log, que traz uma lista completa de alterações, bem como o número de versionamento de cada registro, permitindo que você possa retornar a versão, caso queira.

   Por padrão será exibido o hash gerado, o autor, a data e mensagem escrita do commit.

Push

   Para enviar essas alterações para um servidor, basta utilizar o comando push, onde todos os commits feitos localmente serão replicado no servidor, mas isso só será possível caso sua cópia de trabalho esteja atualizada.

Pull

   Para efetuar essa atualização é necessário executar o comando pull que irá trazer todas alterações feitas no diretório para sua cópia local.

Fontes: https://www.mercurial-scm.org/wiki/QuickStart
 http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html

Bazaar em 5 minutos

Este post é uma adaptação e resumo de postagem na wiki oficial, disponível em: http://doc.bazaar.canonical.com/latest/en/mini-tutorial/.

Como já foi dito num post anterior, o Bazaar é um sistema de controle de versão distribuído. Nele, cada usuário é identificado através da tupla (nome, endereço de email), vale lembrar que o endereço de email não precisa ser real, basta apenas que se pareça com um, de modo a manter um padrão.

As imagens abaixo ilustram, respectivamente e por linha de comando, o momento que um usuário (John Doe) se identifica e depois pergunta quem ele mesmo é, obtendo o retorno do sistema.

Abaixo estão listados os comandos que criam um repositório chamado sample (amostra) e, em seguida, iniciam o mesmo e navegam para a pasta trunk.

Os próximos comandos adicionam o arquivo "test1.txt" e comitam com uma mensagem entre aspas.

"primeira linha de texto adicionada"

O histórico de mudanças pode ser observado com o comando:

O Bazaar também oferece a função merge, que permite que todo usuário envolvido numa equipe mantenha-se atualizado quanto às mudanças realizadas por outros componentes da equipe.

Há ainda um comando que mostra as diferenças da última revisão de um usuário para com o branch principal.

Isso é tudo por este post, mais comandos e explicações podem ser obtidas diretamente do console do Baazar, através do comando:

Há também um guia de usuário online, disponível em: http://doc.bazaar.canonical.com/latest/en/user-guide/index.html.

Bons estudos!

Referências

http://bazaar.canonical.com/en/

Bazaar - Instalação

Esta postagem traz instruções de como obter e instalar o Bazaar no Mac OS X, Linux e também Windows, há também imagens da tela inicial em cada sistema.

1 - Mac OS X:

Fonte: http://doc.bazaar.canonical.com/explorer/en/_images/welcome-setup4.png

O download pode ser feito em: http://wiki.bazaar.canonical.com/MacOSXDownloads .

Há, além de pacotes de instalação para algumas versões mais antigas do OS X, tutoriais de como obter e instalar via MacPorts ou Homebrew, canais alternativos de software livre para usuários de OS X, para mais informações acerca destas ferramentas, acessar:

• MacPorts: https://www.macports.org/
• Homebrew: http://brew.sh/

2 - Linux:

Fonte: http://i.stack.imgur.com/ojMZG.png

No Linux, em suas diversas distribuições, o Bazaar pode ser instalado através do gerenciador de pacotes específico de cada distribuição, o pacote a ser instalado é o "bzr", no Debian e derivados, como é o caso do Ubuntu, o comando para a instalação é:

Sudo apt-get install bzr

Basta apenas então aguardar que o gerenciador de pacotes termine o download e instalação para se fazer uso do sistema.

3 - Windows

Fonte: http://doc.bazaar.canonical.com/explorer/en/_images/welcome-setup5.png

Para instalar no Windows, basta fazer o download do executável instalador e seguir as instruções em tela, como de costume no sistema operacional em questão.

Referências:

http://bazaar.canonical.com/en/

Bazaar, o sistema de controle de versões da Canonical

 A Canonical é mundialmente conhecida por ser a empresa que está por trás do famoso Ubuntu Linux, a partir de pesquisas para a manutenção deste blog, chegamos ao conhecimento do Bazaar, um sistema de controle de versões que é parte do Projeto GNU, e é patrocinado pela Canonical.

Fonte: http://www.cheatography.com/uploads/hoplayann_1402999184_Untitled.png

Este blog focará no sistema de controle de versões Bazaar, para mais informações acerca da Canonical e do Projeto GNU, favor acessar seus respectivos sites:

1. Canonical: http://www.canonical.com/
2. Projeto GNU: http://www.gnu.org/

Logo do Projeto GNU

Logos do Ubuntu e Canonical

 O Baazar está disponível para um vasto número de sistemas, como pode ser notado a partir da imagem abaixo, print recortado do site oficial do sistema.

 Há versões para Windows, Mac OS X, várias distribuições Linux, entre outros sistemas. Vale lembrar que o Baazar é um sistema de controle de versão do tipo distribuído, Nos próximos posts traremos instruções de como começar a utilizar o Baazar, bem como algumas de suas caractrísticas, para que o leitor possa testar o sistema e checar suas vantagens ou desvantagens para com outros sistemas bastante conhecidos, como o Git.

referência:

http://bazaar.canonical.com/en/

SCV: Boas Práticas #Parte 3#

Essa é a terceira e última parte das nossas dicas no uso dos SVCs, esperamos que façam bom proveito delas.

Boa práticas para sistemas de controle de versão distribuídos

Nunca force um comando

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

"Não use git push -- force, as pessoas odiarão você"

Tanto o Git quanto o Mercurial por vezes se recusam a realizar um comando, como um push para um repositório remoto quando ainda não foi feito um pull prévio com todas as mudanças. O Mercurial por exemplo indica esse tipo de problema através da seguinte mensagem ao usuário:

abort: push creates new remote heads!
(did you forget to merge? use push -f to force)

O Mercurial sugere que seja feito um merge com todas as mudanças — a melhor maneira de fazer isso é através do comando: 

hg fetch (em vez de hg merge)

Em seguida pode-se tentar novamente o comando que gerou o erro, push. Logicamente, como pode-se ver na mensagem de erro gerada a partir do comando de push, é possível forçar com:

push -f ou--force

Entretanto tal artifício não deve nunca ser usado, apesar de realizar o comando desejado, muito provavelmente esconderá problemas que deverão ser tratados no futuro, gerando retrabalho e perda de tempo para o(s) desenvolvedor(es).

Como já foi mostrado em outro posts de dicas, não se pode usar 'update' antes de 'commit' e 'merge'. O resultado será uma mensagem de erro como a descrita abaixo:

abort: outstanding uncommitted changes

Todavia, caso seja realmente necessário ou da vontade do desenvolvedor incorporar as mudanças providas por outros componentes do grupo, mesmo que ainda não finalizadas ou prontas para serem comitadas, o uso de um update sem seguir essas dicas irá gerar retrabalho por parte do programador.

Caching de uma senha

Fonte: http://www.leapbeyond.com/ric/tsvnpd/reveal.png

O SVN (Subversion) faz um cache de sua senha automaticamente, de modo que somente é preciso informar a sua senha uma primeira vez. Abaixo estão duas maneiras de fazer um caching de senha no Mercurial, no intuito de não precisar digitar a senha pessoal a cada uso do sistema:

1.   hg clone https://usuario:senha@jsr308-langtools.googlecode.com/hg/ jsr308-langtools
   

2. No arquivo .hgrc global, adicione esta seção:

   # The below only works in Mercurial 1.3 and later
   [auth]
   
   googlecode.prefix = code.google.com
   googlecode.username = nome_usuario
   googlecode.password = senha
   googlecode.schemes = https
   
   dada.prefix = dada.cs.washington.edu/hgweb/
   dada.username = nome_usuario
   dada.password = 
   dada.schemes = https
   

 Notificação por Email

Esta dica é particularmente para o Mercurial. Uma funcionalidade muito legal dos sistemas de controle de versão é a notificação por e-mail, de modo que todos os que fazem parte de um projeto sejam avisados a cada commit ou push revelando as mudanças no servidor.

Para se ter tal funcionalidade no Mercurial, basta seguir as dicas postadas em : http://mercurial.selenic.com/wiki/NotifyExtension.

Isso é tudo por enquanto, esperamos ter ajudado com as dicas!
Nos vemos na próxima postagem.

Referências:

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

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