Como começar uma StartUp

Boa noite,

   essa será minha última publicação no blog da disciplina, por esse motivo me darei a liberdade de fugir do assunto principal, os sistemas de controle de versões, e irei abordar um infográfico da RecepeTI, que explica os passos para se criar uma StartUp de sucesso.

   O sonho de todo estudante de informática na atualidade é concluir seu curso, ou antes disso, e abrir uma empresa de sucesso, que lhe renderá milhões com um aplicativo inovador de smartphone, mas como fazer isso?

   A RecepeTI (Rede Catarinense de Inovação) lançou, em março de 2015, um infográfico listando o caminho "simples" é necessário ser trilhado para conseguir o sucesso da sua startup.

Fonte: http://recepeti.org.br/wp-content/uploads/2015/03/info_startup.png

   O trabalho tem início com algumas orientações de perfil do estudante, viva no futuro e observe o que falta no mundo, com isso escreva e ressalte suas idéias. Para as idéias que valem a pena faça um protótipo. Mostre-o para cem pessoas e teste para que ele faça algum sentido.

   Feito esses passos chegou a hora de ganhar dinheiro com isso, em primeiro lugar encontre um parceiro e constitua uma empresa formal, agora é só procurar um financiamento para que você possa impulsionar sua empresa.

   Com a empresa possuindo clientes monitore sua fidelização, se não estiverem satisfeitos lance novos produtos, caso já estejam satisfeitos alcance mil usuários.

   Tendo clientes e ganhando dinheiro, chegou a hora de continuar crescendo, mostre ser possível crescer cinco porcento semanais e permaneça assim pelo próximo quatro anos até chegar ao SUCESSO!!!

   Com essas dicas chegou a hora de colocarmos em prática nossos sonhos e lançarmos o próximo "WhatsApp" ou o "Waze".

Fonte: http://recepeti.org.br

GitHub - Como utilizar

Boa noite,

   nessa postagem iremos ver um vídeo do HxTutors que está disponível no YouTube, explicando um pouco para que serve o GitHub e como usar. O vídeo não é longo e explica passo a passo de como utilizar, espero que possa ajudar a quem esteja iniciando.

Fonte: https://www.youtube.com/watch?v=neDiLHwXSVo

Bitbucket

Boa noite,

   nessa postagem iremos falar do Bitbucket, um repositório gratuitamente para projetos em GIT ou Mercurial.

   Esses repositórios são interessantes para os usuários que possuem algum projeto pessoal que queria ter acesso de outros lugares ou trabalhar colaborativamente sem ter um custo adicional. Além de permitir que o usuário possa aprender a utilizar novas ferramentas de gerência de projetos e versionamento.

Fonte: https://s3.amazonaws.com/helpjuice_production/uploads/upload/image/2341/29865/bitbucket.png

   O Bitbucket é um repositório de controles de versões, mantido pela empresa Atlassian, apresentando algumas vantagens como, integração com o JIRA, cliente desktop, visões entre outras coisas, o que deixa seu código mais rápido e inteligente.

   Possui duas modalidades de preço, o Small Teams, que é gratuito para até cinco usuários no projeto, e o Growing Teams, que permite dez, vinte e cinco, cinquenta e cem usuários, cada um tendo um custo mensal de um dólar, a outra modalidade do Growing Temans oferece a opção de usuários ilimitados a um custo mensal de duzentos dólares.

Fonte: https://bitbucket.org

Plano de Projeto de Software

Plano de Projeto para o Sistema de Controle de Frequência:

Plano de Projeto de Software from Matheus Mendonça

Qual a melhor ferramenta de controle de versão: Subversion, Git ou Mercurial?

Bom dia a todos,

Como já muito apresentado por nós aqui no blog, existem dois tipos de controle de versão: centralizado e o distribuído. O modelo distribuído é mais recente e possui algumas vantagens interessantes sobre o centralizado, embora seja um pouco mais complexo. Para as equipes que decidiram migrar para o distribuído ou mesmo permanecer com o centralizado, ainda resta a questão de qual a melhor ferramenta escolher.

Para aqueles que vão ficar no controle de versão centralizado, a decisão é bem simples: Subversion. Já é um padrão estabelecido, desbancando outros tais como CVS, Visual Source Safe, ClearCase etc. Não há realmente muito a acrescentar neste ponto.

O verdadeiro desafio está na escolha da ferramenta de controle de versão distribuído.

Filtragem Inicial

Existem muitas ferramentas de controle de versão distribuído. Para diminuir esse número inicial, vamos usar alguns critérios de filtragem inicial:

1. Licença open source. Não há a menor necessidade de usar uma ferramenta proprietária para controle de versão. Aliás, as melhores são open source.
2. Rodar em plataformas diferentes (Windows, Linux, etc.). A mesma ferramenta deve permitir que a equipe use a plataforma que quiser/precisar para trabalhar. Melhor ainda se houver uma interface gráfica tipo TortoiseSVN ou plugin para a IDE, mesmo que a linha de comando seja muito mais rápida e produtiva para a maioria das operações do controle de versão.
3. Massa crítica de projetos já usando. Se vários projetos grandes usam a ferramenta é sinal de que ela já foi testada, avaliada e aceita por outros antes. Além disso, é mais provável que haverá uma comunidade ativa mantendo e desenvolvendo a ferramenta por muitos anos.

Depois de aplicados os critérios na lista, acabam restando praticamente o Git e o Mercurial. Talvez o Bazaar também pudesse ser incluído mas outros como Darcs, Monotone e SVK não passam no critério 3.

A seguir, alguns projetos conhecidos que usam o Mercurial ou o Git:

• Mercurial: Google Code, Python, Java (OpenJDK), Mozilla, Netbeans (IDE), OpenSolaris  etc.
• Git: Linux kernel, Perl, Samba, X.org Server, Qt, Ruby on Rails,  GNOME, Google Android, Btrfs da Oracle etc.

Aspectos Sociais na Escolha do DVCS

Critérios de desempate podem ser desempenho, funcionalidades, facilidade de uso, portabilidade, interfaces etc. O problema é que as análises comparativas entre o Mercurial e o Git têm mostrado muito mais semelhanças que diferenças entre os dois. Embora um ou outro tenha uma pequena vantagem em algum dos aspectos, não há diferença realmente significativa que justifique uma decisão baseado nisso.

Processos recentes tem usado outros fatores para o desempate tais como menor curva de aprendizado, suporte à plataforma Windows e preferência dos desenvolvedores para definir a escolha:

1. A análise comparativa feita pelo Google Code entre o Mercurial e o Git considerou as duas alternativas bastante equilibradas. O Mercurial foi escolhido por ter um conjunto de comandos mais próximos do Subversion, o que facilita a transição dos desenvolvedores, e também por ter desempenho e adequação melhores ao serviço que o Google Code já oferece.
2. Outro exemplo é o processo que levou o Python a também adotar o Mercurial (PEP 374 – Chosing a distributed VCS for the Python project). A análise comparativa entre Mercurial, Bazaar e Git apresentou alguns casos de uso, comparações de desempenho etc. mas, no final, o que pesou bastante foi o melhor suporte ao Windows, a preferência da comunidade de desenvolvedores pelo Mercurial e, é claro, o fato de o Mercurial ser escrito em Python.

Considerando funcionalidades e desempenho equivalentes, o que vai ser importante na escolha são as afinidades do Git ou Mercurial com as características do projeto/equipe/empresa. O desempate acabará sendo feito por critérios mais subjetivos tais como proximidade com outros projetos relacionados e preferência dos desenvolvedores.

Fonte: http://pronus.eng.br/blog/http:/pronus.eng.br/blog/qual-a-melhor-ferramenta-de-controle-de-versao-subversion-git-ou-mercurial

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/