Esta es la tercera y última parte de una serie que ha querido abordar el control de versiones JediVCS, con la sana intención de que quedaran lo mas claros posibles, algunos puntos que en mi opinión estaban un tanto confusos, sobretodo para las personas que se enfrentan por primera vez a este tipo de servicios. Una vez entiendes el funcionamiento lo ves tan obvio que piensas:
-¿Cómo he podido pensar de otra forma…?
Creo que debería empezar por comentar que es lo primero que pensé cuando decidimos hacer uso de un control de versiones. Uno piensa que lógicamente, el código se situa en algun servidor. Yo me imaginaba la escena mas o menos así:
El código fuente del proyecto se copiaba inicialmente a una carpeta del servidor (ese era el directorio de trabajo) y el servicio protegía el acceso a los ficheros físicos bloqueando el estado de lectura/escritura y comprometiendose como un semaforo para todos los usuarios que accedían a los módulos. En ese estatus, es facil pensar que el usuario, al hacer CheckOut estaba trayendose una copia local de un modulo concreto y al hacer CheckIn devolvía a ese directorio de trabajo los ficheros que habían sido comprometidos, sobrescribiendo los cambios. Al menos, yo tenía esa primera intuición sobre el trabajo en la red local, entre usuarios de un mismo equipo de trabajo y accediendo a un servidor global.
El problema reside en que algunos de los patrones comentados coinciden en parte. Coincide el funcionamiento de las dos funciones principales, que son CheckIn y CheckOut, coincide el efectivo uso real y la posibilidad de trabajar en un mismo equipo las dos partes básicas implicadas, que son el cliente y el servidor de JediVCS. Así que como Platón y su visión de las sombras, podemos ir elucubrando sobre un pilar falso conclusiones veraces que se cumplen solo de forma casual. Dicho en cristiano… montamos sobre una verdad aparente una teoria que no es cierta e intentamos descubrir como se accede a ella.
Así que lo primero que vamos a hacer es desmontar la teoria y para ello vais a hacer los siguiente: (enumeramos primero el supuesto y luego los puntos que hay que seguir)
* Tenemos dos equipos A y B.
* En el equipo A tenemos intalado el cliente de Jedi y Delphi. Además hemos creado la unidad virtual V: apuntando a la carpeta D:ProyectosTest. En dicha carpeta existe el codigo fuente que vamos a controlar mediante Jedi. El equipo A tiene la Ip 192.168.1.2.
* En el equipo B tenemos intalado el servidor de JediVCS. Su Ip es la 192.168.1.50. El servicio está en marcha y hemos habilitado nuestro firewall con los permisos necesarios para que permita el acceso al puerto. Tambien hemos creado el administrador del proyecto, que será Salvador, con derechos de acceso de nivel 3 (identificador de derechos segun el servicio de control para administradores de proyecto). Tambien hemos instalado el cliente de Jedi en el equipo B (pero esto es opcional). Igualmente hemos creado la unidad virtual V: pero esta vez apuntando a la carpeta física D:Repositorio_Jedi
Punto 1: Desde el entorno de Delphi en el equipo A, nos conectamos al servidor de Jedi del equipo Servidor (B), a través del usuario Salvador, que va a ser quien añada el nuevo proyecto que tiene el usuario alojado inicialmente en A, en la unidad V:. Esos pasos los pudimos ver en el video. En el pudimos ver cómo se creaba el proyecto y se añadian los módulos.
Punto 2: Hecho el punto 1, el equipo A, sigue conteniendo una copia local en V de los archivos del proyecto de Delphi. En el equipo B existe una copia archivada, que mantiene el servicio de JediVCS. Fisicamente no existen todavía los ficheros en B.
Punto 3: Desconectamos A de la red. El usuario del equipo A, se fue a tomarse una cerveza bien fría acompañada de unas almendritas y un ración de ensaladilla. 🙂 Es un usuario que sabe disfrutar de la vida. 🙂
Punto 4: Veamos que pasa con el equipo B… Conectamos el cliente de JediVCS. Nos hacemos pasar por Salvador y accedemos al proyecto. Vemos los modulos pero presentan un icono similar al de eliminados (una cruz roja tachada) que nos indica que no existen en el hipotetico directorio de trabajo V:. Efectivamente no existen. Sincronizamos los modulos y tras confirmar, ¡voila!, la unidad virtual se sincroniza con el servidor y recibe una copia local de la versión archivada de los ficheros.
Lo cual entra en conflicto con la idea original que teniamos en mente y nos desmonta la teoria…
Ahora deberíamos comprender que significa para JediVCS el directorio de trabajo y cómo resulta sencillo en el uso del proyecto compartido entre varios programadores con una única unidad virtual local. Cada programador trabajaría de esta forma localmente compartiendo una misma unidad virtual, que podría apuntar en cada uno de los desarrolladores a distintas carpetas locales. No obstante, ni siquiera esto es obligatorio y de ahí que nos recomienden no variar la unidad de destino, con el fin de que no podamos accidentalmente sobrescribir los cambios. Al principio, y debido a que no entendía el correcto funcionamiento del flujo de trabajo, no comprendía bien el sentido de Sincronizar, puesto que si partes de una premisa inicial erronea es realmente fácil aventurar deducciones falsas de la misma.
Como véis, el servicio de control de versiones es una buena idea incluso para un unico desarrollador que pretenda llevar un minimo control sobre el codigo fuente. Le permitiría mantener un comentario de los distintos cambios realizados de forma versionada, a cada nueva versión de los módulos. Le permitiría guardar distintar versiones del mismo proyecto, recuperarlas si no ha avanzado correctamente y necesita deshacer lo andado. Y le permite guardar de forma automática en el supuesto de que el servidor se aloje en un equipo distinto del de desarrollo de una copia de seguridad actualizada del codigo fuente, puesto que podría mantener una copia local en dicho equipo con la ultima versión física de los ficheros. Y por último, podría mantener un sistema de control de bugs o errores, ya que el mismo servicio cuenta con los apartados necesarios para la anotación y control de errores y tareas pendientes.
Existen otros controladores de versiones mas complejos. JediVCS se basa en el sistema de bloqueo de ficheros de forma que un modulo solo puede ser accedido por uno solo desarrollador. Todo depende un poco de que es lo que realmente necesite vuestro equipo de desarrollo. Si necesitais que simultaneamente accedan a un único módulo varios programadores, no os va a ayudar. Para ello existen otros servicios que sí que contemplan esta situación y que confrontan distintas versiones, que comparan y mezclan las versiones archivadas. Es otro enfoque que resuelve el problema.
En fin… un poco como resumen. Creo que es bueno plantearse el uso de cualquier control de versiones. Mucho mas si trabajan varios desarrolladores en el proyecto. Y en este caso además, es una opción gratuita. Puede ser un buen comienzo para valorar en un momento posterior otros VCS y decidir que mejoras nos aportan.
Espero que os haya podido servir de algo esta pequeña serie sobre JediVCS.
Delphi Básico 
Comentarios recientes