La única ventaja que veo de pasarlo a git es poder hostear en github y hacerlo mainstream.
Para los ficheros estáticos se puede escribir un scriptcito en grunt (o hasta en PHP para no instalar una nuevo programa) que pase los ficheros de foo.js a foo.<substr(hash, 0, .js y que haga un replace de las views. A mi entender hacer eso es más cache friendly (mucho más que tener foo.js?$x).
@crodas@esparta Exportar no es problema, es el uso diario y la felxibilidad. El svn nos es mucho más cómodo. Lo de hacer "mainstream" sólo por tenerlo en GitHub... bueeeeeno
Lo de versiones y caché, hace meses que ha cambiado, por ejemplo:
@gallir@crodas Ya lo entiendo mejor, pero a mi parecer se tienen dos temas:
1.- La convenincia de usar el control de versiones como pasarela para deployment/test,
2.- La inconveniencia de la colaboración de terceros en la programación
La idea que propongo sigue siendo la misma, el "Blessed Repository" (BR), serviría igual como viene funcionando svn.meneame.net, pero a diferencia de éste, el control podría llegar a nivel branches: NFS/dev estaría ligado a BR->dev y NFS/www a BR->master. Cada uno de los directorios de NFS puede ser por medio de un clon del BR: cada clon hace un `git pull` cada que lo necesite ya sea con un script, con un hook de git o manualmente o por medio de cron (posibilidades hay muchas).
Si se decidiera lo faltante sería ver si se quiere usar un host de terceros o un hosting local. De ello dependería las siguientes etapas se sincronización de los repo publicos con el BR.
La única ventaja que veo de pasarlo a git es poder hostear en github y hacerlo mainstream.
Para los ficheros estáticos se puede escribir un scriptcito en grunt (o hasta en PHP para no instalar una nuevo programa) que pase los ficheros de foo.js a foo.<substr(hash, 0,
Para las pruebas me sumo como voluntario