Acompanho o twitter de varios desenvolvedores e vire e mexe alguém esta com alguma reclamação com seus arquivos versionados tipicamente estes arquivos são os “.svn” .

Os arquivos svn são pastas que contem a assinatura dos arquivos e seus conteúdos, ou seja tudo fica duplicado,  e algumas vezes quando vamos enviar esses arquivos para o servidor de produção não nos atentamos que estamos enviando junto os arquivos svn o que faz a transferencia ficar muito mais lenta pois tem que se enviar muito mais arquivos.

Hoje vejo que isso pode ser contornado de 3 formas diferentes:

Baixando as Atualizações via svn

Nesta modalidade o desenvolvedor envia todos os seus códigos para o servidor de svn “svnserver”,
mas antes verifica se algo entrou em conflito ou se ele próprio precisa fazer alguns updates.

svn status -u /url/pasta/raiz/projeto/

Imaginando que tudo esta correto e que somente ele tem arquivos a serem enviados.

svn commit -m "SEU COMENTÁRIO" /url/do/arquivo/a/ser/commitado/
svn commit -m "SEU COMENTÁRIO" /url/da/pasta//commitada/

Pronto tudo esta pronto e devidamente no seu lugar, agora vamos logar na máquina de produção e fazer o update que foi enviado.

svn update /url/pasta/raiz/projeto/

Neste modo nada se perde no caminho. Fim todo mundo feliz

Mandando pequenas atualizações que ainda não são a versão final do arquivo

Nesta modalidade o desenvolvedor envia todos os seus códigos para o servidor de testes, portanto não importa se vai haver svn ou não. O que importa aqui seria ser um pouco mais rápido.

Ai ele limpa todos os .svn para ficar mais leve o envio.

cp -R /url/pasta/raiz/projeto/ /tmp/projeto
find /tmp/projeto -iname *.svn -exec rm -rf {} \;

Assim foram apagados todos os arquivos .svn da pasta do projeto pois esse foi copiado para o /tmp/projeto
Assim só precisamos enviar os novos arquivos para o servidor TESTE , leia-se TESTE e não “DE TESTE”

scp -r /tmp/projeto/arquivo/ usuario@host:/url/pasta/raiz/projeto/

Os arquivos são enviados e todos quase ficamos felizes, pois essa não é a melhor prática.

Mandando pequenas atualizações que ainda não são a versão final do arquivo por rsync

Esta é a caracteristica do rsync que achei interessante pois não conhecia a syntaxe.
A opção -C do rsync exclui uma penca de arquivos que normalmente eu apagava na mão, e evita que se tenha que copiar para um segundo diretorio todos os arquivos para depois limpa-los.
Sendo assim enviando para o mesmo sever bastaria fazer o seguinte.

rsync -Cavz -e ssh /url/pasta/raiz/projeto/  usuario@host:/url/pasta/raiz/projeto

Todos os arquivos que foram modificados serão enviados e com a vantagem de ser descartados esses tipos de arquivo.

RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS .make.state .nse_depinfo *~ #* .#* ,* _$* *$  *.old  *.bak  *.BAK  *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core .svn/

Como tem alguns desenvolvedores que mesmo sob um sistema de controle de versão (svn) continuam usando o “.old” o rsync também os ignora, isso é simplesmente lindo!

Essas são algumas práticas que tenho observado no twitter e também com companheiros de trabalho.

Acho que essas dicas podem ajudar alguém por isso postei esses detalhes.

E existem também muitas outras maneiras de fazer esse deploy. Invente a sua ….

1. Rafael Henter Says:
   agosto 1st, 2009 at 18:26

   Ficou bem legal. Simples e direto