terça-feira, 3 de março de 2015
quarta-feira, 25 de fevereiro de 2015
quarta-feira, 21 de janeiro de 2015
Apache Subversion - SVN e seus comandos principais
O Apache Subversion, conhecido como SVN, é um sistema de controle de versão e foi desenvolvido a partir do CVS com a proposta de corrigir suas limitações.
Dessa forma, o SVN funciona em quase tudo como o CVS, no entanto com acrescimentos de algumas outras funcionalidades. No SVN foram introduzidos os comandos rename e move, para corrigir os problemas relacionados a renomear e mover arquivos no CVS. Esses comandos não apenas renomeia/move o arquivo como mantém seu histórico de alterações. Diferente do CVS, no SVN o comando commit (de envio de arquivos) suporta rollbacks em caso de falhas. Além disso é possível também versionar arquivos não suportados pelo CVS, como links simbólicos. O SVN possui também capacidade de guardar metadados dos arquivos e diretórios.
SVN e CVS possuem basicamente os mesmos comandos, com exceção de alguns contidos apenas no SVN - como o comando move. Segue abaixo a lista dos principais comandos e sua descrição:
checkout
Ao executar este comando, o módulo (projeto) selecionado no repositório é baixado para o cliente.
add
Novos arquivos criados no módulo devem ser adicionados com este comando.
del
Remove o arquivo da próxima versão.
move
Renomeia ou move um arquivo no versionamento (deletando o antigo e adicionando o novo).
status
Visualiza se um arquivo será ou foi adicionado, deletado, ou modificado localmente ou no repositório.
diff
Visualiza as alterações feitas no arquivo.
log
Visualiza a mensagem de commit do arquivo.
revert
Reverte a alteração local feita no arquivo para a versão anterior.
update
Atualiza o módulo para a versão mais recente. Se houver alterações no mesmo arquivo, automaticamente é feito o merge - mescla ente ambos. Quando há conflitos, o arquivo é marcado e a mescla deve ser feita manualmente.
resolved
Remove o status de conflito do arquivo.
commit
Envia as alterações do módulo para o repositório central.
Referências
http://pt.stackoverflow.com/questions/8315/diferen%C3%A7as-entre-git-svn-e-cvs
http://pt.wikipedia.org/wiki/CVS
http://pt.wikipedia.org/wiki/Subversion
http://mariomariani.blogspot.com.br/2010/02/comandos-mais-usados-do-svn.html
Dessa forma, o SVN funciona em quase tudo como o CVS, no entanto com acrescimentos de algumas outras funcionalidades. No SVN foram introduzidos os comandos rename e move, para corrigir os problemas relacionados a renomear e mover arquivos no CVS. Esses comandos não apenas renomeia/move o arquivo como mantém seu histórico de alterações. Diferente do CVS, no SVN o comando commit (de envio de arquivos) suporta rollbacks em caso de falhas. Além disso é possível também versionar arquivos não suportados pelo CVS, como links simbólicos. O SVN possui também capacidade de guardar metadados dos arquivos e diretórios.
SVN e CVS possuem basicamente os mesmos comandos, com exceção de alguns contidos apenas no SVN - como o comando move. Segue abaixo a lista dos principais comandos e sua descrição:
checkout
Ao executar este comando, o módulo (projeto) selecionado no repositório é baixado para o cliente.
add
Novos arquivos criados no módulo devem ser adicionados com este comando.
del
Remove o arquivo da próxima versão.
move
Renomeia ou move um arquivo no versionamento (deletando o antigo e adicionando o novo).
status
Visualiza se um arquivo será ou foi adicionado, deletado, ou modificado localmente ou no repositório.
diff
Visualiza as alterações feitas no arquivo.
log
Visualiza a mensagem de commit do arquivo.
revert
Reverte a alteração local feita no arquivo para a versão anterior.
update
Atualiza o módulo para a versão mais recente. Se houver alterações no mesmo arquivo, automaticamente é feito o merge - mescla ente ambos. Quando há conflitos, o arquivo é marcado e a mescla deve ser feita manualmente.
resolved
Remove o status de conflito do arquivo.
commit
Envia as alterações do módulo para o repositório central.
Referências
http://pt.stackoverflow.com/questions/8315/diferen%C3%A7as-entre-git-svn-e-cvs
http://pt.wikipedia.org/wiki/CVS
http://pt.wikipedia.org/wiki/Subversion
http://mariomariani.blogspot.com.br/2010/02/comandos-mais-usados-do-svn.html
Git ou Mercurial? parte 2
Um fato é que se considerarmos as funcionalidades e desempenho equivalentes (ou muito aproximados), a afinidade do Git ou Mercurial com as características da empresa/projeto/equipe se mostrarão mais importantes e desempatar será cada vez mais decidida por aspectos subjetivao como proximidade com outros projetos relacionados e preferência dos desenvolvedores.
Projetos Relacionados
Projetos maiores que já usam o Mercurial ou o Git acabam atraindo projetos relacionados para o seu campo de influência.
A interferência direta se dá quando é necessário acompanhar ou mesmo participar de certos projetos externos associados com o projeto da equipe. A escolha da mesma ferramenta para todos torna o controle de versão muito mais fácil pois define um padrão homogêneo.
A tabela a seguir apresenta alguns projetos e qual a ferramenta que usam.
| Projeto | Git | Mercurial |
|---|---|---|
| Google Android | X | |
| Google Code | X | |
| Pylons | X | |
| Python (linguagem) | X | |
| Ruby on Rails | X | |
| Sun (OpenJDK, NetBeans, OpenSolaris) | X |
Preferência dos Desenvolvedores
Esse é o critério mais passional de todos. O que leva um desenvolvedor a preferir uma ferramenta a outra varia desde a identificação com a filosofia do projeto até a preferência pelo logotipo do projeto. De qualquer modo, uma tendência clara da equipe por uma ferramenta específica deve ser pesado na decisão final.
Estudos de Caso
| Projeto X | Projeto Y | Projeto Z | |
|---|---|---|---|
| Escolha Final | Mercurial | Git | Mercurial |
| Plataforma | Windows | Windows/Linux | Linux |
| IDE/Interface | Eclipse | NetBeans | linha de comando |
| Linguagem Principal | Java | Ruby | Python |
| Projetos relacionados usam | Subversion/Mercurial | Git | Subversion/Mercurial |
| Preferência dos Desenvolvedores | - | Git | Mercurial |
Considerações Finais
Git e Mercurial são ambas ótimas opções de controle de versão distribuído. A análise de um ou outro baseado em número de funcionalidades, forma de implementação interna, desempenho etc. acaba caindo em um tipo de discussão que abunda pelas listas de discussão na internet a fora e que gera muito calor e pouca luz!
Em termos práticos, ambas as ferramentas são muito parecidas e é mais fácil (e prático) escolher entre uma e outra com base na afinidade com o projeto/equipe.
É bom lembrar que controle de versão é muito mais que instalar a ferramenta e sair usando. É necessária a capacitação dos desenvolvedores, a definição de um processo de GCS em sintonia com as particularidades da ferramenta e também integração com uma ferramenta de controle de mudança (por exemplo, o Trac).
Git ou Mercurial? parte 1
Conhecemos os dois tipos de controles de versão: o centralizado e o Distribuído e levando em consideração isso devemos analisar a partir de alguns critérios qual seria a melhor ferramenta para as equipes que decidiram migrar para o distribuído ou mesmo permanecer com o centralizado.
Para quem vai ficar no controle de versão centralizado, é bem simples decidir já é o Subversion é um padrão estabelecido, acima de outros tais como CVS, Visual Source Safe, ClearCase etc.
Já para os que optaram por escolher uma ferramenta de controle de versão distribuído, a escolha é um desafio.
Para diminuir o número inicial de ferramentas a se considerar, vamos usar alguns critérios de filtragem inicial:
Open source.
As melhores são open source então não há a menor necessidade de usar uma ferramenta proprietária para controle de versão.
Multiplataforma (Windows, Linux, etc.).
A mesma ferramenta deve permitir o uso de qualquer plataforma de interesse da a equipe para trabalhar. Se houver interface gráfica (tipo o Tortoise) ou plugin para IDEs é ainda melhor, mesmo que a linha de comando seja muito mais rápida e produtiva para a maioria das operações do controle de versão.
Massa crítica de projetos já usando.
Projetos grandes usando uma ferramenta são boas referências, sinaliza que ela já foi testada, avaliada e aceita por outros antes. Com mais projetos fica mais provável que haverá uma comunidade ativa mantendo e desenvolvendo a ferramenta por mais tempo.
Após usar esses critérios acima, nos restam praticamente o Git e o Mercurial. O Bazaar poderia entrar na lista, mas para facilitar a comparação não o incluímos(com resultados piores que os outros 2 e não tão popularizado). Muitos 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:
A seguir, alguns projetos conhecidos que usam o Mercurial ou o Git:
[2]
Git:
[2]
Aspectos Sociais na Escolha do DVCS
2 - Gerenciadores de Controle de Versão: Git, Mercurial e Bazaar. Boa apresentação em slides comparando as 3 ferramentas exibindo dados e tabelas interessantes.
Why Git is better than X? Artigo interessante que analisa diversos pontos de Git com boas ilustrações de conceitos.
Os 6 melhores controle versões OpenSource. Bom comparativo entre sistemas de controle de versão.
PEP 374 – Chosing a distributed VCS for the Python project.Google Code - análise comparativa Mercurial e Git.
"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.Novos processos tem se apoiado em outros fatores de desempate, suporte à plataforma Windows, preferência dos desenvolvedores envolvidos e menor curva de aprendizado da ferramenta."[1]
2 exemplos de escolhas fundadas no aspecto social:
O Google Code fez uma análise comparativa entre o Mercurial e o Git considerando as duas alternativas bastante equilibradas e escolheram o Mercurial seu conjunto de comandos ser mais próximos do Subversion, o que facilita a transição dos desenvolvedores, e pelo serviço que o Google Code já oferece ter tido melhor desempenho e adequação com o Mercurial do que o Git.
O processo que levou o Python a também adotar o Mercurial (PEP 374 – Chosing a distributed VCS for the Python project) comparou Mercurial, Bazaar e Git e apresentou comparações de desempenho obtido, alguns casos de uso, mas as características que favoreceram o Mercurial foram: seu melhor suporte ao Windows, a preferência da comunidade de desenvolvedores pelo Mercurial e, o fato de o Mercurial ser escrito em Python , que facilitou a assimilação da ferramenta.
O processo que levou o Python a também adotar o Mercurial (PEP 374 – Chosing a distributed VCS for the Python project) comparou Mercurial, Bazaar e Git e apresentou comparações de desempenho obtido, alguns casos de uso, mas as características que favoreceram o Mercurial foram: seu melhor suporte ao Windows, a preferência da comunidade de desenvolvedores pelo Mercurial e, o fato de o Mercurial ser escrito em Python , que facilitou a assimilação da ferramenta.
Fontes
1- Blog Pronus - Qual a melhor ferramenta de controle de versão: Subversion, Git ou Mercurial. Comparação entre Git e Mercurial principalmente considerando fatores socias para a escolha.2 - Gerenciadores de Controle de Versão: Git, Mercurial e Bazaar. Boa apresentação em slides comparando as 3 ferramentas exibindo dados e tabelas interessantes.
Links relacionados
Comparação entre Git e Mercurial. Quadro comparativo entre principais características entre os dois. Alguns comentários interessantes também sobre portabilidade e interfaces disponíveis.Why Git is better than X? Artigo interessante que analisa diversos pontos de Git com boas ilustrações de conceitos.
Os 6 melhores controle versões OpenSource. Bom comparativo entre sistemas de controle de versão.
PEP 374 – Chosing a distributed VCS for the Python project.Google Code - análise comparativa Mercurial e Git.
Funcionamento do CVS
Como Funciona
O CVS funciona a partir da arquitetura cliente-servidor. Nesta arquitetura, um servidor armazena as versões do projeto e os usuários envolvidos se conectam ao servidor para acessar, fazer cópia e atualizar o projeto, neste caso, se comportando como clientes. Cliente e servidor podem se conectar através de uma rede local ou Internet. É também possível que cliente e servidor estejam na mesma máquina, caso a configuração do CVS seja feita de maneira a dar acesso a versões e histórico do projeto apenas a usuários locais. Um servidor CVS deve estar em um Sistema Operacional Unix (ou Linux), no entanto não há restrições para o cliente.
Os projetos gerenciados pelo CVS são chamados de módulos. Os módulos são acessados e modificados de maneira concorrente por um grupo de usuários que trabalham em equipe. Quando alterações são feitas e confirmadas - através do comando commit - o servidor ao ser atualizado - com o comando update - faz uma mescla do projeto atual com o que há de novo. A mescla é feita através do merge. No entanto, se houver conflito entre arquivos modificados - quando há, por exemplo, modificações diferentes feitas na mesma região de um arquivo - o merge é abortado e o servidor avisa que existe algum conflito e que é necessário uma intervenção humana. Caso contrário, a versão é incrementada e o servidor CVS escreve uma linha de observação com data e o autor das alterações em seus arquivos de log - além de observações informadas pelo próprio usuário, quando houver.
Entre as funcionalidades disponíveis aos usuários clientes estão a capacidade de comparar diferentes versões de um arquivo, pedir um histórico completo das alterações ou baixar uma determinada versão do projeto - a partir de uma data ou de uma das alterações no histórico, por exemplo. Para manter suas cópias locais atualizadas com a última versão do servidor os clientes utilizam o comando update.
No repositório existem 3 tipos de diretório: trunk, branches e tags. O trunk mantém o fluxo principal de desenvolvimento. Já o branches mantém os fluxos alternativos de desenvolvimento, como novas ramificações a partir de uma determinada versão. Por último, em tags ficam registradas revisões que não podem mais serem alteradas, ou seja, versões estáveis do projeto.
Limitações
As maiores limitações do CVS estão relacionadas a impossibilidade de mover e renomear arquivos sem perder sua referência e seu histórico de alterações. Quando necessário renomear um arquivo, este deve ser explicitamente removido e novamente adicionado com seu novo nome. Para mover ou renomear diretórios são enfrentados os mesmos problemas, dessa forma, cada arquivo do subdiretório em questão deve ser individualmente removido e readicionado.
O Apache Subversion (SVN), criado como substituto do CVS, corrige essas falhas.
Referências
http://www.embarcados.com.br/controle-de-versoes-parte-ii-cvssvn/
http://www.devmedia.com.br/cvs-instalacao-e-configuracao/2801
http://pt.wikipedia.org/wiki/CVS
O CVS funciona a partir da arquitetura cliente-servidor. Nesta arquitetura, um servidor armazena as versões do projeto e os usuários envolvidos se conectam ao servidor para acessar, fazer cópia e atualizar o projeto, neste caso, se comportando como clientes. Cliente e servidor podem se conectar através de uma rede local ou Internet. É também possível que cliente e servidor estejam na mesma máquina, caso a configuração do CVS seja feita de maneira a dar acesso a versões e histórico do projeto apenas a usuários locais. Um servidor CVS deve estar em um Sistema Operacional Unix (ou Linux), no entanto não há restrições para o cliente.
Os projetos gerenciados pelo CVS são chamados de módulos. Os módulos são acessados e modificados de maneira concorrente por um grupo de usuários que trabalham em equipe. Quando alterações são feitas e confirmadas - através do comando commit - o servidor ao ser atualizado - com o comando update - faz uma mescla do projeto atual com o que há de novo. A mescla é feita através do merge. No entanto, se houver conflito entre arquivos modificados - quando há, por exemplo, modificações diferentes feitas na mesma região de um arquivo - o merge é abortado e o servidor avisa que existe algum conflito e que é necessário uma intervenção humana. Caso contrário, a versão é incrementada e o servidor CVS escreve uma linha de observação com data e o autor das alterações em seus arquivos de log - além de observações informadas pelo próprio usuário, quando houver.
Entre as funcionalidades disponíveis aos usuários clientes estão a capacidade de comparar diferentes versões de um arquivo, pedir um histórico completo das alterações ou baixar uma determinada versão do projeto - a partir de uma data ou de uma das alterações no histórico, por exemplo. Para manter suas cópias locais atualizadas com a última versão do servidor os clientes utilizam o comando update.
No repositório existem 3 tipos de diretório: trunk, branches e tags. O trunk mantém o fluxo principal de desenvolvimento. Já o branches mantém os fluxos alternativos de desenvolvimento, como novas ramificações a partir de uma determinada versão. Por último, em tags ficam registradas revisões que não podem mais serem alteradas, ou seja, versões estáveis do projeto.
Limitações
As maiores limitações do CVS estão relacionadas a impossibilidade de mover e renomear arquivos sem perder sua referência e seu histórico de alterações. Quando necessário renomear um arquivo, este deve ser explicitamente removido e novamente adicionado com seu novo nome. Para mover ou renomear diretórios são enfrentados os mesmos problemas, dessa forma, cada arquivo do subdiretório em questão deve ser individualmente removido e readicionado.
O Apache Subversion (SVN), criado como substituto do CVS, corrige essas falhas.
Referências
http://www.embarcados.com.br/controle-de-versoes-parte-ii-cvssvn/
http://www.devmedia.com.br/cvs-instalacao-e-configuracao/2801
http://pt.wikipedia.org/wiki/CVS
Assinar:
Postagens (Atom)