Mostrando entradas con la etiqueta control de versiones. Mostrar todas las entradas
Mostrando entradas con la etiqueta control de versiones. Mostrar todas las entradas

viernes, octubre 10, 2014

PlasticSCM: Qué es el Cherry Pick y cómo se usa

Por: Fernando D. Bozzo

El Cherry Pick, que se traduce como "selección de cerezas", es una operación que permite seleccionar solamente los cambios de una rama o changeset, sin incorporar todo el resto de archivos heredados.

En otras palabras, si un changeset o rama tiene 2 archivos nuevos, pero ya existían 10 archivos previamente, el cherry pick permite seleccionar los 2 archivos nuevos, y no todos los archivos que ya existían, como haría el merge.



Ejemplo 1 - Cherry pick de un changeset



Supongamos que tenemos la rama-1 de la imagen, con 3 changesets (3, 4 y 5):



Y que en cada changeset hemos ido agregando un archivo de texto, archivo1.txt en el changeset 3, archivo2.txt en el changeset 4 y archivo3.txt en el changeset 5, como vemos en la siguiente lista (columna derecha):



Si quisiéramos pasar el contenido del changeset 5 (donde se agregó el archivo3.txt) de la rama-1 a la rama-2, que ahora está vacía, normalmente seleccionaríamos el cs:5 y luego "merge desde este changeset" en el menú, pero en este caso el merge mostraría lo siguiente:



Como vemos, nos trae no solo lo del changeset 5 (cs:5), sino todos los archivos heredados de las operaciones anteriores.

Para resolver este caso, lo que podemos hacer es un Cherry Pick para seleccionar exclusivamente el contenido del changeset elegido, pero sin incluir lo heredado, para lo que seleccionando el cs:5 elegimos en el menú del click-derecho la opción "Cherry pick de este changeset", lo que mostrará lo siguiente:



Con esto ya tenemos los cambios de ese changeset particular y el explorador de ramas mostrará el cherry pick con una línea violeta:





Ejemplo 2 - Cherry pick de una rama


Lo mismo que pasó antes con los archivos de un changeset, se aplica a los archivos de una rama (que es la suma de todos sus changesets), por lo que al realizar un Cherry pick de una rama, estaremos pasando al destino todos los archivos modificados en esa rama, indistintamente de si se modificó en el primer o último changeset, pero sin heredar todos los archivos anteriores a la misma.

Para hacer un cherry pick de una rama, el intervalo se selecciona eligiendo el changeset anterior a la rama y el último de la rama (intervalo abierto-cerrado):





Ejemplo 3 - Cherry pick para restaurar un changeset quitado con un merge sustractivo


Supongamos que hicimos un merge sustractivo para quitar de una rama los cambios hechos en el mismo, porque había un error que requerirá tiempo para corregir, pero se quiere poder seguir trabajando con el resto de cambios.

Usando el primer ejemplo, si quisiéramos quitar el changeset 4 que contenía el archivo2.txt, haríamos click-derecho en ese changeset, seleccionamos "Merge avanzado" y luego "Merge sustractivo del changeset...", lo que mostraría lo siguiente:




Y una vez hecho el checkin, se reflejaría en el diagrama de ramas con una línea roja:



Si exploráramos el repositorio en el nuevo changeset, comprobaríamos que el archivo2.txt se quitó:



Si quisiéramos volver a incorporar los cambios de ese changeset, entonces tendríamos que seleccionar "Cherry pick de este changeset", lo que mostraría lo siguiente:




¿Pero por qué no muestra el archivo de antes? Porque Plastic lleva la cuenta de las operciones que hemos realizado antes, y como ya le hemos indicado que no queríamos ese archivo y tampoco hay nada nuevo que agregar, entonces no muestra nada para hacer.

Para forzar a Plastic a que incluya los cambios de ese changeset, debemos indicarle que no tenga en cuenta las operaciones anteriores, lo que se hace eligiendo el botón inferior "Opciones de merge..." y luego marcando la opción "Ignorar merge tracking":




Y ahora sí, mostrará el archivo que queríamos recuperar:




Al finalizar el checkin, en el diagrama de ramas veremos una línea violeta:



Y explorando los archivos en ese changeset, ya veremos todos los archivos nuevamente:





Ejemplo 4 - Cherry pick para restaurar una rama quitada con un merge sustractivo


Este caso es como el anterior, pero cambia la forma de seleccionar el intervalo (abierto-cerrado).

Así como para hacer un merge sustractivo de una rama se debe seleccionar el changeset anterior a la rama (1) y el último changeset de la rama (2) (intervalo rojo difuso):




Para hacer un cherry pick de una rama, el intervalo se selecciona de igual forma (intervalo violeta difuso):




Y al igual que en el Ejemplo 3, cuando el cherry pick se hace para restaurar algo que anteriormente fue quitado total o parcialmente, no hay que olvidar elegir "Opciones de merge.." y marcar la opción "Ignorar merge tracking"




Resumen



Como hemos visto, el Cherry Pick es muy útil en varias situaciones, permitiendo realizar una selección puntual para una operación precisa.

En varios casos puede reemplazar al Merge normal, y en situaciones donde el merge sea demasiado complicado y muestre los bloques de código a mezclar muy "desordenados", vale la pena probar con el Cherry Pick, cuyo algoritmo de merge puede mostrar esos mismo bloques más fáciles de mezclar.

La única particularidad que se debe recordar, es que si hubo una merge sustractivo anterior, se debe marcar la opción "Ignorar merge tracking" en las opciones del merge, y así evitaremos no solamente la situación de no ver ningún archivo, sino que además permitirá resolver un merge que requiera intervención manual, de una forma más óptima y clara.


Hasta el próximo artículo! :D

domingo, septiembre 14, 2014

PlasticSCM: Cómo configurar la replicación entre repositorios Plastic locales y remotos

Por: Fernando D. Bozzo


[05/06/2015 - Actualizado con nuevo apartado de Exportación e Importación manual]

Suena complicado el título, como algo de la NASA, pero realmente no lo es.

En resumen: En Plastic, la "replicación" se refiere a la sincronización entre 2 repositorios, que es lo mismo que sincronizar 2 bases de datos, donde todos los datos nuevos que se han agregado en una de ellas se pasan a la otra, y viceversa, para lograr que ambas tengan lo mismo.

Estas bases de datos pueden ser locales, remotas o mezcla de ambas. En el caso de un repositorio remoto, puede ser tanto la PC o Portátil de al lado, como un servidor en otra planta o en otro edificio o ciudad.



¿Qué diferencia hay entre usar la Replicación y no usarla?


La replicación es simplemente una redundancia de repositorios, una forma de tener más de una copia de lo mismo y en ciertos casos es la única forma de poder trabajar con otras personas. Por ejemplo, cuando se trabaja con un Portátil que se puede llevar al cliente, y no se disponga de una conexión al repositorio principal (obviamente, siempre que el Portátil no sea el repositorio principal), entonces se hace necesario trabajar offline, o sea, con un repositorio local para poder ir protegiendo los cambios y mantener un historial de los cambios, que más tarde se sincronizarán con el repositorio central, que está en una PC de casa o de la oficina.

En el caso de no usar replicación de repositorios, se estará usando un único repositorio siempre, que estará todo el tiempo actualizado con lo último y no requerirá ninguna sincronización. Siempre estará la posibilidad abierta para crear otro repositorio en otro PC y hacer replicación.

Ahora, centrándonos en las diferencias, más allá de la sincronización en sí, la única diferencia notable es respecto de la eliminación de changesets, ya que si necesitamos eliminar un changeset o una rama por haberla creado mal, por ser innecesaria o por lo que sea, trabajando con un único repositorio esto es algo que se hace en un solo paso (se borra y listo), pero trabajando con replicación, se debe hacer esa eliminación en cada uno de los repositorios replicados, ya que si solo se hace en uno, al sincronizar se volverá a restablecer el/los changesets y ramas eliminadas, ya que los repositorios que tengan esa información se la pasarán a los que no la tengan.

Al final es algo simple de solucionar, pero es importante saber cómo funciona.



¿Qué ventaja tiene usar la Replicación?


La ventaja principal, es que con un par de clicks podemos hacer un "backup" en otro ordenador conectado a la red o a Internet, cosa que si a nuestro ordenador principal le pasa algo, al menos tenemos la tranquilidad de que tenemos una copia en otro ordenador, y es difícil que se estropeen 2 ordenadores a la vez.

A colación de esto, ¿recuerdan cuántas personas han aparecido en los foros diciendo que habían perdido todo o parte del trabajo (nada menos que los fuentes), y que sólo tenían, con suerte, un EXE para descompilar? ¿o los que se les ha estropeado algún binario (en general un form) con el que estuvo trabajando todo el día?

Espero que con lo fácil que es esto, ustedes no sean nunca esas personas, porque con esta facilidad que ofrece un DVCS y en varios casos sin coste (como este), ya no hay excusas. La comodidad es muy peligrosa en estos temas.




Configuración de una vista de sincronización


Veamos un ejemplo práctico de una replicación de un servidor Plastic local, por ejemplo, la PC o Portátil que usamos para desarrollar, y un servidor externo, que bien podría ser otro PC en la red o en Internet.

Nota: En mi caso, la PC local de trabajo es un Windows 7 virtualizado que llamé win7u, y el servidor es un PC físico con Ubuntu Linux llamado fer-desktop. En ambos casos, ustedes deben reemplazar los nombres de PC por los vuestros, así que las imágenes a continuación son orientativas. Para saber el nombre de vuestro PC, pueden abrir la ventana de comandos DOS, escribir SET <Enter> y ver una variable que dice COMPUTERNAME=NombreDeVuestroPC.



1) Lo primero es abrir la vista de Sincronización de repositorios, en el panel izquierdo, donde podemos observar 2 paneles verticales; el superior con los nombres de las "vistas" de conexiones y el de abajo con las conexiones de esa vista:




2) Luego añadimos una vista (de conexiones), que en este caso es una agrupación de una o más conexiones que se agruparán bajo un nombre identificativo a elección:




Una vez agregada la vista, ya aparece en la lista:




3) Ahora agregamos el origen de la conexión, que es el PC con el repositorio de origen, por ejemplo, nuestro PC o Portátil de trabajo (recordar, win7u es mi PC, ustedes pongan el suyo!):




 Una vez seleccionado el PC, el puerto y el repositorio, ya aparece el origen creado en la vista:




4) Ahora asociamos el destino de replicación, que puede ser otro repositorio en la misma PC o en otra que esté visible en la red o en Internet, en mi caso será fer-desktop, pero ustedes pongan la suya.

Cuando clickeen "Buscar" es posible que les pida las credenciales para conectarse al repositorio indicado, así que deberán indicarlas, y opcionalmente pueden marcar el check para "Recordar credenciales como un perfil de conexión", que luego se podrá acceder desde la opción "Preferencias" del panel izquierdo:

Nota: En el caso de que el repositorio externo sea de Internet o fuera de nuestra empresa o casa, conviene usar siempre una conexión SSL para mejorar la seguridad, en cuyo caso el servidor debe indicarse como ssl://ServidorRemoto:8088, donde ServidorRemoto puede ser una dirección URL o una IP.





5) Una vez puestos los datos del PC/servidor destino y puerto, se mostrarán los repositorios encontrados en el mismo (solo los que se tenga acceso), para seleccionar uno y aceptar:




6) Ya podemos "Refrescar" la conexión para que verifique si hay algo que sincronizar, por lo que hacemos click-derecho en la conexión deseada:




7) Si hay algo, como en este ejemplo, se mostrará qué hay, y si son cambios entrantes o salientes, siendo los entrantes los que actualizarán nuestro repositorio origen (normalmente el local) y los salientes los que se exportarán al repositorio destino (normalmente externo):




8) Si hay cambios, sincronizamos todo:




9) Se mostrarán las ramas que se sincronizarán y se da la oportunidad de cambiar algunos parámetros de la sincronización:




10) Si hay cambios para sincronizar, se mostrará un avance del proceso:




11) Hasta que finalice:




12) Una vez terminada la sincronización, se mostrará un mensaje de estado:




13) Respecto del check que había comentado cuando agregamos el repositorio destino, que permitía guardar las credenciales como un Perfil de conexión, estos datos se pueden acceder desde la opción de "Preferencias" del panel izquierdo, de donde se pueden modificar, agregar o eliminar perfiles, e indicar si el perfil es de conexión "Automática" o "Manual":


Respecto de elegir conexión Automática o Manual, la decisión se debe basar en si el repositorio a conectarse está todo el tiempo disponible (siempre online) o no (a veces offline).



[Actualizado. 05/06/2015 >>]

Exportación e Importación manual de repositorios


Plastic permite exportar o importar los repositorios, uno a uno, de forma manual por medio del comando cm desde la ventana de comandos. El formato es abierto y se basa en el mismo formato que usa git, con lo cual también se puede usar para importar o exportar en git.


Exportación:

La sintaxis para exportar es la siguiente:

cm fast-export repositorio@servidor:8087 [archivo-destino.dat]

Si no se indica el nombre del archivo destino, se llamará "fast-export.dat", y si existiera, se le irá agregando 1, 2, 3, etc.


Este es un ejemplo de uso en Linux (muy similar a Windows):

cm fast-export FoxUnit@fer-desktop:8087 ./FoxUnit.dat


Importación:

La sintaxis para importar es la siguiente:

cm fast-import repositorio@servidor:8087 archivo-a-importar



Más información en la web oficial:
https://www.plasticscm.com/documentation/technical-articles/kb-fast-import-fast-export.html
[<<]



Notas finales

Este artículo pretendió explicar de forma rápida como configurar una replicación, pero no es extensivo, y hay unos cuántos parámetros y combinaciones interesantes para ver, como por ejemplo la posibilidad de replicar un origen a múltiples destinos y otras opciones, que les dejo para que les investiguen ustedes.

Espero que les haya sido útil.


Hasta la próxima! :D


Artículos relacionados:
PlasticSCM: Opciones de conectividad, transporte del código fuente y backup


viernes, agosto 15, 2014

Prácticas de VFP 9 con control de código fuente desde CERO - ¡Ayuda! ¡Me perdí! (agosto 2014)

Por: Fernando D. Bozzo

Para estas prácticas de agosto 2014 hice un nuevo Blog para los que se perdieron y para quienes quieran rapasar lo que vamos haciendo, donde iré actualizando todas las tareas que hagamos en el foro, con links a las mismas y a los articulos que publico, en el orden que los vamos viendo, así pueden volver a ponerse en tema rápidamente.

Con solo seguir el orden de los artículos publicados en el Blog, será suficiente para poder avanzar paso a paso en el uso del control de código fuente con Plastic, y en el foro hacen las preguntas.

Gente, de verdad no se preocupen si en algún momento alguno se retrasa. Simplemente hagan las preguntas en el hilo correspondiente a la práctica, marcada como [Foro], y los que ya la hayan hecho podrán responderles sin problemas, yo incluido.

Por ejemplo, si estamos en la PARTE 3 de las prácticas y alguno sigue en PARTE 2, no pasa nada, solo haga sus preguntas en el hilo de la PARTE 2 en la que se encuentra, que todos recibirán el correo de notificación, y por el asunto se sabrá dónde está cada uno.

Con este tipo de participación online, el término "rezagado" no existe, porque es atemporal, de la misma forma que todavía hay preguntas de FoxPro 2.6 y se siguen contestando.

Importante: Es conveniente que primero lo lean el artículo completo antes de hacer nada, para tener una idea del conjunto de pasos, y luego vayan haciendo los pasos. No se apuren.


¿Tienes algún problema? Chequea este artículo, que voy actualizando contínuamente:
PlasticSCM: ¡Houston, tenemos problemas!


¿No puedes bajarte el programa por algún problema en la página de Plastic?
Aquí hay un enlace a una versión de Plastic actualizada que temporalmente va a servir (versión evaluación 30 días y 5 desarrolladores), así que luego hay que bajarse el archivo de licencia gratuita anual para 15 desarrolladores antes de que caduque:
PlasticSCM-5.0.44.596-windows-installer.exe.7z


Recursos de software necesarios (links):


- Visual FoxPro 9.0
- Herramientas FoxPro para Plastic => (Incluyen el EXE de FoxBin2Prg, pero no sus fuentes, que están aquí si los quieren)



Todo lo que estamos viendo está aquí:



Cualquier duda, me escriben o preguntan en el foro.

Fernando D. Bozzo

miércoles, agosto 13, 2014

Control de versiones: ¿Para qué sirve? ¿Por qué es necesario?

Por: Fernando D. Bozzo

Muchos han oido hablar, o incluso han leido, sobre la existencia del Control de Versiones (VCS: Versioning Control System) también conocido como Control de Código Fuente (SCM: Source Code Managment) o su variante Distribuida (DVCS: Distributed Versioning Code Management), pero todavía son pocos los que se han dado cuenta de qué les aporta un SCM a su trabajo programando.

Para complicar más la experiencia, la gente que sí ha usado control de versiones, pero que ha sido mediante SourceSafe, tienden a pensar en una herramienta SCM como un "repositorio de código", debido a las limitaciones de SourceSafe que todo el que haya trabajado con él ya conoce.

Un SCM es mucho más que un repositorio de código, y tienen muchas ventajas trabajar con uno. La mayoría de los lenguajes de programación, que son basados en texto, como Java, PHP, PLSQL, Python, Javascript, C/C++ y muchos otros, vienen beneficiándose de ellos desde los 90, siendo el primero cvs, y siguiendo luego por Subversion (svn), Perforce , y evolucionando luego a DVCS (Distributed Version Control System o Sistemas Distribuidos de Control de Versiones) como Git, Mercurial, Plastic y otros.

En el caso de Visual FoxPro, un SCM tradicionalmente se podía solo usar parcialmente, más que nada para comparar versiones de un archivo, que es muy útil, pero donde los cambios de otros desarrolladores había que seguir haciéndolos a mano para integrar.

Desde fines de 2013, y con la ayuda de un proyecto Open Source hecho en Visual FoxPro, FoxBin2Prg, es posible aprovechar absolutamente todas las ventajas de un SCM o un DVCS que ya disfrutaban los demás lenguajes basados en texto:

  • Se pueden comparar los binarios usando archivos de texto estilo PRG
  • Se puede saber qué se cambió en cualquier momento del tiempo, incluso entre versiones no consecutivas (por ejemplo, hace 3 versiones atrás)
  • Se puede saber quién hizo un determinado cambio, incluso a nivel de cada línea de código
  • Se pueden obtener varias estadísticas, como, por ejemplo, cuántos cambios se hicieron desde la última versión, o qué componentes cambiaron
  • Se puede tener un equipo de desarrolladores que puede trabajar en los mismos componentes (forms, librerías de clases, menús, etc) y que pueden hacer merge (mezcla) de código concurrentemente y obtener binarios FoxPro funcionales de esas mezclas sin bloquearse entre ellos
  • Cada desarrollador tiene su copia local del sistema, donde puede hacer todas las pruebas que necesite sin tener interferencias o bloqueos por los cambios de los demás
  • Si un desarrollador comete un error, los demás no pagarán las consecuencias ni quedarán bloqueados por ello
  • Un desarrollador puede trabajar en la versión actual del sistema, mientras otro puede estar trabajando en el parche de la versión anterior con código más antiguo, y ambos no se verán afectados
  • Se puede trabajar en más de una versión a la vez (esta versión, la próxima, un parche, etc) usando ramas
  • Se tiene la opción de trabajar en un proyecto con gente que está en sitios geográficamente separados. Esto permite que tu trabajes en tu casa, yo en la mía y ambos podamos compartir el mismo repositorio, por ejemplo, GitHub o BitBucket, como repositorio intermedio
  • Se pueden sincronizar varios repositorios de código fuente para backup, para replicación o para otros usos
  • Se tiene la opción de "deshacer" un cambio, o muchos cambios, que afectan a uno o varios componentes de forma segura y volver a una versión anterior
  • Se puede ser libre de los formatos privativos y usar formatos libres que pueden ser usados por más de una herramienta SCM, lo que permite pasarse de una a otra herramienta
  • En definitiva, se tiene el completo control de todos los aspectos del desarrollo de un sistema, de sus versiones, sus cambios y evitando los bloqueos entre miembros del equipo


Si luego de leer esto, siguen con dudas sobre la utilidad que le puedan encontrar, incluso trabajando en solitario, intenten responder estas preguntas a situaciones de la vida real y comparen sus propias respuestas con las que dicen "Con SCM":



¿Llevas el control de las versiones de tu programa?

Con SCM: Siempre es así, además se etiquetan, para mantener un histórico de cambios consultable




¿Cómo lo haces ese control? ¿usando un zip o un subdirectorio por versión? ¿en serio?

Con SCM: Guardando instantáneas de los cambios en una BDD



¿Cómo comparas dos versiones de un archivo?

Con SCM: Se eligen 2 momentos del historial de un archivo y se compara, o se elige una versión y automáticamente se compara con la anterior




Cuando descubres o te reportan un bug, ¿cómo lo buscas? ¿depurando siempre?

Con SCM: Algunos errores se descubren solo mirando los cambios, porque se resaltan nada más que los cambios hechos y no hay que revisar todo el código




Si luego de una o dos horas de refactorización descubres que lo has hecho mal y que sería mejor comenzar de nuevo, ¿cómo haces? ¿restauras un backup?

Con SCM: Se elige el punto de guardado (changeset) anterior con un click




¿Tienes backup de todos los momentos en los que agregas funcionalidades?

Con SCM: Guardar una instantánea de todos los archivos cambiados son unos pocos clicks




Estás trabajando en varios requisitos del cliente a la vez, y al finalizar, o en medio de los desarrollos, te llama y te dice que uno de ellos realmente no lo necesita, o que prefiere otra cosa, ¿qué haces ahora mismo? ¿acaso llevas backup para cada requisito? No vale suicidarse :)

Con SCM: Cada requisito se puede trabajar en su propia rama, y quitar un requisito puede llegar a ser tan fácil como desintegrar una rama (unos clicks)



Estás en medio de una release (versión), y te reportan un bug importante que no puede esperar a la siguiente versión, ¿qué haces? ¿mueves todo el desarrollo a otro sitio y restauras un backup? ¿y una vez hecho el arreglo? ¿vuelves a reponer todo a su sitio y vuelves a realizar los cambios en la versión que tenías a medio hacer?

Con SCM: Se crea una rama para el parche (un click), se desarrolla el parche y se aplica a la versión anterior y a la actual, por medio de merge (mezcla de código)




Sigamos complicando: Tienes un mal día, sacas el parche y resulta que no funciona. Hay que deshacer los cambios, que además también los habías hecho en la versión actual, pero además la versión actual tiene otros cambios posteriores que no quieres deshacer. ¿Cómo deshaces el parche? ¿Tienes tantos backups como para volver atrás? Pero en ese caso perderías los cambios que te servían...

Con SCM hay varios caminos posibles: 1) Puedes hacer un merge sustractivo del parche, tanto en la versión anterior como en la actual (algunos clicks), 2) Puedes elegir comenzar a trabajar en una nueva rama de un momento de la historia anterior al parche, 3) otras alternativas.




¡Ok! ¡Suficiente! Parece que esto sirve, pero suena todo muy complicado o no entiendo todos los conceptos, además que seguramente sea muy difícil de usar y no es que me sobre el tiempo para aprender algo nuevo...

¿De verdad crees eso? ¿Y si te digo que con unas buenas prácticas en dos o tres tardes tienes los conocimientos necesarios para seguir adelante? ¿No crees que estás perdiendo más tiempo haciendo manualmente algunas de las cosas antes comentadas, cuando ya existen herramientas que te lo ponen fácil?

¿Ves todas las facilidades que estás perdiendo, y que te luego te ahorrarán mucho más tiempo que el que vayas a invertir en aprender?


Actualmente en VFP 9 hay varias opciones disponibles para trabajar con control de versiones, desde herramientas SCM/DVCS gratuitas hasta herramientas de pago. Sólo es cuestión de elegir algunas, probarlas y quedarte con la que más te guste para tu forma de trabajo.


Si te interesa seguir adelante, te invito a continuar por aquí:

FoxBin2Prg: Control de código fuente con PlasticSCM

Instalación de PlasticSCM paso a paso

Programas para control de versiones


Hasta la próxima!