Control de versiones para PACO

[Franco Bulgarelli]

Buenas!

La semana pasada charlabamos con Nico sobre revivir la cuestión de revisar si SVN es hoy la mejor herramienta de control de versiones para nuestros ejemplos. 

La última vez que lo charlamos dijimos de mantener el statu quo, pero capaz fue una decisión apresurada (básicamente porque no nos poníamos de acuerdo sobre la forma de estructurar nuestro repositorio en algo del estilo git/hg, y porque eran las 6 de la tarde de un sábado en Medrano :P). 

Entonces, la idea es charlar esto con más tiempo. Las preguntas disparadoras son:

  1. ¿El SVN nos alcanza? ¿Queremos cambiar? ¿Porqué sí, porqué no?

  2. Si quisieramos cambiar, ¿estaríamos de acuerdo en movernos a una herramienta descentralizada?

  3. Suponiendo el uso de una herramienta como git/hg, ¿cómo estructuraríamos nuestro repositorio de ejemplos?

  4. ¿Nos molestaría tener un repositorio (u organización) específica para PACO? 

Personalmente, yo pienso que 

   1 y 2. No, yo quisiera cambiar. SVN en sus días fue la maravilla comparada con CVS, hoy después de usar git durante algunos años, la encuentro lenta y tosca. Y eso por fuera de que he trabajado bajo los modelos centralizado puro y decentralizado (híbrido, porque siempre existe un repositorio y rama principial, y ojo con divergir mucho de esta porque se pude todo), y el segundo me resulta  mucho más conveniente.  

   Cosas que me parecen fundamentales de estas herramientas:

   * Historia limpia. Dadas las herramientas de ammend y rebase que tienen, la historia resultante queda limpia y trazable (obvio, si lo usas adecuadamente). 

   * Si el repositorio central se cae (porque por ejemplo, te hacen la gran assembla), replicar el repositorio en otro servidor es trivial. 

   * Poder comitear sin conexion internet es algo que me ha salvado infinidad de veces, incluso preparando clases. 

  * Comitear es gratis, pushear a una rama también, incluso pushear o mershear a master (la rama principal, el trunk de SVN) es una operación simple y rápida. Esto fomenta a que la gente comitee más. Y eso me parece bueno. 

  * Sitios que se paran encima de git o hg como BitBucket o Github tienen un soporte interesante para pull-request, y si querés trabajar con otro esto es excelente porque podés pedir una segunda opinión antes de mergearlo. 

 Esto no resulta útil cuando uno trabaja completamente solo, ahí el modelo de SVN de comitea al trunk y después vemos es mejor, pero acá es lo mismo: si querés comitear y pushear derecho contra master podés. Está en vos ver cuando querés hacer "master derecho" o aplicar el modelo de branching (personalmente en el laburo el modelo de feature branch es mi default, pero acá sería mas relajado)  

  * Si usaramos github (no seé BitBucket), pedir cuenta educativa es trivial, lo que nos da muchos repositorios privados y sinfinin de públicos. Esto es MUY útil cuando por ejemplo hacemos los parciales de TADP, en los que Demian, Pablo y/o yo queremos hacer pruebas de concepto de nuestros enunciados, y queremos que sean privados (por motivos obvios). 

  Esto también nos libraría del problema de depender de un SVN hosteado por nosotros. Hoy en día, este está caido y no lo podemos usar, y XP-dev es público. 

 * Una boludez: estos sitios en general tienen sistemas de notificaciones por los cuales te avisan cuando en un repositorio cambia algo o alguien quiere revisar algo. A mí al menos me interesa esto, que elimina burocracia y ahorra los típicos mails del estilo "hola, cambié algo"

3. Ahora, todas no son malas con SVN. Los puntos fuertes que tiene el SVN son: 

  * Podés tener una estructura jerárquica. La estructura de Git/HG es plana, donde tenés un repositorio por cada proyecto (acá sería por cada ejemplo). Esto en general se resuelve con:

    * Una organización:  es un conjunto de repositorios. Por ejemplo, podríamos tener paco, uqbar-paco o algo así. 

    * una convención de nombres. Por ejemplo, un ejercicio sobre metaprogramación se podría llamar meta-<nombre-del-proyecto>

    Yo sé que esto puede sonar a herejía, pero a mí me suele ser más fácil encontrar cosas buscandolas por nombre en el buscador de github que siguiendo la jerarquía de directorios de SVN que a veces lleva a ambigüedades. 

 * Poder bajarse todos los ejemplos juntos. No hay una forma nativa. Acá entiendo que con scripts se puede lograr (conozco varios que lo hacen, puedo aprender más al respecto). También entiendo que existen los submódulos, pero no tengo experiencia con esto. 

  * Permisos: SVN tiene permisos para todo el repo, que es único. Acá tenés multiples repositorios, pero podés darle permisos a los miembros de paco, con lo que lográs los mismos resultados. 

4. Creo que no. 

En fin, escucho sus comentarios. 

[Nicolas Passerini]

Antes que nada, yo les cuento mi postura: hay que migrar, sí o sí. Hace algunas semanas cuando discutimos esto en una reunión, yo me quedé dudando, pesamos las ventajas de svn y decidimos seguir usándolo para las cuestiones docentes. En este poquito tiempo me terminé de convencer de lo que ya sospechaba ese día y es que continuar usando svn no es una opción. Así que mi voto es que 

- paco migre ya mismo

- diseño debería tener en mente que va a seguir el mismo destino más temprano que tarde

- esta discusión no se debería orientar a discutir si es mejor svn o git sino asumir que ya migramos y en todo caso ver cómo (a) aprovechamos las ventajas de la nueva herramienta y (b) mitigamos las ventajas de la vieja que se perdieron.

Con respecto a las ventajas de la nueva herramienta estoy 100% con Franco. Una sola aclaración quiero hacer y es que me da miedo que la gente "dé vueltas" para commitear las cosas en el master. Creo que eso es contrario a la forma ágil en la que venimos laburando y que podría ser algo negativo. 

Para mí les tenemos que inculcar a todos que por default el código es de todos y que si ves algo que está mal lo corrijas y lo publiques "en el master". El branch como herramienta de laburo me parece perfecto, mientras no se convierta en que los chicos nuevos tienen miedo de cambiar lo que hicimos los más viejos y entonces hacen un branch y commitean ahí y queda medio escondido.

Luego puede haber situaciones donde los branches son sumamente útiles, si uno realmente hace un cambio del que no está seguro (para poder charlarlo con otro antes de mergear) o si uno quiere tener muchas versiones de lo mismo porque conviene mostrar distintas formas de hacerlo (aunque no estoy seguro de si el branch es la mejor herramienta para eso). Pero eso no debería querer que terminemos (como veo en algunos proyectos) que muchas cosas ocurren en los branches y que el pasaje del branch al master es lento, vueltero o burocrático o que sólo lo pueden hacer algunos elegidos.

Sí está bueno tener una versión más burocrática del brancheo para permitir que (por ejemplo) gente ajena al arena nos mande pull requests, eso está bueno para un proyecto open source, para permitir la participación de gente externa al proyecto. Pero no está bueno para un grupo colaborativo de trabajo.

Con respecto a las ventajas del svn... vamos por partes.

a) Estructura jerárquica... no hay mucho para hablar, se perdió.

A ver, como yo lo veo, el objetivo de la estructura no es encontrar más fácil UN ejemplo. Si yo sé lo que busco, coincido en que es más fácil buscar por nombre. Lo que me da la estructura jerárquica es una forma fácil de ver todos los proyectos de metaprogramación o todos los proyectos de scala.

Si tenemos un buen buscador, tal vez eso pueda resolverse. Una pregunta que me hago es si es posible agregarle "tags" o algo similar a un proyecto, de forma de por ejemplo indicar en qué lenguaje está hecho. Eso podría ser incluso superior a la estructura jerárquica. Y si no se buscará por nombre.

La convención de nombres ya la tenemos, es cuestión de asegurarse de respetarla en cada caso.

Creo que el nuevo esquema va a exigir que seamos más ordenados, pero no es inviable. La principal duda que me da, es qué pasa con proyectos que uno crea y quedan por ahí, que por ahí después no se usan. Y lo que pasa es que da pena borrarlos, pero tampoco está bueno tener infinitos proyectos que se usaron alguna vez y que lo más probable es que no los vuelva a usar.

Otra cosa que creo es que va a ser importante que el site sirva como directorio para poder encontrar los proyectos.

b) Checkoutear muchos proyectos a la vez

Se puede hacer con scripts o con submódulos.

Los scripts podrían estar en el site.

c) Permisos.

A mí me parece que tener una administración de permisos por proyecto es burocrático y es la receta para que me olvide de darle permisos a uno en un proyecto, no puede commitear y hace que busque otra forma de hacer las cosas.

Entonces tendría una política en la que todos los paqueros pueden commitear en todos los repos de la organización y listo.

La pregunta que me hago es si las cosas privadas (enunciados, etc) pueden estar todas en un mismo repo o si también vamos a necesitar muchos repos para eso.

Si fuera un mismo repo, tal vez ese podría ser el único privado y los demás todos públicos (asumiendo que puedo tener ese tipo de defaults).

Si no, mi propuesta es tener dos organizaciones: paco-examples y paco-private (o los nombres que quieran) y manejar permisos a nivel de organización.

2013/7/30 Franco Bulgarelli <flbulg...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "paco-docentes" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a paco-docente...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Javier Fernandes]

Estoy de acuerdo, creo.
Bah.. estoy investigando GIT por estos días, más profúndamente, y me gustaría empezar a usarlo de verdad. Así que sí.

Por otro lado, entre las licencias académicas que conseguí de atlassian el otro día, está la de Stash que creo que sirve justamente para administrar repo's grupos de personas, etc.
Capaz podríamos aplicar una de esas para uqbar ?
Pasa que creo que son medios putos, hay que mostrar un site, y algún proyecto opensource o algo.

Digo.. así, como para mediano/largo plazo.

2013/7/30 Nicolas Passerini <npass...@gmail.com>

[Franco Bulgarelli]

Algo así?

https://github.com/programacionhm? 

(No saqué paco porque ya está tomado. Otra opción sería renombrar a uqbar-paco, si no nos molesta que uqbar figure en el nombre de la materia; a mí personalmente no me jode)

[Franco Bulgarelli]

PD: Si me dan el OK, le meto el loguito de uqbar y pido que nos den repos privados por ser organización educativa. 

[Nicolas Passerini]

Si a nadie le jode a mí me gusta uqbar-paco antes que programación hm, no sé.

Lo de los repos privados, para adelante sin dudas.

2013/9/8 Franco Bulgarelli <flbulg...@gmail.com>

[Pablo de Haro]

A mí me es indistinto, pero avísenme cuando esté tomada la decisión final que empiezo a subir cosas.

Saludos!

Pablo de Haro

2013/9/8 Nicolas Passerini <npass...@gmail.com>

[Franco Bulgarelli]

Bueno, ahí quedó: 

https://github.com/organizations/uqbar-paco

Los agregé como owners a los Nico's y PabloDH, porque tenía sus usuarios de github. Si me pasan el resto de sus usuarios, los agrego

[Demian Alonso]

Complete la planilla, pero mi usuario es demianalonso en ambas.

2013/9/9 Franco Bulgarelli <flbulg...@gmail.com>

--
Demian P. Alonso (demian...@gmail.com)
-- A conclusion is simply the place where someone got tired of thinking.

[Franco Bulgarelli]

Listo. Renombrado a uqbar-paco. 

[Franco Bulgarelli]

PD1: ya pedí los repos privados

PD2: tenemos que poner una convención de nombres para los proyectos. Yo propongo <tema>-<nombre>, y que no haga referencia a la materia. ¿Que opinan?

[Nicolas Passerini]

2013/9/9 Franco Bulgarelli <flbulg...@gmail.com>

PD1: ya pedí los repos privados

Excelente. 

PD2: tenemos que poner una convención de nombres para los proyectos.

+1 

Yo propongo <tema>-<nombre>, y que no haga referencia a la materia. ¿Que opinan?

No sé si a ustedes les pasa pero yo tengo muchos casos de ejemplos que están repetidos en varios lenguajes para poder comparar. En esos casos convendría agregar el lenguaje a la convención, como hacemos en diseño.

[Franco Bulgarelli]

Tenés razón. <tema>-<nombre>-<lenguaje>, en snake-case?

[Franco Bulgarelli]

PD: ya nos dieron repos privados. 

[Nicolas Passerini]

Excelente!

2013/9/24 Franco Bulgarelli <flbulg...@gmail.com>

[Demian Alonso]

A la mañana cree un repo para poner todo lo que son parciales, finales, tps, enunciados y cosas que deberían ser privadas. Me parece que lo más útil es que pongamos lo de todas las materias en el mismo repo, así es más fácil "prestarnos" las cosas :)

Y subí todo lo que teníamos en el svn de tadp dentro de la carpeta tadp.

El repo es: https://github.com/uqbar-paco/documentos

2013/9/24 Nicolas Passerini <npass...@gmail.com>

[Nicolas Passerini]

Capo!

Carlos: acá tenemos un repo para guardar cosas de Obj3.

2013/9/27 Demian Alonso <demian...@gmail.com>