devlog

Ao criar um controlador em uma pasta que estava num repositório svn, ele já adicionou o controller ao repositório

Link: http://coreygilmore.com/blog/2007/09/14/ignoring-svn-directories-with-grep/

Uma dica que veio em boa hora pra mim

1ª opção:

grep -ri "your password is" * | grep -v .svn

2ªopção:

GREP_OPTIONS="--exclude=\*.svn\*"
export GREP_OPTIONS

A partir de então, o grep já ignora os diretórios .svn.

Retirado de: http://coreygilmore.com/blog/2007/09/14/ignoring-svn-directories-with-grep/

Há um tempo atrás, um amigo pediu para que eu escrevesse algo sobre o svn. Como eu enrolei, acabou que o ùltimo log fez isso por mim, com um tutorial básico sobre o svn bem descontraído. Não cobre coisas como externals e propriedades, mas já dá pra iniciar a usar o subversion sem muito grilo.

A maioria dos repositórios que eu uso são subversion (com exceção do b2evolution, que é CVS). Porém, semana passada eu tive contato com um outro tipo de repositório. O subversion e o CVS são variações do mesmo tema: um gerenciador de controle de versão centralizdo, onde as coisas estão todas num servidor, e todos voltam a ele.

Com o mercurial, que foi o SCM que eu testei, a coisa é diferente. Cada cópia de um repositório mercurial é ela mesma um repositório completo. Você pode enviar o seu código pra esse repositório cópia que ele não será propagado automaticamente para o repositório pai. Aliás, não há exatamente um repositório pai: se 2 programadores fazem o checkout de um repositório desse tipo, ambos os repositórios podem ser copiados por mais pessoas. Essa é a idéia de repositórios descentralizados.

Parece um pouco anárquica a idéia, mas é interessante. Além de manter o código fonte do projeto sobre controle de versão, você acaba mantendo o seu próprio código sobre um controle de versão também. Fez algma besteira no código? Não tem problema, isso não afetou o repositório original, apenas o seu. E como o Thiago Arrais fala em seu post sobre o assunto, os próprios usuários acabam por eleger um repositório como principal, que receberá o merge dos outros repositórios. Mas isso é apenas uma escolha dos usuários, eles não tem a obrigação de considerar esse ou aquele repositório como principal.

Uma idéia bacana, utilizada pelo darcs, git e mercurial. Um pouco complicada a princípio, mas confesso que me atrai bastante.

Apesar de saber desde um tempo a importância de se ter um controle de versões, só hoje eu tomei coragem e comecei a testar o subversion.

Instalei também dois clientes gráficos para o subversion (eu pretendo aprender a sintaxe dos comandos logo, logo).

O primeiro que eu instalei foi o Rapid SVN, que é feito em wxWidgets e C++.

Depois, testei o esvn, que é em QT.

O esvn contém já um diff tool embutido, enquanto para o rapidsvn estou usando o meld (que a bem da verdade já venho usando a algum tempo).

A princípio, o esvn tem levado uma pequena vantagem nos testes.

Ambos os pacotes foram obtidos pelo repósitorio do Debian (unstable).