¡¡ Por fin tenemos nuestro primer proyecto migrado a subversion !!.
La historia ha sido una verdadera odisea. Normalmente usamos CVS, pero en el momento de empezar a trabajar con ramas un poco en serio, el tema se hacía demasiado pesado. CVS crea las ramas recorriendo todos los ficheros del repositorio y marcando la rama para cada uno de ellos. Crear una rama en CVS tardaba cerca de media hora en cada proyecto implicado. Subversion, al tener todo el repositorio con un número de versión único, no necesita recorrer todos los ficheros uno a uno para hacer la rama, le basta con marcar en algún sitio que en ese número de versión comienza una rama. Tarda como la mitad de medio segundo (es un decir) en hacer la rama de un repositorio, independientemente de la cantidad de ficheros que haya almacenados.
Por otro lado, nuestro servidor de CVS se estaba quedando "viejito". Una estación solaris del año del "catapúm" con 128 megas de ram (al que hace poco se le estropeo un módulo de 64 y creo que de esos ya no hay ni el rastro), con el disco duro (de pocos gigas) permanentemente al 99%. Total, que se imponía también un cambio de máquina.
Así que aprovechando lo uno con lo otro, decidí que nos pasabamos a Subversion en un servidor nuevo. Dicho….. y a esperar.
Primero convencer a la gente de las excelencias de Subversion sobre CVS. Como siempre, a unos pocos les parece estupendo, a muchos les importa tres pepinos y a algunos lo de "¿Para qué vamos a cambiar si ahora funciona?". A base de dar la paliza, conseguí convencer (o al menos dejaron de protestar) a todos.
Después lo de conseguir el servidor nuevo. Ni el departamento ni los proyectos para los que trabajamos estaban dispuestos a comprar un servidor (pensé seriamente en ir a tomar los cafés encima del servidor actual, para que ocurriera "una desgracia"). Así que a negociar con el departamento de informática de la empresa, a ver cuánto nos cobran por darnos un subversion en uno de sus servidores. Tras mucho tira y afloja (y sobre todo gracias a la persona que nos hizo de intermediaria en la software lab con la que trabajamos), nos dieron el subversion gratis. Entre pedir el servidor a los proyectos, intentar convencerles y hablar con el departamento de informática pasaron casi dos meses.
Y hoy, por fin, la primera migración. Me bajé el cvs2svn e intenté migrar uno de nuestros proyectos. Desgraciadamente, intenté hacerlo sobre windows y no hubo manera. Tenía el cygwin y teóricamente todo lo necesario, pero me fallaba en un punto en el que se hace una llamada al comando "sort". El de windows no vale, porque funciona distinto del de unix. El de cygwin aparentemente me daba problemas porque se liaba con las \ de los directorios (al ser unix, espera / de directorio). Me bajé los UnxUtils, pero al ejecutar el comando sort daba un error muy raro (insuficiente espacio en disco, o algo así, habiendo más de 20 Gigas libres). Así que reinicié el ordenador para arrancar en linux y ahí fue todo rodado a la primera.
Total, ya tenemos nuestro primer proyecto en subversion. El primero de una larga lista de ellos que debemos ir migrando poco a poco.
¡Pero si svn es de la anterior generación de controles de versiones! Ahora hay que migrar a git, mercurial, bazaar,…
No, si ya me gustaría a mí, pero los he descartado por varias razones.
– No tienen tanto soporte para los IDEs que usamos (eclipse e Idea). Sí, existen plugins, pero todavía no están del todo completos. El plugin de git para eclipse, por ejemplo, está en la versión 0.x.x
– Git no está plenamente soportado en Windows (sí, hay cosas como msysgit)
– La gente ya se lía con una rama que hacemos de vez en cuando con cvs, como para que trabajen cada uno en su propio repositorio y tengan que hacer branches y merges con frecuencia.
– En principio no necesitamos un sistema de control de versiones distribuido. Quizás si empezáramos a usarlo y la gente lo cogiera en general con más cariño, acabaríamos sacandole provecho, pero como comento en el post, a la mayoría le da igual so que arre y algunos están por sistema en contra de cualquier cambio.
Eso no quita para que yo use Bazaar en secreto, creando mis propias ramas locales a gusto 😉
Se bueno.
Buena entrada, se echan de menos entradas en castellano que tengan tanto de practica y realidad como teoria.
Jeje. Sobre los IDEs y el soporte de git en windows tienes razón. Pero lo de crear una rama, es mucho más fácil en cualquier control de versiones distribuido que en CVS o SVN.
Si una herramienta es realmente útil usarla en consola es tu vcs. Si todo lo que hago con git, o antes svn, lo tuviese que hacer dentro de eclipse sería todo un martirio (directamente no lo haría).
Al final, la gente que usa vcs dentro de un IDE, lo usan como un save all. Guardo todo y commit al servidor, como si fuese una copia de seguridad o algo así. Eso no es forma de usar un vcs.
Hola blaxter.
Estoy de acuerdo contigo en que la línea de comandos permite hacer muchas cosas que no permite hacer el ide, de hecho, yo también uso mucho la línea de comandos y con este cambio a subversion, lo primero que hice fue instalarme un cliente con línea de comandos antes que el plugin de eclipse, para hacer mis pruebas a gusto.
Pero no estoy de acuerdo en que el que usa el ide lo use como un «save all». Eso depende más de la persona que de la herramienta. El que hace «save all» desde el ide, lo va a hacer también desde la línea de comandos, y el que es cuidadoso con la línea de comandos, lo será también desde el ide. En general, las herramientas ayudan (o lo intentan), pero el hacer bien o mal las cosas depende más de la persona que de la herramienta.
Sin embargo, hay una cosa que sí es cierta: las personas a las que gusta pelearse con la línea de comandos (usen o no el ide también), suelen ser gente más inquieta y con más conocimientos. Pero si prohibes usar el ide y obligas a usar línea de comandos, tendrás a los pasotas del ide haciendo «save all» desde línea de comandos.
Se bueno.
Pingback: Diario de Programación » Blog Archive » CVS no vale para proyecto grandes
>>> No, si ya me gustaría a mí, pero los he descartado por varias razones.
>>>
>>> – No tienen tanto soporte para los IDEs que usamos (eclipse e Idea). Sí, existen plugins,
>>> pero todavía no están del todo completos. El plugin de git para eclipse,
>>> por ejemplo, está en la versión 0.x.x
Creo que había algo de esto para Mercurial …
>>> – Git no está plenamente soportado en Windows (sí, hay cosas como msysgit)
A diferencia de Mercurial que tiene hasta un cliente integrado con el shell (a.k.a. TortoiseHg) y otros más sofisticados para extensiones más sofisticadas como MQ
>>> – La gente ya se lía con una rama que hacemos de vez en cuando con cvs, como para que
>>> trabajen cada uno en su propio repositorio y tengan que hacer branches y merges
>>> con frecuencia.
El salto desde CVS hacia SVN es realmente considerable, pero al final en los viejos tiempos siempre terminé por utilizar algo como SVK y ahora Hg. Por si llega el momento y la decisión es migrar hacia Hg, aquí redacté un pequeño tutorial sobre ¿Cómo migrar desde Subversion (SVN) hacia Mercurial con Hgsvn? ;o) .
>>> Eso no quita para que yo use Bazaar en secreto, creando mis propias ramas locales a gusto
Ya lo veía venir :o) … ¿tendrá bzr algo como MQ?