Habitualmente lo podemos conocer como Jedivcs y es un proyecto opensource que nos permitirá el control de versiones de nuestro código fuente. Muchos de vosotros podéis conocerlo; está basado si no recuerdo mal, en el originario de Thomas Hensles (FreeVCS ) y se ajusta a la licencia de Mozilla Public License Version 1.1. . Se aloja, como tantos proyectos libres en sourceforge.

http://jedivcs.sourceforge.net/index.html

En la sección de descarga de la web de jedivcs podéis en este momento descargar la ultima versión, que se corresponde con la JEDI VCS 2.43

No hace demasiado tiempo de la salida de esta última versión, ya que estamos hablando de Octubre del 2008, hace cinco meses. Podeis ampliar los detalles técnicos de las nuevas funcionalidades y correcciones que incorpora en la documentación (http://downloads.sourceforge.net/jedivcs/JVCS.2.43.ReleaseNotes.pdf?use_mirror=ovh). Pero bueno… creo que merece señalarse que ya permite la integración con Delphi/C++Builder 2009.

Hasta este punto se puede decir que hemos caminado sobre detalles bastante objetivos pero sabéis de sobra que el tipo de espacio que compartimos intenta llegar un poco mas lejos y en la medida de lo posible, y a riesgo de equivocarnos, estas entradas sirven para reflexionar, discutir o simplemente conversar. No voy a empezar la entrada diciendo si JediVCS es mejor o peor proyecto que otros existentes, mas evolucionados o mas complejos, porque existir existen y seguramente tambien existan razones para optar por unos o por otros. Mi idea al empezar a escribir estas lineas era simplemente contar un poco la peripecia que vivimos hasta que el sistema ha empezado a funcionar de forma optima.

Veamos… No siempre es necesario un sistema de control de versiones de la misma forma que tampoco es necesario hacer comentarios exhaustivos en las líneas de código. Depende de muchos factores pero creo que uno de los principales es la realidad de muchos programadores que trabajan como autónomos y que no siempre se trabaja en equipo y nos pierden las urgencias y la necesidad de entregar los proyectos. No me cabe la menor duda que a todos nos gusta que nuestro codigo este “exquisitamente comentado”, ordenado, con anotaciones de cambios, pero mi experiencia y la que he podido compartir con otros compañeros es que a menudo el mantenimiento del codigo fuente es uno de los primeros sacrificios que hacemos en aras de la supervivencia, de la rentabilidad. Ya.. ya se que no debería ser así pero la realidad es la que es. Supongo que existiran programadores metódicos que se rasgaran las vestiduras por estos comentarios pero yo ya he dejado de escandalizarme por cosas mayores.

Ahora bien, no es de recibo abogar por actitudes que al final deterioran la calidad de nuestro trabajo, si no a corto plazo, sí a medio largo plazo, cuando el proyecto empieza a tomar cauces distintos y donde nos aseguraron que 2 + 2 eran 4, desean ahora que sean 6.

El caso es que yo habia escuchado hablar de este tema. Incluso recordaba haber comentado con un buen amigo y compañero de trabajo los detalles de la puesta en marcha de un CVS. Pero sin profundizar demasiado. Es decir. No tenía ni puta idea de como funcionaba y sabía mas o menos que me podía aportar pero no para tirar cohetes. Lo que pasa, y vuelvo al razonamiento inicial, cuando uno trabaja solo, como a mi me ocurría en ese momento tampoco me preocupaba demasiado. Hacía mis copias de seguridad. Intentaba que el codigo fuera lo más limpio posible, evitando ser rebuscado en los razonamientos y comentaba las lineas mas críticas de los módulos. Nada de florituras en cada procedimiento o función tipo:

//————————————————————————-
// Procedimiento: El procedimiento permite … etc etc…
//
// Parametros: … etc etc..
//
// Objetivos: …
//———————————-
procedure TForm1.MiProcedimiento(

Creo que me entendéis.

En fin. Las situaciones cambian y desde que me incorporé a un empresa en la que desarrollo por cuenta ajena, y comparto el departamento con otro compañero, (somos tres programadores pero el tercer programador aborda la parte de la web y no participa de esta problemática), empezamos a vivir los problemas de convivencia respecto al código fuente. Y eso que eramos dos gatos y bien avenidos.

El principal problema que nace de esa convivencia es la posibilidad de sobrescribir accidentalmente los módulos de código. ¿Cuántos módulos puede tener un proyecto? ¿400? ¿500? La angustía de vivir en un ay:

-¿Estas modificando el codigo de este modulo, Manuel?
-Graba por favor que necesito hacer unos cambios.
-Espera que ahora no puedo…
-Me cago en la madre que ha parido a … (insultos varios) … que se me ha borrado las lineas que tenían.

Eso teniendo el codigo compartido en un servidor y accediendo los dos desde una unidad conectada. Si fuera el caso de que estuviera duplicado el codigo localmente todavía el peligro de sobrescribir algun módulo es mayor, salvo que inviertas en una pizarra grande y la cuelgues del techo, y allí escribas el nombre el modulo que vas a cambiar para que lo vea tu compañero.

En esas condiciones empezamos a hacer de sabuesos y dimos los primeros pasos para ver como solucionabamos el tema y fue así como apareció la palabra CVS en los pensamientos inmediatos de ambos. Pero…

(Primera reflexión que nos surgío)

¿Tenía nuestro entorno de delphi alguna característica que permitiera el control de versiones? (sin tener que soltar un duro)

Pues desgraciadamente, es un tema que no parece demasiado contemplado en las versiones de delphi (o al menos se deja para que otros desarrolladores y empresas lo solucionen). Esa reflexión os confieso que (me) resultaba un tanto inquietante en el sentido que dada la inversión que se hace en un entorno así, y sabiendo como se sabe que será utilizado por un equipo de programadores en condiciones normales, no se contemple que traiga ya incorporada esta caracteristica. Estos días estuve ojeando la demo un entorno como windev.com y cuando generas un proyecto ya le indicas si vas a trabajar tu solo o en equipo. Velneo, mi querido velneo, tambien contempla esa posibilidad y ya se ha tenido en cuenta durante el desarrollo de la V7, y sin embargo, Delphi, que hicieron ese tímido intento en la versión Borland Developer Studio 2006, incorporando el cliente de StarTeam, se lo llevó el viento… y nunca más se supo. No parece muy lógico que unas herramientas de desarrollo que se supone que van a ser utilizadas en equipo no profundicen en esos temas y mas aun, se evadan de ellos como quien no quiere la cosa.

Me gustaría decir que la llamada al representante español que como sabeis es Danysoft, nos aportó claridad en el asunto pero desgraciadamente no fue así. Y me duele decirlo porque siempre los he valorado muy positivamente pero en este caso, nos quedo la impresión de que ni siquiera a ellos fuera esta cuestión algo que habitualmente les demandaran. Eso sí nos indicaron el camino del Jedi (que la fuerza te acompañe Luke!!!), tras comprobar que los precios de un controlador de versiones como Starteam eran algo disparatados. Incluso nos liaron mas recomendandonos que hicieramos uso de un invento que nadie sabe para que sirve (seguro que los de borland si) que se llamaba repositorio compartido y que debía bloquear el acceso a módulos comunes. Lo cierto es que todavía no he averiguado que coño controla. Desde luego, para controlar versiones o trabajar en equipo parece que no… jejejeje

Empezamos a trabajar en el tema de evaluar JEDIVCS.

Tras proceder a la descarga, la instalación no resulta demasiado áspera. Siguiente, siguiente, siguiente y ya tienes el cliente. Siguiente, siguiente, siguiente y ya tienes el servidor. Quiero decir que no habian pegas o dudas pues son cuatro pantallazos. Quizás lo mas inquietante era si se intalaba el servicio embebido de firebird (nosotros elegimos el servicio sobre esta base de datos) o sobre el servidor de la version 1.5 que ya teníamos en funcionamiento. Al final elegimos el servidor y tras ejecutar un script de creación de la base de datos y configurar el servicio de Jedi para que apuntase al servidor de Firebird, nos quedaba solo instalar el servicio desde dicha configurador e iniciarlo. Y todo funcionó bien.

Os prometo que no os engaño, que lo que os acabo de contar hace algo así como 3 ó 4 meses. O quizás mas. La puesta en marcha fue un desastre porque a pesar de leer las indicaciones una y otra vez algo no funcionaba correctamente.

Veamos el documento de puesta en marcha:

How to start working
To become friendly with JEDI VCS we recommend to do the first steps with a less important ‘Dummy’ project. The Dummy project may be removed from the archive later without any problems.

As from V 2.0, JEDI VCS is based on a Client/Server architecture, connecting client & server via TCP/IP protocol.
Due to this you MUST install the TCP/IP network protocol on your machine, no matter whether client & server are located on different or on the same machine.
Step by step:
· Close Delphi / C++ Builder.
· Install JEDI VCS (as described in Installation ).
· Restart Delphi / C++ Builder. (Close Delphi / C++ Builder and check the registry value if the error ‘VCSManager not found’ appears.)

Hasta aquí fue seguido al dedillo. Sin problemas.

· Set the options and paths under Properties .
We recommend to make the Backup function active (page Backup/Log). (Default = off.)
Sharing the archives over a network requires additional configuration settings!
· Open an existing project, project group or package (or create a new and save it under a unique name – Remember that ‘Project1.dpr’ or ‘Package1.dpk’ are not valid project names JEDI VCS!).
In the IDE expert version, a new created Delphi / C++ Builder project (IDE|File|New Project) must be saved under a valid name, before it can be added to the archive. You must reopen the project so that JEDI VCS can recognize it as a new project (JEDI VCS watches the project Open-Close events in the IDE).

Esta parte es mas o menos sencilla pero para quien no ha trabajado nunca con este sistema de trabajo puede suponer o imaginar cosas que no sean correctas. Lo habitual sería abrir el cliente del Jedi en nuestra versión de Delphi y al reconocer nuestro proyecto actual, cargado ya en el IDE, nos pida crear el proyecto de control de versiones, que habitualmente coincidiría en nombre con el de nuestro proyecto. Así que eso precisamente fue lo que hicimos. Con el desarrollo alojado en el servidor principal, accedimos a la unidad conectada y eso, tras abrir el cliente de JediCVS, nos hizo dar los primeros pasos, creandose el proyecto e insertando en el mismo todos los módulos que contenía.

Nos saltamos varios párrafos y llegamos a:

..· If your changes have not the expected results there are two ways to get back the original state:
1. Select ‘Check Out’ again in Project manager and create a copy (select ‘Check Out & confirm the question ‘Overwrite…?’ with yes) of the saved module (UnCheck Out). JEDI VCS will restore the old state of the module (the module is still checked out and locked for other developers).
2. Select ‘Undo Check Out’ in Project manager. JEDI VCS will restore the old state of the module and unlock the module in the version archive (the module is checked in and everything is back as it was before).
Remember that any changes to the module on disk will be lost!
· If you have done (and tested) your work re-check in the module[s] and other users can ‘ Synchronize ‘ their working directories to the current development state.
· Get is an other way to get the most actual version of a module from the archive.

Es decir, teníamos un proyecto y unos módulos ya dentro del jedi y el sentido común, nos indicaba que estos dos comandos, check out y check in, iban a ser la base de nuestro trabajo. Check in, representaba a los modulos archivados y Check Out, aquellos que se sacaban para ser modificados por el usuario del equipo.

Y aunque aparentemente era todo correcto, algo no funcionaba bien. Si yo bloqueaba un módulo y hacia check out sobre el mismo, mi compañero seguía viendo los cambios que yo había hecho y cuando compilaba la aplicación los detectaba.

-Raro, ¿no?… -nos deciamos Manuel y yo-

Es decir, se hablaba de un puñetero workingdirectory, pero en la configuración de las opciones del cliente solo aparecía un directorio temporal. Por un lado no te recomendaba alterar la ruta o destino del check out y sin embargo el efecto de no hacerlo solo se traducía en el bloqueo de lectura y localmente no se creaba ningun archivo.

Sinceramente y resumiendo un poco, esa primera experiencia duró un par de semanas, hasta que accidentalmente sobrescribí el codigo de toda una tarde de trabajo, al hacer un syncronize, que me llevo a una angustia vital y a maldecir a todo bicho viviente. Ese día, cabreado por la situación acabé desinstanlando todo lo que había instalado, y mandando (y pido perdón por la expresión) a la mierda mis buenas intenciones de introducir el control de versiones. En el manual del JediVCS creo que faltaban explicar algunos puntos claves que se pasa así como si se sobre-entendieran y si no se ha trabajado nunca con estos artilugios puedes cagarla.

Ese:

Sharing the archives over a network requires additional configuration settings!

No puede pasar tan inadvertido.

La historia es que probamos varios CVS, como TeamCoherence y alguno mas, que se integraba en el ide pero cansados de perder tiempo seguimos trabajando de forma precaria y nos olvidamos del tema durante un tiempo y seguimos trabajando a “voces”.

El viernes de la semana anterior, tras dos o tres dias en los que reintentamos con sana cabezonería que funcionara el control de versiones, finalmente descubrimos el problema, que realmente era por desconocimiento del funcionamiento de esta herramienta. En opinón de ambos, de Manuel y mia, la documentación habla de muchas cosas, bla, bla y bla pero da por supuesto algunos conceptos de esa puesta en marcha que no se desprenden lógicamente del contenido y se tocan asi como de pasada.

Esa es la primera parte de la entrada de hoy. En la siguiente vamos a ver que es lo que fallaba, mas que nada por si alguno de vosotros os encontrais en una situación similar y os rebanais la cabeza pensando en que estais haciendo mal. Ademas, se ha hecho tardisimo y hay que descansar.

Ahh … Solo decir una cosa antes de acabar. Una vez correctamente configurado JediVCS, estamos trabajando sin ningun problema, y es cuando uno descubre que incluso para situaciones en las que uno trabaja solo, o donde solo existe un programador accediendo al codigo puntualmente, es una buena idea su uso y recomendable cien por cien. Y si encima es gratuito(*), como es este caso, mejor aun.

(*) Aunque sean gratuitos es una buena práctica hacer una donación de cuando en cuando a este tipo de proyectos… por agradecimiento… o si se prefiere por el egoismo de que puedan pervivir.