@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).
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.
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.
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).
@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:
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).
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.
@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.
@esparta Yo que se, es que me sorprende, es algo que se puede ver en la wikipedia sin ningún esfuerzo, me provoca desconfianza en cuanto a la preparación de sus clases.
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?
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.
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.
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
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">
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
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.
El Mercurial lo usé para el SpokenPic (y luego lo exporté a GitHub para publicarlo), me gustó mucho.
Hay que ser cenutrios, eh.
suzumiyayuki.files.wordpress.com/2011/11/double-facepalm-picard-riker-
@espeangel luisangelaguilar.blogspot.com/2011/09/albacete-tambien-salio-la-calle-
@oraculus todoesposibleenmatrix.blogspot.com/2011/09/mi-primer-libro-mas-alla-de
www.meneame.net/rsss.php #blogs
@punch www.rusadas.com/2011/09/valentin-yanus-reportero-de-guerra.html
@PauGNU www.gnulinux.cat/2011/09/ubuntu-11-10-oneiric-ocelot-beta-2/
@esparta feedproxy.google.com/~r/esparta/~3/4MAOjdaN1R4/
www.meneame.net/rsss.php #blogs
www.meneame.net/rsss.php #blogs
www.meneame.net/rsss.php #blogs
www.meneame.net/rsss.php #blogs
@calopez feedproxy.google.com/~r/com/Gerp/~3/5YxnHZaawpc/
@Pontifex tetraedro.wordpress.com/2011/09/15/estereotipando-docentes/
www.meneame.net/rsss.php #blogs
www.meneame.net/rsss.php #blogs
www.meneame.net/rsss.php #blogs
www.meneame.net/rsss.php #blogs