@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.
El punto 1, mi preferencia seguiría en desarrollar poco un paso de deployment/test más en forma, pero para ello sería bueno primero terminar con el tema de colaboración distribuida.
En el punto 2, ya lo vivimos como lo que pasó con los parches que te envié (de los archivos de python), resulta más y más difícil integrarlo con el ritmo que llevan vía svn. La colaboración distribuida es más anárquica en cierto modo, pero vence en conveniencia cuando hay cosas y temas muy sencillos que se pueden aislar por medio de ramas. Eso sin tomar en cuenta lo que menciona ESR sobre la barrera de los nuevos colaborades y las tecnologías que están siendo "vencidas"[1]. Git/hq es un "mal necesario" a favor de la sociabilidad.
Abogo más por una colaboración más abierta (y caótica), aunque sin duda requerirá un(os) paso(s) extra (automatizable, según mi experiencia).
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.
Continúa...
@crodas Ahí estoy de acuerdo con @gallir