Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
@gallir@crodas Me parece adecuado todos los puntos, eso dará tiempo a encontrar formas más eficientes de todo, junto con pruebas de concepto independientes. Mi idea inicial siempre ha sido el dejar el control de versiones para sólo eso y el despliegue en algo más sencillo (o especializado) y con menos trabajo para quien le toque hacerlo. Así es como lo llevo en mi trabajo, y sigo aprendiendo en ello.
El WebSVN es bueno, pero si actualmente sólo sirve para mostrar el código igual mejor tirarlo. El primer paso de un mirror en github es avance, y permitirá revisar igualmente la hipótesis de que no hay cambio en la colaboración.
@Pecinejo@esparta@crodas Lo decía para quitar completamente el svn de acceso público (y menos trabajo para mantener el demonio y el websvn) y dejar sólo el otro (que llevará unas horas o minutos de retraso).
@gallir@gallir@crodas Hay en el mercado de SL varias soluciones para hosting, aunque la más "cómoda" es tercerizarlo. Github* es el defacto. GH ayuda a que puedes integrarlo con otros servicios para pruebas automatizadas (con unit testing, pero eso es otro tema).
Para self-hosting las dos opciones más maduras son GitLab y gitorius. Pero ambas tienen el detalle que son en ruby, y suelen ser bastante pesadas. En Efecto Tequila se tiene GitLab: git.efectotequila.com (nuestro benévolo dictador lo puso en marcha)
En los tres es relativamente sencillo poner los puntos 1 a 3, sobre todo el punto 2 y 3. La belleza de cualquiera de ellos es que se pone en contexto el problema, el código y la colaboración. Hay quieres creen que gitolite es suficiente, pero hasta donde sé no tiene interface web. Redis? Hmmmm no, gracias*.
Sobre el punto 4, es donde hay más trabajo de inicio, aunque igual es más cuestiones de logística lo que se necesitará*.
1.- Estoy segurísimo (sin datos) que los pocos colaboradores que se tienen en mnm es el mismo caso que muchos de los desarrollos de SL y que probablemente no cambiará mucho se pase a DVCs o no. ¿Se podría probar esa hipótesis?
2.- Con "abierta" me refiero a que no se tenga que estar suscrito al svn como (creo) funciona ahora o enviando parches*. Se puede usar "Integration Manager Workflow" o "Dictator and Lieutenants Workflow" [1], para seguir con inspección y arreglo que requieres.
3.- No lo pongo en duda.
4.- No es ningún problema, cuesta un poco de trabajo, sí. De hecho me estoy ofreciendo a ello.
5.- Tampoco lo puse en duda. (¿o si?)
Es necesario evaluar si da más problemas que soluciones. Pro: Facilita colaboración, Pegas: Requiere administrar más.
Es decir, si encontramos una forma que facilite la colaboración, que nos permita abandonar svn.meneame.net (que vaya mierda de sistema, al estar centralizado e ir por NFS es muy lento y consume recursos) por algo mejor tipo Github pero que no nos complique la gestión del día a día, perfecto. Lo pondremos en marcha.
De hecho comencé a analizarlo para intentar pasar svn.meneame.net a github, y me empecé a encontrar con las pegas de Git (las mismas, aunque a menor escala, que Facebook). Es lo que estoy buscando:
1. Que sea más sencillo y fiable de gestionar branches, por ejemplo.
2. Que facilite la colaboración/envío de parches.
3. Que sea navegable por web.
4. Pero lo fundamental: que al menos mantenga la simplicidad (y velocidad/eficiencia) actual para el test y despliegue.
1. No tenemos problemas de colaboración: en 8 años recibimos muy pocos parches, no hay comunidad de desarrolladores, ni siquiera de los que usan el código de Menéame (normal, son pocos).
2. El código que se ejecuta en Menéame no puede ser resultado de colaboración "abierta", tiene que pasar por mi inspección a fondo y arreglo (que a veces me lleva más trabajo).
3. Es muy sencillo abrir un nuevo directorio o usuario para colaboraciones concretas (como hicimos a veces con @crodas)
4. Nuestra prioridad es gestionar nuestro propio desarrollo (la inmensa mayoría es mío) y el despliegue, con el menor esfuerzo posible, y la menor probabilidad de cometer errores.
5. Es fácil exportar de svn, si hace falta.
Por esto sigo sin ver la ventaja de usar Git ni qué nos soluciona, sin embargo es más complejo de gestionar, nos mete más trabajo y probabilidades de cometer fallos en el día a día.
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).
@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.
@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:
Tenemos un repositorio central (que es muy cómodo) y deberemos seguir con uno igual.
Podemos hacer cambios locales, pero estos siempre van al central.
En los servidores tenemos dos directorios: el dev (testing) y el www (producción).
En dev se hacen las pruebas y modificaciones antes de pasar a producción, el dev se accede por NFS desde cada instancia web (son variables y autoescaladas) desde dev.meneame.net.
Para pasar a producción hacemos el update en www y estos ficheros se sincronizan -vía rsync- con las instancias (es automático, cuando cambia la fecha o modifica config.php o local.php).
Hacemos cambios pequeños en www (como número de versión, afecta a urls de ficheros estáticos) y también subimos eso al repositorio central (un simple commit en svn). Para poder hacer esto en git debemos tener el árbol completo, con un "bare" no se puede (AFAIK).
Es decir, no nos da ninguna ventaja importante, pero nos complica innecesariamente.
En él, el repositorio "sacred", es decir, el ofical de mnm tendría el control total de qué se modifica en ello, cada colaborador creará su repositorio y enviaría cambios (vía pull requests) basándose en issues públicos, o que se va encontrando uno paso a paso.
A mi parecer este modelo aplica para cualquier DVCS.
*Básicamente no entiendo para o por qué no tener toda la historia.
@esparta Estaba pensando a pasar a Git, y hablé hasta con @crodas, pero no es muy conveniente para nuestro caso. Para la parte de producción deberíamso poner un "bare" (para no tener toda la historia), pero con éste no se pueden hacer ni modificaciones sencillas (las hacemos, por ejemplo variables de configuración).
El Mercurial lo usé para el SpokenPic (y luego lo exporté a GitHub para publicarlo), me gustó mucho.
Feliz feliz en tu diaaaaaaaaaaaaaaaaaaaaaaaaa
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas y @Ganon
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas
github.com/gallir/Meneame/blob/a7776ed1c294e25779818f58ab246f8418e8e3e
Vamos, que si hay código "subcontratado"
Gracias a ambos.
O sea, ¿creo otro proyecto y luego lo inserto como submódulo en el subdirectorio? ¿Los commits y push los tengo que hacer por separado?
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas
El WebSVN es bueno, pero si actualmente sólo sirve para mostrar el código igual mejor tirarlo. El primer paso de un mirror en github es avance, y permitirá revisar igualmente la hipótesis de que no hay cambio en la colaboración.
1. No tocar el sistema actual.
2. Exportar periódicamente a un repositorio git o mercurial.
3. Subirlo a un sistema como Github.
4. Encontrar una forma sencilla de importar parches del otro repositorio al svn.
¿No lo ves posible?
Para self-hosting las dos opciones más maduras son GitLab y gitorius. Pero ambas tienen el detalle que son en ruby, y suelen ser bastante pesadas. En Efecto Tequila se tiene GitLab: git.efectotequila.com (nuestro benévolo dictador lo puso en marcha)
En los tres es relativamente sencillo poner los puntos 1 a 3, sobre todo el punto 2 y 3. La belleza de cualquiera de ellos es que se pone en contexto el problema, el código y la colaboración. Hay quieres creen que gitolite es suficiente, pero hasta donde sé no tiene interface web. Redis? Hmmmm no, gracias*.
Sobre el punto 4, es donde hay más trabajo de inicio, aunque igual es más cuestiones de logística lo que se necesitará*.
* a mi parecer
1.- Estoy segurísimo (sin datos) que los pocos colaboradores que se tienen en mnm es el mismo caso que muchos de los desarrollos de SL y que probablemente no cambiará mucho se pase a DVCs o no. ¿Se podría probar esa hipótesis?
2.- Con "abierta" me refiero a que no se tenga que estar suscrito al svn como (creo) funciona ahora o enviando parches*. Se puede usar "Integration Manager Workflow" o "Dictator and Lieutenants Workflow" [1], para seguir con inspección y arreglo que requieres.
3.- No lo pongo en duda.
4.- No es ningún problema, cuesta un poco de trabajo, sí. De hecho me estoy ofreciendo a ello.
5.- Tampoco lo puse en duda. (¿o si?)
Es necesario evaluar si da más problemas que soluciones. Pro: Facilita colaboración, Pegas: Requiere administrar más.
[1] www.git-scm.com/about/distributed
* ¿Cuántos "nuevos" saben hacer un patch? Es bien cómodo los pull-request, la verdá.
Es decir, si encontramos una forma que facilite la colaboración, que nos permita abandonar svn.meneame.net (que vaya mierda de sistema, al estar centralizado e ir por NFS es muy lento y consume recursos) por algo mejor tipo Github pero que no nos complique la gestión del día a día, perfecto. Lo pondremos en marcha.
De hecho comencé a analizarlo para intentar pasar svn.meneame.net a github, y me empecé a encontrar con las pegas de Git (las mismas, aunque a menor escala, que Facebook). Es lo que estoy buscando:
1. Que sea más sencillo y fiable de gestionar branches, por ejemplo.
2. Que facilite la colaboración/envío de parches.
3. Que sea navegable por web.
4. Pero lo fundamental: que al menos mantenga la simplicidad (y velocidad/eficiencia) actual para el test y despliegue.
Partes de premisas equivocadas:
1. No tenemos problemas de colaboración: en 8 años recibimos muy pocos parches, no hay comunidad de desarrolladores, ni siquiera de los que usan el código de Menéame (normal, son pocos).
2. El código que se ejecuta en Menéame no puede ser resultado de colaboración "abierta", tiene que pasar por mi inspección a fondo y arreglo (que a veces me lleva más trabajo).
3. Es muy sencillo abrir un nuevo directorio o usuario para colaboraciones concretas (como hicimos a veces con @crodas)
4. Nuestra prioridad es gestionar nuestro propio desarrollo (la inmensa mayoría es mío) y el despliegue, con el menor esfuerzo posible, y la menor probabilidad de cometer errores.
5. Es fácil exportar de svn, si hace falta.
Por esto sigo sin ver la ventaja de usar Git ni qué nos soluciona, sin embargo es más complejo de gestionar, nos mete más trabajo y probabilidades de cometer fallos en el día a día.
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]http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00005.html
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
Lo de versiones y caché, hace meses que ha cambiado, por ejemplo:
<script src="/v_9/js/main.js.php" type="text/javascript" charset="utf-8">
Tenemos un repositorio central (que es muy cómodo) y deberemos seguir con uno igual.
Podemos hacer cambios locales, pero estos siempre van al central.
En los servidores tenemos dos directorios: el dev (testing) y el www (producción).
En dev se hacen las pruebas y modificaciones antes de pasar a producción, el dev se accede por NFS desde cada instancia web (son variables y autoescaladas) desde dev.meneame.net.
Para pasar a producción hacemos el update en www y estos ficheros se sincronizan -vía rsync- con las instancias (es automático, cuando cambia la fecha o modifica config.php o local.php).
Hacemos cambios pequeños en www (como número de versión, afecta a urls de ficheros estáticos) y también subimos eso al repositorio central (un simple commit en svn). Para poder hacer esto en git debemos tener el árbol completo, con un "bare" no se puede (AFAIK).
Es decir, no nos da ninguna ventaja importante, pero nos complica innecesariamente.
www.atlassian.com/git/workflows#!workflow-forking
En él, el repositorio "sacred", es decir, el ofical de mnm tendría el control total de qué se modifica en ello, cada colaborador creará su repositorio y enviaría cambios (vía pull requests) basándose en issues públicos, o que se va encontrando uno paso a paso.
A mi parecer este modelo aplica para cualquier DVCS.
*Básicamente no entiendo para o por qué no tener toda la historia.
El Mercurial lo usé para el SpokenPic (y luego lo exporté a GitHub para publicarlo), me gustó mucho.
amiguito que el Cabal te bendigaaaaaaaaaaaaaaaaa
que no reine el spam en tu diaaaaaaaaaaaaaaaaaaa
y que menees mucho masssssssssssssssssss #felicitaciones
Bieeeeen, plas plas plas: Felicidades @crodas y @Ganon