VidaGeek.net

Linux, Open-source, Programação e Produtividade

Archive for the ‘Dicas’ Category

Como migrar de SVN para GIT

Sei que tem um monte de tutoriais por aí de como migrar de svn para git, mas não achei nenhum com tudo que eu precisasse e em português. Então aqui vai o meu :)

WARNING!!!! Se você tem um repositório svn público e vai migrar para o github, use o script de migração que ele te oferece quando você cria um repositório lá.

  1. Primeiro você deve instalar o git-svn. Não sei como instalar via apt, mas com o macports é um simples sudo port install git-core +svn (talvez você precise desinstalar o git-core antes de conseguir instalar. Se for o caso, sudo port uninstall git-core)

  2. Crie um arquivo mapeando os usuários do svn para os do git. Algo como:

    jonas = Jonas Abreu <jonas@vidagek.net>
    usuario_svn = Nome Usuario <email@usuario.net>
    

    Dê o nome que quiser para o arquivo.

  3. Faça checkout com o git svn

    mkdir repo_temp
    cd repo_temp
    git svn init URL_DO_SEU_REPOSITORIO_SVN --no-metadata
    git config svn.authorsfile ARQUIVO_DE_MAPEAMENTO
    git svn fetch
    

    É bem importante não esquecer do –no-metadata. Isso vai evitar que ele traga um monte de lixo (.svn, se não me engano) para sua máquina.

  4. Limpe a sujeira que o git svn colocou no seu repositório git local clonando ele.

    cd ..
    git clone repo_temp repo_final
    
  5. Altere a url da origem do seu repositório local:

    cd repo_final
     .git/config
    

    Troque a url:

    [remote "origin"]
          url = repo_temp
    

    pela url do seu repositório git:

    [remote "origin"]
           url = URL_DO_SEU_REPOSITORIO
    
  6. Envie os dados para o seu servidor remoto:

    git push origin master
    

Pronto. Seu repositório acabou de ser migrado de svn para git. Simples, fácil e rápido (a não ser que você tenha uns 10k commits. Aí vai demorar bastante. No meu caso demorou cerca de 4 horas o processo completo.)

Posts Relacionados:

  • Como descobrir todos que commitaram em um repositório SVN
  • Como remover os malditos .svn
  • Git Workflow
  • Como desfazer commits na branch errada no Git
  • Cuba Libre
  • Ubuntu Ganha o Parlamento Francês
  • Ambiente aberto de Xadrez Online
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

    Por tudo que é sagrado, escrevam testes!

    Acho que já passou da hora dos programadores amadurecerem um pouco quanto a necessidade de testes para TODA e QUALQUER aplicação que seja escrita, independente do tamanho. Acho que já passou muito da fase na qual a arrogância era o suficiente para você acreditar que sua aplicação funcionaria sem testes, afinal, você é o melhor programador do mundo.

    “Mas o Knuth não usa testes. A gente tem que seguir o exemplo dos melhores”.

    Concordo. Temos que seguir o exemplo dos melhores programadores do mundo. Mas lembre-se, Knuth não usa testes porque ele é o Knuth. Se ele diz que a aplicação dele funciona sem escrever testes eu acredito. Se isso é bom, acho questionável. Knuth não trabalha com mercado. Ele não trabalha dando manutenção em código. Ele trabalha apenas em projetos onde ele tem controle total (vale lembrar que embora o TeX seja aberto, apenas o Knuth pode usar o nome TeX). E ele é um dos maiores programadores do mundo. Uma realidade bem diferente da qual eu e você passamos todos os dias.

    Sei que o mundo já gritou a muito tempo que sem testes não rola nenhuma aplicação (já ouviu falar dos caras que escreveram o Manifesto Ágil? Não? Onde você viveu nos últimos anos?). Dos maiores aos menores bons programadores. Por que raios seguir o exemplo desses caras? Será que eles realmente não sabem o que estão falando?

    Dê uma chance ao que eles estão dizendo.

    Eu, que não sou ninguém ainda, consigo ver incontáveis vantagens em usar testes.

    • O tempo de desenvolvimento diminui a partir da terceira semana consideravelmente (Não temos mais que nos matar caçando bugs de regressão e esperando o pessoal de QA dar aval);
    • Em geral testamos o código com um main, pra ver se está funcionando. Qual a diferença de tempo entre isso e escrever um teste de verdade que vai te ajudar por todo o projeto?
    • Sabemos exatamente qual modificação causou uma quebra de compatibilidade (em vez de saber em qual mês ela ocorreu);
    • Não precisamos lembrar de absolutamente todo o código. Se esquecer, dê uma olhada nos testes daquela parte do código e pronto;
    • Se alguém for dar manutenção no código daqui a 6 meses e incidentalmente introduzir um bug, os testes vão avisar;
    • Integração contínua funciona por causa dos testes;
    • Refactoring funciona por causa dos testes;
    • Agile development funciona por causa dos testes;
    • O Design da sua aplicação tende a ficar melhor e menos acoplado;
    • Entre outros, o que eu considero mais importante é o fato de poder dormir em paz, sabendo que meu código está funcionando. Ninguém vai me ligar no fim de semana (ou no meio da noite) para arrumar um sistema que está em produção.

    E você ainda acha que não vale a pena investir nisso? Ignore o que os programadores de 30 anos atrás ainda estão falando (a não ser que eles tenham bom senso e usem testes).

    Mas como faço para escrever testes? Primeiro, clique aqui.

    Gostou? É assim que se aprende muito em computação sobre o que é relativamente novo no mercado. E testes infelizmente ainda são relativamente novos no mercado.

    E depois? O que eu devo fazer? Bom, de agora em diante, apenas ter disciplina para escrever os testes para as suas funcionalidades. Pronto. E o mundo está quase salvo =D .

    Programadores não podem ter medo de aprender coisas novas. O novo, em programação, é o que vai garantir que possamos chegar em casa e viver um pouco, em vez de apenas trabalhar por horas até a exaustão.

    Posts Relacionados:

  • Testes unitários em C++
  • Os criadores do Skype atacam novamente…
  • Dia C - Usando testes para o desenvolvimento
  • TDD para Ruby - Fibonacci
  • Infinitest
  • FISL 9.0: Coding Dojo
  • Um caso de ódio e talvez um pouco de amor (Também conhecido como automatizadores de build)
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

    Construindo sua marca

    Tempos atrás li um post do Jay Fields onde ele comentava sobre a importância de você ter uma marca. Em outras palavras, ele falava sobre você existir para o resto do mundo, expandir seus horizontes.

    Por exemplo, atravéz do VidaGeek, diversas oportunidades já apareceram pra mim e outros membros do blog. Fui convidado para um estágio na Google (infelizmente não rolou por problemas administrativos), tive contato com programadores que me mostraram caminhos que eu desconhecia, entre outros.

    Mas um detalhe fundamental, você não estaria lendo esse post se não tivesse-mos criado a marca VidaGeek (atravéz da criação de conteúdo de qualidade e um pouquinho de divulgação). E essa é uma das dicas do Jay Fields.

    Em geral, o mundo não está interessado em você. Poucas pessoas sabem que você existe. Se você não forçar o mundo a vê-lo, vai continuar escondido em algum canto. Construir uma marca é exatamente sair do seu pequeno mundo e ampliá-lo, sempre deixando bem claro quem é você (para que o resto do mundo te encontre depois).

    E como fazer isso? É simples, mas exige um trabalho incrível.

    Primeiro: Aprenda inglês. Antes de mais nada você precisa conseguir se comunicar com o resto do mundo e a linguagem padrão é inglês, quer você goste ou não.

    Segundo: Mantenha-se informado. Você não vive mais sozinho. Existem várias outras pessoas no mundo com muito a te ensinar. Leia livros, acompanhe blogs (não apenas sobre computação).

    Terceiro: Contrinua com a comunidade. OpenSource é porta para muitas coisas. Você aprende muito e cria algo que facilita a vida das pessoas que por sua vez vão contribuir com algo que facilita a sua vida, criando um ciclo virtuoso, porque agora você vai ter mais tempo para contribuir :D.

    Quarto: Diga ao mundo o que está fazendo e passe conhecimento para frente. Se você não falar, ninguém vai saber. E se você não ajudar os outros a aprender, não existe muita razão para que eles voltem para o seu site.

    Por último, ignore tudo que falei acima quando quiser ou achar que faz sentido. Não existe um único caminho para se construir uma marca. Você tem que achar o seu.

    Posts Relacionados:

  • Guia Latex - Parte I: O que é e por que usar
  • Promoção RedBug
  • Guia Latex - Parte III: Estruturando e marcando o texto
  • FISL 8.0: Programando a nova cultura da colaboração
  • Scripts para o Greasemoney do Firefox
  • Algoritmos Humorísticos - Trainee Algorithm
  • SNL - O Caçador de Pipas
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

  • 2 Comments
  • Filed under: Dicas, Opiniao
  • Semana passada, Michael Feathers publicou um post no blog da ObjectMentor onde indica 10 artigos que todo programador deveria ler. Segundo ele, a lista contém artigos que abrangem assuntos que todo programador deve saber sobre código. Os artigos estão em inglês. Essa lista pode servir de um resumo do que há de mais importante para aprender sobre programação para quem pretende trabalhar com isso. A lista segue abaixo, com links para versões gratuitas dos artigos (no post original, nem todos os links são para versões gratuitas) (more…)

    Posts Relacionados:

  • Permissões do .ssh
  • Linguagens de Programação - Python versus Ruby
  • FISL 8.0 - A Ida
  • O mal dos programadores
  • INC - Isso Não Compila!!!
  • Linguagens de Programação - C
  • Dia C - VarArgs
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.