En un SCM o en un DVCS trabajar con ramas es algo de todos los días.
Se suelen hacer ramas por tarea para poder trabajar en cada tarea de forma independiente, también se hacen ramas por release, de las que cuelgan las ramas de las sub-tareas que la conforman, también podemos tener a uno o más desarrolladores en cada tarea, donde cada uno tiene su propia rama de trabajo, y finalmente está la rama principal (main o trunk) de donde cuelga todo lo anterior.
Nivelación de ramas
La nivelación de ramas es el mecanismo que se usa para actualizar una rama que tiene un ritmo de actualización menor o distinto a otras ramas, y que se hace mediante la operación de merge o de cherry pick.
Un ejemplo:
Si dos o más personas trabajan en una misma petición o tarea, cada uno haciendo una parte específica de la misma (por ej, uno hace la parte visual y otro el acceso a datos y la lógica de negocio), uno no ve lo que hacen los otros y ninguno tiene todo lo de todos, entonces lo que se hace es que todos combinan sus cambios en la rama de la tarea mediante el merge y luego cada uno nivela su rama con el trabajo de los demás desde la propia tarea.
En la siguiente imagen, se puede observar una tarea TESTS en la que trabajan 2 desarrolladores, DEV_1 y DEV_2, trabajando cada uno en su rama, como se detalló antes, y ocurre la siguiente secuencia de eventos, irando de izquierda a derecha:
1. DEV_1 hace un merge desde su rama de trabajo /main/DEV_1 hacia la rama de la tarea TESTS (flecha verde ascendente), que será automático por ser el primero
2. DEV_2 hace un merge desde su rama de trabajo /main/DEV_2 hacia la rama de la tarea TESTS (flecha verde descendente)
3. En este punto, la rama de la tarea TESTS tiene la suma de los cambios de DEV_1 y DEV_2, por lo que DEV_2 ahora hace una nivelación en su propia rama (flecha verde ascendente) teniendo así los cambios de DEV_1
4. DEV_1 hace lo mismo, y nivela su rama con los cambios de TESTS (flecha verde descendente) mediante un merge, por lo que al terminar tendrá todo lo que hizo el compañero DEV_2
5. DEV_1 termina sus cambios y hace merge en TESTS (flecha verde ascendente)
6. DEV_2 termina sus cambios y hace merge también en TESTS (flecha verde descendente)
7. Finalmente, la tarea TESTS se integra en /main (flecha verde ascendente)
Técnicas de nivelación de ramas
Cuando se hacen merges o nivelaciones, siempre se debe buscar actualizar lo más nuevo sobre lo antiguo y nunca al revés, ya que es más fácil pensar integrar "lo que se agregó nuevo" que hacer el razonamiento y la operación opuesta.
El siguiente es un ejemplo típico de una Release, donde la v1.0 está en Producción (o en el cliente), se está trabajando en la próxima Release v2.0 y en medio hay que sacar un parche v1.1 urgentemente.
La secuencia de eventos es la siguiente:
1. Partiendo de la v1.0 de la primera etiqueta circular verde, salen tanto la rama de la próxima release_2 como la rama del parche v1.1
2. El parche se desarrolla y se integra con un merge sobre la v1.0, lo que crea un nuevo changeset que se etiqueta como v1.1 en segunda etiqueta verde
3. Luego, en vez de integrar este mismo parche sobre la rama de la release_2, se crea una subrama de nivelación desde la v1.1 de arriba (1), se le hace un merge desde la rama de la release_2 (2) para agregar todo lo nuevo, y finalmente se hace la nivelación de la rama release_2 desde la rama_de_nivelación que ya contiene el parche aplicado (3)
De esta forma se maximiza la posibilidad de que los merges que se hacen sean automáticos, ya que de la otra forma (aplicando el parche sobre la release_2) es más probable que haya que hacer merge manual.
Aunque a primera vista pueda parecer un poco complejo, realmente no lo es una vez que se comienza a practicar.
En
esta nota vamos a ver cómo se vincula y sincroniza un repositorio Plastic con GitHub.
Nota: Plastic tiene sus propios repositorios, y no necesita conectarse a repositorios externos como GitHub o BitBucket para funcionar. Esto solo se hace cuando específicamente se quiere trabajar con esos repositorios.
Un aviso importante:
Una vez hecha la sincronización con GitHub ya no hay marcha atrás, y lo que se suba quedará subido y no se podrá borrar localmente.
Aunque se intente borrar localmente (por ejemplo un changeset) en la
siguiente sincronización se volverá a descargar todo y volverá a aparecer, y si no se
controla bien los archivos que suben, sus conversiones a texto, su
capitalización y el tipo de archivo (que no sea basura), puede perjudicar la sincronización con GitHub, lo que en la práctica puede
significar tener que volver a hacer todo desde cero (crear otro
repositorio Plastic, otro repositorio GitHub, etc), por eso insisto
tanto en tomar las precauciones necesarias para no tener que perder
tanto tiempo luego en reconfiguraciones.
Una vez aclarado el tema, ahora sí, el proceso de sincronización.
Pasos a seguir para sincronizar con un repositorio GitHub
1) Seleccionar el alias del workspace que se quiere sincronizar desde la solapa superior, justo bajo el título de la ventana (ejemplo: dvcs_vfp9). Como el workspace está vinculado a un directorio y al Repositorio (de hecho es un alias para una vista del repositorio), Plastic sabe de donde tomar la información y donde actualizar. También puede observarse que justo bajo la solapa del workspace está la información del mismo, en el formato:
Rama @ Repositorio @ servidor : puerto y Workspace path (directorio del workspace)
2) Ahora vamos vincular nuestro repositorio con GitHub. Hacemos
click-derecho en la rama /main sobre la parte gris que está fuera del punto azul (es poco
margen al principio, pero se puede seleccionar y se quedará coloreada de azul claro, bajo los puntos circulares), se abrirá el menú contextual y en
el título del panel derecho deben ver que dice "Nombre de la rama" (si dice "numero de changeset" eligieron mal), en este menú eligen "Replicación / Sincronizar con Git":
3) Aquí ponen la URL del repositorio de GitHub ( ejemplo: https://github.com/fdbozzo/dvcs_vfp9.git ) y el usuario y contraseña que usaron para darse de alta en GitHub, y pulsan "Sincronizar" (no se preocupen del nombre que figura en la captura, que es solo ilustrativo):
4) Si todo salió bien, deberían ver esto:
Si lo anterior sale en rojo, es que algo salió mal (por ejemplo, siguiente imagen) y se debe analizar el mensaje de error dado. En este caso, el error se debió a un bug de Plastic que reporté en febrero y que solucionaron:
5)
Una vez que cierren esta pantalla, ya está hecha la sincronización y
guardadas las credenciales para las próximas sincronizaciones.En el
Explorador de ramas, si actualizan con F5 o con el icono de la flecha circular (a la derecha de ACCIONES PRINCIPALES), deberían poder ver dos o más puntos azules, al menos más puntos de los que veían antes de sincronizar. Esta
vista es un gráfico de changesets (cambios) en el tiempo, donde pueden
ver la fecha (arriba), y hacia la derecha siempre está lo más nuevo.
Nota importante: Las ramas nuevas no hacerlas nunca delprimer
nodo de /main (el de más a la izquierda), debe hacerse de los posteriores y normalmente se hace
desde el último changeset de la derecha, ya que si no les quedarán
ramas fantasma que no podrá ver nadie mas.
Solución a algunos problemas sincronizando con GitHub u otro repositorio externo no-Plastic
Cuando se trabaja con repositorios externos como GitHub, BitBucket u otros, a veces las cosas pueden no salir como esperamos.
Si el problema es de conexión, o sea que da un error nada más intentar sincronizar, lo primero que se debe verificar son los datos de conexión al repositorio externo, como la URL, el usuario y la contraseña, que a veces poner mal un carácter impide la conexión.
Si se detecta que lo que uno de los usuarios ve no se corresponde con lo que debería ver, una solución podría ser que el usuario se cree un nuevo repositorio local, en un nuevo workspace y un nuevo directorio, vuelva a configurar la conexión al repositorio externo y sincronice. De esta forma se le bajará todo nuevamente, y si el repositorio local anterior tenía algún problema, entonces ese problema desaparece.
Normalmente esto lleva unos minutos, dependiendo del tamaño del repositorio externo.
Cuando instalamos Plastic, por defecto no hay un usuario Administrador preconfigurado (no tiene nada que ver con ser Administrador de Windows!).
Normalmente esto no es un problema y se puede trabajar sin más, sobre todo si lo usamos para trabajar en solitario, pero hay que recordar que la Licencia Comunitaria de Plastic es hasta 15 usuarios, y si usamos uno o más repositorios sincronizados con un repositorio externo, como GitHub o BitBucket, nos pueden aparecer otros usuarios sin que nos demos cuenta, y encima se dan de alta de forma automática como usuarios habilitados, que por ende consumen una licencia cada uno.
Ejemplo del problema
Nos creamos uno o varios repositorios locales, (que por defecto usan el backend local de SQLCE en Windows y SQLite en Linux y Mac, salvo que configuremos una BDD externa), y uno o más de esos repositorios los configuramos para que se sincronicen con un repositorio externo, por ejemplo, con GitHub.
Cuando hagamos la sincronización y se actualicen los datos del repositorio local, todos los usuarios que hayan intervenido en el desarrollo de los programas del repositorio (o sea, del proyecto), se darán de alta localmente de forma automática, lo que consumirá parte de las licencias que tenemos disponibles, o, en el peor caso, todas!, y si esto llegara a ocurrir, Plastic se bloquea automáticamente por haber alcanzado el máximo de licencias permitidas. Pero tiene solución...
Cómo evitarlo
La solución es fácil, lo que pasa es que cuesta encontrarla ...y para eso es este artículo :D
Se trata de establecer el usuario Administrador del Servidor Plastic, que es el único que puede habilitar e inhabilitar licencias, y ahí está lo bueno, porque se pueden desactivar las licencias que no se usen!
Esto es útil incluso si se trabaja en un equipo, donde uno de los integrantes se va de vacaciones y otro integrante ocupa su lugar: Se desactiva la licencia del que se va (ojo, no se borra!, solo se desactiva!) y se habilita al nuevo.
Cabe aclarar que las licencias de uso se activan automáticamente cuando se hace el primer checkin, no cuando se agrega un usuario a Plastic.
1 - Comprobar licencias en uso y disponibles
Para comprobar qué licencias se están usando de nuestro servidor Plastic, usamos el comando "cm" desde la línea de comandos de DOS, así:
C:\DESA\dvcs_vfp9>cm li Información de licencia de Plastic SCM:
* Información de usuarios con licencia:
fdbozzo ACTIVO chewbacca ACTIVO
--------------------------------------- Registrado a: Community edition particular - Fernando Bozzo
Fecha de expiración: 02/03/2015 00:22:18
Total de licencias: 15 Total usuarios activos: 2 Total licencias disponibles: 13 ---------------------------------------
En el ejemplo anterior podemos ver que el usuario "chewbacca" está usando una licencia, por estar ACTIVO, y podría haber más. En este caso el total de usuarios activos es 2.
2 - Comprobar el usuario actual
Aunque cada uno sabe con qué usuario se dió de alta en Plastic, lo puede comprobar igual que se hace en Linux, con el comando whoami (en Plastic es cm whoami):
C:\DESA\dvcs_vfp9>cm whoami fdbozzo
3 - Consultar el usuario administrador del Servidor Plastic
A continuación consultamos el usuario administrador del Servidor Plastic, que inicialmente será "all":
C:\DESA\dvcs_vfp9>cm showowner repserver:win7u:8087 repserver:win7u:8087 all Usuario
Si el usuario es "all", conviene configurar el usuario Administrador como se indica en el siguiente paso.
4 - Configurar un nuevo usuario Administrador del Servidor Plastic
Ahora configuramos (o reconfiguramos) el usuario Administrador (el nuestro, que consultamos antes), como se indica a continuación, reemplazando el usuario por el vuestro y el servidor (PC) por el nombre de la máquina donde hayan instalado Plastic (el mismo que en FoxPro se obtiene con SYS(0) ):
Siendo Administradores del Servidor Plastic podemos usar el comando "cm du" (o también "cm deactivateuser") para desactivar licencias. En este caso desactivaremos la licencia del usuario "chewbacca":
C:\DESA\dvcs_vfp9>cm du chewbacca --nosolveuser El usuario chewbacca_cp ha sido desactivado correctamente
Volvemos a listar las licencias en uso para comprobar los cambios:
C:\DESA\dvcs_vfp9>cm li Información de licencia de Plastic SCM:
* Información de usuarios con licencia:
fdbozzo ACTIVO chewbacca INACTIVO (No tiene licencia) --------------------------------------- Registrado a: Community edition particular - Fernando Bozzo
Fecha de expiración: 02/03/2015 00:22:18
Total de licencias: 15 Total usuarios activos: 1 Total licencias disponibles: 14 ---------------------------------------
Listo! Eso es todo. Ya tenemos esa licencia DESACTIVADA (que no borrada), que podremos volver a activar cuando querramos, y en este caso quedó un único usuario activo.
6 - Activar licencias de usuario
Siendo Administradores del Servidor Plastic podemos usar el comando "cm au" (o también "cm activateuser") para activar o reactivar licencias. En este caso activaremos la licencia del usuario "chewbacca":
C:\DESA\dvcs_vfp9>cm au chewbacca --nosolveuser El usuario chewbacca_cp ha sido activado correctamente
Volvemos a listar las licencias en uso para comprobar los cambios:
C:\DESA\dvcs_vfp9>cm li Información de licencia de Plastic SCM:
* Información de usuarios con licencia:
fdbozzo ACTIVO chewbacca ACTIVO --------------------------------------- Registrado a: Community edition particular - Fernando Bozzo
Fecha de expiración: 02/03/2015 00:22:18
Total de licencias: 15 Total usuarios activos: 2 Total licencias disponibles: 13 ---------------------------------------
Tengan muy presente esto, porque si el Servidor Plastic se bloquea por aclanzar las licencias permitidas, desactivando licencias es la manera de desbloquearlo.
Una de las cosas que más me gustan de este SCM (Source Control Manager o Administrador de Código Fuente) es la cantidad de opciones que tiene para conectarse y sincronizarse con otros servidores Plastic y con otros servicios como GitHub, BitBucket y otros.
Este artículo está dedicado a quienes necesitan sincronizar sus repositorios con otras personas o con otros servicios, trabajen en solitario o en grupo. Lo importante es conocer las opciones disponibles para luego elegir.
Quienes vienen trabajando con herramientas de control de código, ya saben que una vez que se comienza a trabajar así, no se puede ni se quiere vivir sin él, y quienes estén comenzando a conocerlo, estarán pudiendo comprobar, al menos, algunas ventajas que aporta, como poder ver y analizar el historial, deshacer o rehacer cambios, hacer un Diff o un Merge (....a qué ahora sí les suena esto :), preparar versiones del sistema, también llamadas Releases, preparar parches, trabajar simultáneamente en más de una versión del mismo componente, etc.
Dicho esto, una de las cosas que nos aportará valor y comodidad es poder disponer del control de código donde sea que estemos trabajando, tanto trabajando en solitario como trabajando en grupo y compartiendo un proyecto, y por eso vamos a ver varias situaciones y alternativas de trabajo disponibles.
Supongamos que disponemos de un PC de escritorio en
casa, o de un servidor en la oficina, donde está instalado el componente servidor
de Plastic con los repositorios definitivos, y donde realmente se centralizará todo el control del código fuente. Es necesario mantenerlo siempre actualizado, por lo que las vías para hacerlo son:
Trabajar directamente en ese PC o en el servidor
Trabajar en una red local con acceso a ese PC o servidor
Trabajar desde Internet con acceso a ese PC o servidor
Trabajar en una ubicación desconectada y sin Plastic, hacer una copia de lo trabajado en zip y sincronizarlo más tarde en el servidor Plastic
Trabajar en una ubicación sin Plastic, pero con acceso a DropBox, Google Drive u otro servicio de guardado en la nube, para más tarde sincronizarlo en el servidor de Plastic
De ahora en más, hablar de una PC de sobremesa, hablar de una Portátil o hablar de un Servidor de Oficina o Empresa, en todos los casos con el componente servidor de Plastic, los consideraré a todos como "el servidor Plastic", ya que es la función que están realizando, desde el momento en que permiten guardar el código fuente en una Base de Datos local.
Es importante entender esto, porque todo lo posterior tratará sobre formas de sincronizar los repositorios entre servidores Plastic, que perfectamente podrían sincronizarse entre una PC de sobremesa y una Portátil, o entre una Portátil y un Servidor de Oficina/Empresa, o entre dos (o más) Portátiles, o usando un repositorio externo como GitHub, BitBucket, etc, o cualquier otra combinación que se les ocurra donde intervengan dos o más servidores Plastic.
Finalmente, y para despejar cualquier duda, "sincronizar" es la acción de actualizar repositorios en ambos sentidos, o sea que se suben los cambios (archivos y directorios nuevos, modificados o eliminados) que el repositorio destino no tiene y se bajan los cambios que nuestro repositorio local no tiene, quedando el historial en ambos casos igualado.
¿Pero sincronizando no se pisarán mis cambios con los de los demás?
Puede ocurrir, si no se trabaja de forma organizada. Para evitar estos problemas fácilmente, la forma de trabajar debe ser tener una rama por desarrollador como mínimo, y a su vez otra rama por tarea, pero fundamentalmente debe haber un proyecto inicial, con su pjx, los archivos de configuración de Plastic y con toda la estructura de directorios en el repositorio, para evitar diferencias innecesarias en nombre de directorio o capitalización, y demás.
Opciones de sincronización entre repositorios
Estas son algunas de las opciones disponibles:
Sincronizar un repositorio Plastic local con otro repositorio Plastic remoto. Esta es la opción ideal y la más eficiente. Requiere una conexión de red o por Internet entre ambos servidores Plastic, y que no esté bloqueado el puerto 8087 (u 8088 si se usa seguridad SSL). Ojo, Plastic no soporta Firewalls donde deba autenticarse. En esos casos se deberá usar redirección de puertos.
Sincronizar un repositorio Plastic local con otro repositorio remoto como GitHub, BitBucket o cualquier otro soportado. Esta opción implica usar un servicio "intermediario", y si el repositorio no es público, probablemente implique algún costo extra asociado, ya que al menos GitHub, si se quiere usar un repositorio privado, se debe pagar, y supongo que con el resto será lo mismo.
Trabajar con cliente Plastic local y servidor Plastic en red o por Internet. Realmente aquí no hay sincronización. Esta opción se suele usar en las empresas que tienen uno a varios equipos de desarrollo internos o externos, pero donde el código fuente se quiere que solamente esté en el servidor corporativo por ser un bien intelectual de la empresa. La única desventaja de este modelo es que si la red no es veloz se pueden producir picos de congestión si los equipos de desarrollo son numerosos o si se usa para procesos de Integración Continua (CI). Requiere una conexión de red o por Internet entre ambos servidores
Plastic, y que no esté bloqueado el puerto 8087 (u 8088 si se usa
seguridad SSL) y en este escenario ayuda mucho utilizar balanceo de servidores o Servidores Proxy Plastic (esto está mejor explicado en su web)
Supongamos que tenemos un portátil
nuestro que usamos para programar, en el que podemos instalar lo que sea
necesario, y que llevamos de aquí hacia allá todo el tiempo, sea a lo
del cliente, a casa o a un bar. Tenemos un Servidor Plastic
instalado en el portátil, y nuestros repositorios, cada uno con su proyecto. Aquí
trabajamos normalmente y sin mayor problema, ya que tanto el código como
el SCM están en el mismo equipo, por lo que hacemos checkin, merge,
ramas y lo que haga falta.
Si tuviéramos que sincronizarnos con un compañero que trabaja en otra ubicación y donde no compartimos una red local, podríamos usar estas opciones:
Sincronización Plastic local a Plastic remoto. En este caso los dos nos ponemos de acuerdo en un horario para conectarnos a Internet y la sincronización sería directa de equipo a equipo usando el puerto 8088 SSL (u otro), y para resolver el problema de la IP dinámica se puede usar algún servicio como NoIP, DynDns o similar. El único problema con esto sería ponerse de acuerdo en ese horario, y que, a día de hoy, la versión 5 de Plastic no soporta la conexión a través de Firewalls que requieran autenticación, pero si al Firewall se le configura redirección de puertos, muy probablemente se pueda.
Sincronización Plastic local a servidor remoto (GitHub, etc). Este es el caso comentado en Opciones de Sincronización, donde se usa un repositorio intermediario.
Sincronización mediante archivos zip por DropBox. GDrive o similar. Esto realmente no es una sincronización, pero al menos permite incorporar los cambios de otra persona al repositorio local. La idea es crear dos ramas, la nuestra y la de nuestro compañero. Nosotros trabajamos en nuestra rama normalmente hasta que nuestro compañero nos envía un zip mediante DropBox, Google Drive o similar. Nos pasamos temporalmente a la rama de nuestro compañero, descomprimimos el zip en el workspace y hacemos el checkin. Ya está en control de código y podemos hacer un merge de su rama a la de integración. Este mecanismo es un poco Espartano porque nos implica estar haciendo un merge de lo nuestro y un merge de lo del otro, y al otro le implica lo mismo, con lo que se duplica el trabajo de integración y la posibilidad de errores, pero al menos nos puede sacar del paso.
Sincronización Plastic local a Plastic local. Si, suena raro, pero se pueden crear 2 o más repositorios Plastic locales usando distintos workspaces y distintos nombres de repositorio, para luego, mediante un perfil de conexión (comentado más abajo), sincronizarlos. No sé si tenga alguna utilidad, ya que yo lo usé solo para probar y simular 2 usuarios distintos que sincronizaban sus repositorios (que se pueden modificar por separado), pero es bueno conocer las opciones disponibles.
Fast-Export/Fast-Import: Finalmente hay una opción que merece ser conocida, que es la opción Fast-Export y Fast-Import, basada en el formato abierto de Git, que permite exportar un repositorio completo a un archivo en este formato de Git, y también permite importarlo. Esto permite una capa más de compatibilidad, no solo con Git, sino con otros SCM que admitan ese formato.
Dentro de la sección de configuración de Plastic, hay un apartado llamado Perfiles, donde se pueden configurar perfiles de conexión con distintos esquemas de autenticación (usuario/password, LDAP, Directorio Activo, etc).
Este apartado merece ser conocido, porque realmente admite muchas opciones de conectividad.
Como se podrá comprobar en la Instalación, los puertos son configurables, y esta configuración se puede cambiar en cualquier momento
Hay mucha documentación disponible en la web de Plastic, aunque lamentablemente está solo en Inglés. Este es un link al apartado donde explican todo sobre entornos distribuidos.
El comando Annotate, habitualmente llamado "blame" (culpar) en los demás SCM, sirve para obtener información sobre las modificaciones hechas a un archivo, como saber quién modificó una línea, cuándo, etc.
En Plastic lo podemos encontrar en el menú contextual de la vista de Items, en la vista de Cambios Pendientes y al ver el contenido de un changeset, cuando le hacemos doble click.
Ejemplo desde la vista de Items:
Vista Annotate por defecto, donde se puede apreciar la información por cada línea (usuario, número de changeset donde se cambió, rama en la que se cambió y número de línera), el degradé de colores indica la antigüedad del cambio, cuanto más claro, más reciente es el cambio:
En el menú contextual de esta vista también hay varias opciones más:
Entre ellas, el poder ver los cambios coloreados por usuario:
El botón "Statistics" de arriba permite ver algunas estadísticas, como la cantidad de líneas del fichero, la antigüedad y la cantidad de líneas modificadas por desarrollador:
Algo muy útil de esta funcionalidad Annotate es que, al igual que el resto de funcionalidades en Plastic, lo mismo se puede obtener desde la línea de comandos con el comando cm, por ejemplo, estando en la terminal de DOS ubicado en el directrorio del workpsace, este comando:
cm annotate forms\frm_test_fdb.sc2
Genera esta información:
La interfaz de comandos, mediante el comando cm, permite automatizar la mayoría de las funciones de Plastic, lo que es increíblemente flexible y útil no solo para usar en scripts, como las utilidades de Visual FoxPro 9 para Plastic, sino también para automatizar la generación de estadísticas que luego se puedan mostrar por otros sistemas, incluso en web.
Aquí hay un link de ejemplo de lo que se puede obtener:
La verdad es que a veces se buscan términos que confunden, cuando se podrían utilizar otros que todo el mundo conoce. El Shelve es el concepto del portapapeles (clipboard) aplicado a un changeset.
Si, es el copiar+pegar de un grupo de archivos en la rama que se elija, pero con la diferencia de que:
El "pegar" se hace con un merge especial llamado "Cherry Pick"
Este portapapeles (Shelves) se ha potenciado para que permita múltiples entradas que se guardan por separado (cada entrada es un changeset)
Se les puede poner una descripción, para diferenciarlas de otras entradas
Se pueden compartir con los demás desarrolladores que estén en el mismo servidor Plastic, ya que se guardan en la base de datos
Se pueden borrar o reutilizar todas las veces que se necesite
Veamos un ejemplo de uso:
1. Tomamos un form:
2. Le hacemos un cambio, en este caso solo modificaré el backcolor:
3. Verificamos los datos cambiados, que mostrará solo los binarios del form, y regeneramos la vista de texto del form, para tener ambas versiones sincronizadas:
4. En vez de hacer checkin, hacemos Shelve, lo que lo guarda en el portapapeles que comenté:
Observación al paso: Ya que tenemos este menú abierto, notar que hay una opción "Proteger los cambios a otra rama", que sirve para guardarlos en una nueva rama con el nombre que le demos. Viene bien cuando nos equivocamos e hicimos los cambios en la rama principal y olvidamos crear antes la rama de trabajo, lo resolvemos aquí en un paso ;-)
5. En la ventana de confirmación que nos aparece, podemos guardar estos cambios y seguir modificando, o guardar estos cambios y deshacerlos de la rama si marcamos el check de abajo, lo que permite mantenerlos solamente en el portapapeles (Shelve):
Como deshice los cambios del workspace, el form volvió a quedar como estaba:
6. Nos muestra un mensaje confirmando el guardado, donde se puede marcar el check de abajo para que no vuelva a mostrar este mensaje:
7. Nos muestra la vista de Shelves con los que haya, donde arriba siempre están los más nuevos. Un apunte: Esta vista tiene el panel derecho desactivado por defecto, pero se puede activar del icono indicado en la imagen, y en el mismo panel se puede poner un comentario descriptivo, que es muy útil para saber de qué se trata y no se pierda entre los demás:
8. Para aplicar un Shelve en el workspace, se elige desde el menú contextual:
9. Aquí se muestra el Shelve aplicado, que es el equivalente a haber realizado las modificaciones a mano. Un apunte: Aplicar un Shelve implica hacer un merge del Shelve sobre el contenido del workspace que, como todo merge, puede ser manual o automático dependiendo de los cambios hechos en el workspace. Como en este ejemplo antes deshice los cambios del workspace, entonces no hay cambios y el merge será automático:
Y a partir de aquí es como cualquier otro cambio merge que hemos hecho antes.
El resultado de aplicar este Shelve, es el cambio de color del form:
Nota: El Shelve se puede usar
para guardar cambios pendientes normales, no los cambios pendientes de
un Merge, ya que no puede guardar el link de Merge.
Resumen
El Shelve puede ser muy útil usarlo como "backup rápido" cuando se deba hacer un checkin de varios archivos en los que se pretenda deshacer los cambios de los binarios que no tengan su versión texto tx2 (o sea, se indicó generar, pero no se generó), y que por tanto no tienen cambios en el código (esos cambios en los binarios pueden ser por el timestamp interno), y que pueda ocurrir un error que les haga perder los cambios de uno o varios archivos.
Hay situaciones en las que necesitamos borrar uno o varios cambios (changesets), pero queremos borrarlos con la opción de poder recuperarlos luego, o queremos borrarlos definitivamente pero nos es imposible porque no es el último changeset, sino uno o varios intermedios que ya forman parte del historial, y que por cuestiones de integridad referencial Plastic no permite borrarlos.
En estas situaciones lo que se puede hacer es un "merge sustractivo", o sea, un merge para deshacer cambios, que funciona exactamente al revés del merge común, que agrega cambios.
Aunque son exactamente la operación opuesta, tienen un punto en común, y es que en ambos puede darse el caso de requerir una intervención manual, o sea, de resolver algo a mano, bien desactivando los cambios de un panel en la ventana de merge o bien modificando a mano valores directamente.
En esta nota vamos a ver el merge sustractivo automático, ya que la parte manual es la misma que ya comenté en el merge normal, excepto que en vez de agregar cambios, quitaríamos cambios.
Cómo deshacer un changeset
Supongamos que hemos agregado un archivo en un changeset que no debíamos agregar e hicimos algunos cambios que no queremos, y que nos damos cuenta luego de haber hecho otros cambios que hemos guardado en otro changeset posterior y que no queremos borrar, solo queremos quitar el changeset del archivo agregado y los cambios anteriores.
Imagen 1: Cambios a mantener del nuevo botón "Pag.4" (click en la imagen para agrandar)
Imagen 2: Los mismos cambios, pero vistos en el código, luego de hacer doble-click en el changeset de la flecha verde
Imagen 3: Cambios a descartar del label verde (click en la imagen para agrandar)
Imagen 4: Los mismos cambios, pero vistos en el código, luego de hacer doble-click en el changeset de la flecha verde
1. Para deshacer este changeset, lo marcamos (flecha verde de la imagen 4), elegimos click-derecho, "Merge Avanzado" y "Merge sustractivo de este changeset...", lo que mostrará esta pantalla en la que se puede observar que se borrará el archivo antes agregado y se desharán cambios en el form:
2. Procesamos el merge, y nos quedarán los binarios, ya que solo podemos trabajar con versiones texto en un merge, y en este caso los cambios han sido todos automáticos (aunque no siempre es así):
3. Seleccionamos los binarios que queden e indicamos dejar los que ya hay en el workspace:
4. Como hemos hecho el merge sustractivo sobre la versión texto, y por suerte ha sido automático, debemos regenerar los binarios desde los textos. Nunca olvidar que en un merge "el texto manda" y el binario se regenera:
Y esperar el mensaje de confirmación:
5. Hacemos el checkin y confirmamos que en la vista del Explorador de ramas que ha quedado una línea roja de merge sustractivo, que saltea al changeset que queríamos mantener:
6. Finalmente, confirmamos que tanto el archivo agregado antes ahora se quita, como el código del label verde:
Como podemos ver, en el form no hay rastros del label verde y el botón "Pag.4" se mantiene.
Cómo deshacer un grupo de changesets
La forma de operar es la misma que para uno, pero con una única excepción: en vez de elegir un changeset se deben elegir dos.
Si que queremos deshacer los changesets marcados en naranja, debemos marcar (click) el de la izquierda (flecha verde) y luego marcar el de la derecha con ctrl+click (la otra flecha verde). Visualmente se puede comprobar la selección porque el fondo azulado del changeset es un poco más claro y porque el borde redondeado deja de ser gris claro y es gris oscuro:
Ejemplo 1 - Cuando los changesets a Deshacer están en la misma rama
En este caso todos los cambios están en la misma rama, por lo que el merge sustractivo también se hace en la misma rama.
Ejemplo 2 - Cuando los changesets a Deshacer están en distintas ramas
En este caso todos los cambios se han hecho en una rama secundaria (fdbozzo2), luego fueron integrados en la rama de tarea con un merge (punto A - flecha verde) y luego fueron deshechos con un merge sustractivo de la rama secundaria (fdbozzo2) pero con destino en la primaria (punto B - flecha roja)
El motivo de elegir un changeset más a la izquierda de la selección, es que se trata de un intervalo abierto-cerrado, donde la parte abierta (flecha verde izquierda) se selecciona pero no está incluida, y la parte cerrada (flecha verde derecha) se selecciona y está incluida.
[Última actualización: 12/11/2017 - Registro de la clase visualfoxpro.application.9]
Por: Fernando D. Bozzo
...Y es normal, todo no puede salir siempre bien o tal cual se pone en los tutoriales, en los artículos o en los videos. Además, quienes los hacemos, intentamos de que salga todo perfecto, haciendo pruebas previamente y equivocándonos "antes" de publicar algo, pero el problema es que al no mostrarse los posibles fallos, entonces no se puede aprender de ellos, y este artículo intenta llenar un poco ese hueco, con problemas comunes y cómo resolverlos.
1. Quiero cancelar el merge que estoy haciendo, ¡pero no sé cómo salir!
Este problema tiene 2 partes:
a) Mientras se está haciendo el merge
Cuando se hace merge de muchos archivos y no se quiere estar cancelando uno por uno 200 veces, se puede cancelar todo el proceso desde la ventana principal, para lo que es importante no intentar cerrar la ventana actual de merge (que pueden haber muchas, una tras otra), sino conmutarse a la ventana principal, pulsar el botón Cancelar y recién ahí se puede volver a la ventana de merge que quedó abierta y cancelar.
Luego se debe comprobar si hay Cambios Pendientes (no olvidar refrescar la vista) y deshacer todo, si hubiera algo.
b) Una vez hecho el merge
Si hay Cambios Pendientes (no olvidar refrescar la vista) y deshacer todo, si hubiera algo.
2. ¡No puedo hacer un Merge, sale una pantalla rara!
Ok, estamos haciendo un Merge y nos sale esto:
¿Qué pasó, si lo elegido era un archivo de texto, no un binario?
Pueden haber pasado dos cosas:
1. Que el archivo efectivamente sea un binario:
Y si es un binario, entonces no hay otra opción que elegir quedarse con el Origen (el archivo desde donde se hace el Merge), con la Base (de donde partieron origen y Destino) o con el Destino (el archivo del workspace). Pero esto solo debe hacerse si no se trabaja con VFP o si no se usan las herramientas de FoxPro para Plastic.
También puede haber pasado que se haya configurado mal la herramienta de Merge de FoxPro en Plastic, ya que esa configuración sirve para que esta pantalla no aparezca. Por las dudas, la configuración, que está en el README.txt, es esta:
CONFIGURACIÓN DE MERGE EN PLASTICSCM: ------------------------------------------------------------------------
Clickear en el icono de Preferencias de PlasticSCM
Seleccionar "Herramientas Merge" y "agregar" esto:
Mover la extension agregada al inicio de la lista, para priorizarla
2. Que no esté reconociendo el archivo como texto:
En ese caso se debe cancelar el merge cerrando la ventana de la imagen anterior, cerrar la solapa e merge, Deshacer los cambios pendientes (ver el tema anterior: "Quiero cancelar el merge que estoy haciendo, ¡pero no sé cómo salir!") y cambiar el tipo de archivo a texto en la vista de Items:
Luego de solucionar esto, podremos volver a reintentar el Merge, y ahí sí que ya debería salir la ventana de merge normal, y no olvidar "saltear" los binarios que queden, como ya expliqué en el artículo "PlasticSCM: ¿Qué es el Merge".
Para más detalle, también está este video corto:
3. ¡No puedo hacer un Diff, sale un error!
Si sale esta pantalla:
Es porque Plastic no reconoció bien un archivo de texto y lo toma como tipo binario, o porque elegimos un archivo para el que no hay conversor disponible, o porque es un archivo binario normal.
Trabajando con las herramientas de FoxPro 9 esto puede pasar en 3 casos:
1. Plastic no reconció bien un archivo de texto:
Este es el mismo caso que comenté en el punto (2) del problema anterior con el Merge, y tiene la misma solución.
2. Elegimos un archivo para el que no hay conversor disponible:
Si el archivo es un pjx, vcx, scx, frx, lbx, mnx, dbf o dbc, el problema es que se configuró mal, o no se configuró, la opción de DIFF en las opciones de Plastic. El README.txt indica como hacerlo:
CONFIGURACIÓN DE DIFF EN PLASTICSCM: ------------------------------------------------------------------------
Clickear en el icono de Preferencias de PlasticSCM
Mover la extension agregada al inicio de la lista, para priorizarla
3. Elegimos un binario normal:
En este caso hemos querido hacer Diff sobre un EXE o SCT o VCT o cualquier otro binario no soportado.
4. ¡No puedo borrar el workspace!
Cuando hay una sola solapa, será el workspace activo, y no se podrá eliminar:
Para poder borrarlo necesitamos tener un segundo workspace, que podemos crear apuntando a un directorio cualquiera (ya que no lo usaremos) o aprovechar y crear otro repo que necesitemos, lo que creará una segunda solapa que deberemos elegir.
Ahora sí, si en el panel izquierdo seleccionamos "Workspaces", podremos eliminar el workspace anterior.
Nota: Eliminar el workspace solo borra el "alias" del repositorio, no borra el repositorio ni su contenido. Esto permite poder crear un workspace distinto con un nuevo directorio para el mismo repositorio.
5. ¡Me equivoqué al crear el workspace y lo asocié a un directorio equivocado!
En este caso debemos borrar el workspace (no el repositorio!) y volverlo a crear. Si al hacerlo nos da un error como este:
Es porque es el único workspace y está activo. Ver el punto anterior "¡No puedo borrar el workspace!"
Si están queriendo usar otro modo de autenticación porque lo van a usar, por ejemplo, en la oficina con autenticación de Directorio Activo u otro, entonces deben verificar que la configuración del cliente y la del servidor son iguales.
Para comprobarlo, deben ir al menú Programas / PlasticSCM y a continuación:
> Para el cliente, abren la opción: Client Tools / Client Configuration Wizard
> Para el servidor, abren la opción: Server Tools / Server Configuration Wizard
7. Error al intentar abrir el cliente Plastic (2)
Si ocurre el siguiente error, es muy probable que el servicio "Plastic Server 5" no esté levantado:
Para solucionarlo, lo primero que se puede hacer es reiniciar la PC si no se hizo al instalar Plastic, y si no también se puede abrir la consola de Servicios, verificar si está levantado, y si no lo está, iniciarlo:
Esta es la configuración que tengo por defecto para este servicio:
8. ¿Cómo se cambia el idioma?
Cuando se instala un programa, a veces no miramos bien las opciones de la pantalla y le damos "aceptar", "aceptar", "aceptar"... hasta que nos damos cuenta de que se nos pasó algo.
Plastic por suerte viene con 2 programas de configuración, uno para el cliente y otro para el servidor, que permiten configurar el idioma, el servidor, el puerto de conexión, el modo de autenticación, etc.
Para reconfigurar el cliente o el servidor, deben ir al menú Programas / PlasticSCM y a continuación:
> Para el cliente, abren la opción: Client Tools / Client Configuration Wizard
> Para el servidor, abren la opción: Server Tools / Server Configuration Wizard
En ambos casos, vayan avanzando en las pantallas hasta encontrar lo que buscan.
Recuerden que si acaban de instalar el programa, es probable que deban reiniciar la PC o probablemente les de errores al intentar ejecutar Plastic.
9. ¡No puedo descargar Plastic, da un error la página!
Aquí
hay un enlace a una versión de Plastic actualizada a agosto 2014 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
11. ¡Borré el directorio del workspace sin querer y se perdió todo! ¿Qué hago?
Lo que has borrado es solamente los archivos del directorio, no lo que tienen guardado en la Base de Datos, por lo que hay 2 soluciones, una rápida y otra algo menos rápida:
Opción 1: Si no has borrado el directorio oculto ".plastic" del directorio del workspace, entonces puedes ir al Explorador de Ramas, buscar el último changeset y ubicar la casa ahi (click-derecho -> Apuntar workspace a este changeset). Este último paso descargará de la BDD de Plastic todos los archivos en sus ubicaciones.
Opción 2: Si has borrado el directorio oculto ".plastic", entonces debes borrar el workspace de Plastic desde el panel izquierdo (Workspaces), volver a crearlo, asociándolo al mismo directorio (u otro), buscar el último changeset y ubicar la casa ahi (click-derecho -> Apuntar workspace a este changeset). Este último paso descargará de la BDD de Plastic todos los archivos en sus ubicaciones.
12. Quiero ver/comparar el contenido de un archivo tx2 (texto) y dice que es binario!
Cuando esto ocurre, es porque la información del tipo de archivo se perdió en algún momento, o directamente no se indicó en el archivo filetypes.conf del directorio raíz del workspace.
Para solucionarlo, vamos a la vista de Items, seleccionamos los archivos de texto que figuran como binarios, hacemos click-derecho sobre alguno de ellos y elegimos Camiar tipo de revisión -> Texto, y listo, problema resuelto.
13. No me reconoce la licencia plastic.lic
El archivo de licencia plasticd.lic que reciban, se debe copiar en el subdirectorio server dentro del directorio de instalación de Plastic (hay un directorio client y uno server), pero antes de copiarlo deben "bajar" el servicio de Plastic ("Plastic Server 5"), luego copiar al archivo y luego volver a levantar el servicio, para que reconozca la licencia.
14. No se puede crear el objeto "visualfoxpro.application.9"
Esto pasa cuando el IDE de Visual FoxPro (vfp9.exe) no está registrado en el registro de Windows. Aunque se puede usar manuelmante el IDE sin registrarlo, el no tenerlo regitrado impide poder usarlo como clase de automatización.
El arreglo es simple: Se abre una ventana de comandos como admin, y se pone esto, adaptando la ruta donde realmente se encuentre VFP9.exe:
Aunque el mensaje es bastante explícito y "técnicamente" correcto, vamos a comentarlo por partes, ya que no siempre es fácil ni evidente determinar el motivo que impide borrarlo.
Etiquetas: Eso es lo más fácil de ver, porque visualmente se puede comprobar si el changeset que se quiere borrar tiene etiquetas o no (pueden haber varias etiquetas en un mismo changeset). Si las tiene, las mismas se deben borrar antes de poder borrar el changeset.
Ramas: PlasticSCM mantiene y comprueba la integridad de los changesets, por lo que si una rama depende de un changeset, el mismo no se podrá borrar hasta que se eliminen las ramas que dependen de él. Esta solución (borrar ramas) es un tanto brusca y debe usarse como último recurso siempre que realmente sea muy importante borrar un changeset y todas sus ramas dependientes. Normalmente esto solo se hace cuando se realizan pruebas con la herramienta de Control de Código, donde se crean ramas y changesets de prueba para luego eliminarlos. Al igual que las etiquetas, ver las ramas dependientes es visualmente comprobable.
Shelves: Esto ya es más complejo, porque los shelves se crean a partir de un changeset bajo la idea de poder proteger los cambios temporalmente para poder continuar con otra cosa en otra rama y luego volver a aplicarlos en el mismo sitio cuando se vuelva a trabajar en la misma rama. El problema radica en que por un lado los shelves no son visuales y por el otro en que la información del shelve no indica en qué changeset se hizo, por lo que visualmente es imposible verlo.
Una solución (algo salvaje) podría ser borrar todos los shelves guardados, y con eso se solucionaría el problema, pero hay otra solución mucho más moderada, que consiste en preguntar a Plastic qué shelves se basan en el changeset que se quiere borrar.
Por ejemplo, si se quisiera saber qué shelves se basan en el cs:4236, la consulta desde la ventana de comandos sería esta:
cm find shelves where parent = '4236' --format="{parent} # {owner} # {guid} # {date} # {comment}"
Esto listará todos los shelves que se crearon desde ese changeset.
Para evitar tener que recurrir a esto y poder resolverlo visualmente desde la vista de Shelves, es muy recomendable que antes de crear un shelve se ponga como inicio de comentario en la vista de cambios pendientes el changeset del que parte. Por ejemplo: "cs:4236 - Arreglo bug cálculo precio"
Observaciones:
De algunos de los errores comentados, también puede deducirse que a veces vamos tan a las apuradas que no prestamos atención al instalar o configurar algo, lo que luego nos trae un sinfín de problemas que en muchos casos se podían haber evitado. Es mejor dedicar el tiempo necesario a configurar bien y sobre todo a entender cómo funciona lo que estamos configurando, y no quedarse solo con los paso-a-paso, para no perder tiempo luego y dominar mejor nuestras herramientas.
Este contenido lo iré actualizando con otros problemas comunes que me vayan surgiendo o que me sugieran.
