martes, agosto 26, 2014

Nueva versión v1.19.32 de FoxBin2Prg (arreglo bug)

Está liberada la versión v1.19.32 de FoxBin2Prg con los siguientes cambios:

  • Una propiedad llamada "text" es confundida con la estructura text/endtext (ph42).




Como actualizar el FoxBin2Prg existente:
Con descargar el zip y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.


Link  de descarga:
https://vfpx.codeplex.com/releases/view/116407


 Saludos!

sábado, agosto 23, 2014

PlasticSCM: Opciones de búsqueda y visualización de ramas y changesets

Por: Fernando D. Bozzo

Cuando se comienza a trabajar con ramas, al poco tiempo se puede convertir en un frondoso árbol donde a veces es difícil poder ver una rama particular y sus relaciones, porque es cruzada por varias otras que en principio no nos interesa ver.

Una de las cosas más importantes que se debe conocer, cuando se trabaja con una herramienta SCM o DVCS, es poder visualizar lo que se quiere de distintas formas, para tener un mejor control sobre lo que se está haciendo o viendo.

En este artículo veremos varias de ellas, y les recomiendo elegir estas opciones al menos una vez para conocerlas y ver su utilidad.

Nota: Todas las vistas permiten trabajar desde ellas. No solo son para visualizar.


Todas las vistas se seleccionan desde el panel izquierdo, el cuál está siempre visible:




Vista del Explorador de ramas


Esta es una vista típica de las ramas de un equipo de desarrollo donde, como se puede observar, cuesta un poco poder ver solo las ramas marcadas en amarillo:





Panel derecho del Explorador de ramas


Con el botón Navegador se puede habilitar o inhabilitar el panel derecho, que tiene varias opciones interesantes:




Apartado: Propiedades


Dentro de este apartado podemos ver información sobre el changeset o rama seleccionada, además de que desde aquí podemos modificar los comentarios:




Apartado: Opciones de visualización


Dentro de este apartado podemos controlar varios aspectos de lo que se muestra en el Explorador de ramas, incluso opciones de filtrao por fechas o niveles de hijos desde el changeset 0.

La mayoría de las opciones son simples y se pueden entender a primera vista, pero hay un par de opciones que no son tan obvian y que requieren algo de explicación, y que son las de debajo de todo: Activar modo de edición de visibilidad y Activar edición de disposición.


Activar modo de edición de visibilidad

Permite ocultar/mostrar ramas: Se elige esta opción, se marcan las ramas a ocultar y se desmarca esta opción para finalizar. Todavía no me tocó una situación donde requiera esto.

Nota: Cuando se elige esta opción, se muestra una explicación de uso debajo.


Activar edición de disposición

Esta opción permite reorganizar las ramas, para poder agruparlas de una forma más útil que la forma por defecto, por ejemplo, acercando entre sí las ramas que tienen relación directa.

Nota: Cuando se elige esta opción, se muestra una explicación de uso debajo.


La forma se uso es simple: Se marca esta opción, se elige la rama que se quiere mover (solo hacia arriba/abajo, ya que izquierda/derecha es controlado por la fecha/hora de la rama según su columna), se mueve la rama con las flechas de cursor y se vuelve a desmarcar esta opción para que queden los cambios guardados.



Nota: Si no se llegara a ver todo el panel completo y apareciera recortado en altura, seguramente el problema sea la resolución de pantalla, que debería ser como mínimo de 1280x1024 para poder ver las opciones completas.


Búsqueda rápida


El cuadro superior-derecho permite escribir para hacer un filtrado en cuando se pulsa <Enter>.

Por ejemplo, si escribiéramos tarea-025, la vista anterior resaltaría en amarillo todas las ramas que contengan ese texto en su nombre, marcando la rama seleccionada en naranja, permitiendo la navegación por las mismas con las flechas de navegación.




Nota: Una búsqueda que a veces puede ser útil, es la búsqueda por changeset, que da un único resultado. En ese caso la forma de buscar es usand la nomenclatura cs:nn , por ejemplo para buscar el changeset 51, escribiríamos cs:51 <Enter>


Opciones del Explorador de ramas


Si hacemos click-derecho sobre una rama y elegimos la opción Explorador de ramas, podemos ver las siguientes opciones:




Opción: Ir a la base de la rama


Nos permite ir al changeset de la rama padre de donde se creó esta rama, y que es a donde apunta la flecha gris fina de cada rama.



Opción: Mostrar ramas seleccionadas en un nuevo diagrama


Si quisiéramos ver una rama (o varias) por separado, sin el ruido de las que no nos interesan, las podemos marcar con CTRL+Click, al igual que se hace para elegir varios archivos en el explorador de archivos, luego hacemos click-derecho sobre una de las ramas seleccionadas y elegimos la opción en cuestión.

Si eligiéramos las 2 ramas en amarillo del principio, se abriría una nueva vista filtrada así:




Opción: Mostrar ramas seleccionadas y relacionadas en un nuevo diagrama


Si quisiéramos ver una rama (o varias) y las  ramas directamente relaciondas por separado, las podemos marcar con CTRL+Click, al igual que se hace para elegir varios archivos en el explorador de archivos, luego hacemos click-derecho sobre una de las ramas seleccionadas y elegimos la opción en cuestión.

Por ejemplo, si quisiéramos ver las ramas relacionadas a la tarea-025 del primer ejemplo, con sólo seleccionar esa rama y eligiendo esta opción se abriría una nueva vista filtrada así:





Opción: Mostrar merges pendientes para las ramas seleccionadas en un nuevo diagrama


Si alguno entiende lo que muestra este diagrama y cuándo y porqué lo hace, por favor, que me lo explique :)




Opción: Mostrar diagrama personalizado de las ramas seleccionadas...


Esta opción muestra un cuadro de diálogo que permite indicar algunas de las opciones anteriores y algunas condiciones de filtrado adicionales:





Vista de Ramas


Esta es una vista de texto con información adicional como los comentarios de las ramas, muy útil en algunos casos, que también permite seleccionar ramas y operar con ellas para hacer Diff, Merge y otras operaciones.

Nota: La rama con el changeset actual siempre se muestra en negritas.


Esta es la vista plana, donde de paso se puede ver que no comentar las ramas quita información útil a la derecha:



Y esta es la vista jerárquica (solo para ramas Plastic nativas, las de GitHub y otros repositorios pueden no verse bien anidadas):



Misma vista, pero abriendo el panel derecho de detalles con el icono marcado en rojo:




Búsqueda rápida


El cuadro superior-derecho permite escribir para hacer un filtrado en tiempo real.

Por ejemplo, si escribiéramos tarea-025, la vista plana anterior filtraría todo lo que contenga ese texto en cualquiera de las columnas mostradas, comentarios incluidos:


Nota: Las columnas permiten ordenar la información mostrada, si se cliquea en ellas.



Vista de Changesets


Al igual que la vista de Ramas, esta es una vista de texto que permite ver rápidamente los changesets con sus comentarios, fecha de creación y otros datos, y que también permite seleccionar changesets y operar con ellos para hacer Diff, Merge y otras operaciones.



Búsqueda rápida


El cuadro superior-derecho permite escribir para hacer un filtrado en tiempo real.

Por ejemplo, si escribiéramos fidel, la vista plana anterior filtraría todo lo que contenga ese texto en cualquiera de las columnas mostradas, comentarios incluidos, y ese es otro motivo para escribir cosas útiles en los comentarios:


Nota: Las columnas permiten ordenar la información mostrada, si se cliquea en ellas.




Vista de Etiquetas


Esta es otra vista de texto que permite ver rápidamente las etiquetas con sus comentarios, fecha de creación y otros datos, y que también permite operar con ellas para hacer Diff, Merge y otras operaciones.



Búsqueda rápida


El cuadro superior-derecho permite escribir para hacer un filtrado en tiempo real.

Por ejemplo, si escribiéramos 1.1, la vista plana anterior filtraría todo lo que contenga ese texto en cualquiera de las columnas mostradas, comentarios incluidos:


Nota: Las columnas permiten ordenar la información mostrada, si se cliquea en ellas.



Vista de Shelves


Esta es otra vista de texto que permite ver rápidamente las etiquetas con sus comentarios, fecha de creación y otros datos, y que también permite operar con ellas para hacer Diff, Merge y otras operaciones.



Búsqueda rápida


Tiene el mismo funcionamiento que las demás vistas de texto.


Comentarios finales


Conocer todas estas vistas y opciones de filtrado, es fundamental para poder navegar por la información que brinda una herramienta SCM o DVCS y para poder realizar operaciones con la misma.

Poder hacer todo esto es una de las mayores ventajas que aporta trabajar con estas herramientas, donde la mayoría de opciones son prácticamente imposibles si se trabaja a la antigua usanza.

Esto es lo que permite poder manipular el código de una aplicación completa con un control total y a distintos niveles de detalle.


Hasta la próxima!

viernes, agosto 22, 2014

Nueva versión v2.4.26 de las herramientas Visual FoxPro 9 para PlasticSCM (Incluye FoxBin2Prg.exe v1.19.31)

Está liberada la versión v2.4.26 de las herramientas Visual FoxPro 9 para PlasticSCM, con los siguientes cambios:

  • Se ha mejorado el control de algunos errores y los mensajes mostrados
  • Se ha agregado el conteo de archivos procesados en la vista de Cambios Pendientes con los script específicos para esta vista



Estas herramientas son un grupo de scripts vbs y programas Visual FoxPro 9 que se configuran dentro de PlasticSCM para poder invocar a FoxBin2Prg (incluye solo el EXE) desde dentro de la interfaz de Plastic.

El README.txt explica como se configura en Inglés y Español.

Nota: Los fuentes del proyecto FoxBin2Prg y el historial de ambios, están en CodePlex, en este link.


Como actualizar las existentes:
Con descargarlas y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.


Link de descarga:
https://github.com/fdbozzo/foxpro_plastic_diff_merge


Saludos!

Nueva versión v1.19.31 de FoxBin2Prg (mejoras)

Está liberada la versión v1.19.31 de FoxBin2Prg con los siguientes cambios:

  • Limpieza de código basura en campo methods, normalmente puesto por programas como ReFox y otros. En un caso reciente de conversión de código antiguo originado en VFP6, se ha dado el caso de encontrar métodos inhabilitados ocultos en clases y forms, puestos por programas como ReFox o similares en sitios que el IDE de VFP no puede acceder ni usar. En estos casos, FoxBin2Prg limpiará esos restos de código inhabilitado para poder generar las versiones texto estilo-prg sin errores.
  • Agregada versión del EXE cuando se genera LOG de depuración. Este agregado es útil para cuando es necesario analizar un LOG generado por FoxBin2Prg, poder saber con qué versión de compilación se hizo.
  • Mejorado el reconocimiento de instrucciones #IF..#ENDIF cuando hay espacios entre # y el nombre de comando. En recientes conversiones de código antiguo originado en VFP 5 y posterior, se han encontrado comandos mal escritos que no dan errores de sintaxis, por lo que se deben aceptar. Por ejemplo: # IF o # ENDIF con espacios entre el símbolo # y el IF/ENDIF. Ahora se soporta este caso.
  • Ajuste de capitalización de los archivos origen. Hasta ahora sólo se ajustaba la capitalización de los archivos generados, y era necesario un ajuste manual extra con script para los archivos origen. Ahora se ajustan automáticamente los archivos origen de la conversión, evitando un paso manual extra.
  • Agregada nueva propiedad c_Language para conocer el lenguaje activo (EN,ES,DE,etc). Esta nueva propiedad pública es útil para poder consultarla externamente desde scripts u otros programas y poder saber qué lenguage compilado está activo por defecto. Lo usan algunos de los scripts de las Herramientas VFP 9 para Plastic, para poder mostrar algunos mensajes en Español o Inglés.



Como actualizar el FoxBin2Prg existente:
Con descargar el zip y reemplazar los archivos en el sitio que los hayan puesto antes es suficiente.


Link  de descarga:
https://vfpx.codeplex.com/releases/view/116407


 Saludos!

domingo, agosto 17, 2014

Cómo configurar las Herramientas de VFP 9 en Plastic


Por: Fernando D. Bozzo

Aunque esto está en el README.txt, lo transcribo aquí por comodidad.

Nota 1: No confundir estas herramientas (scripts) específicos para Plastic, con los scripts que vienen con el proyecto FoxBin2Prg y que son para el explorador de archivos de Windows, no para Plastic!


Nota 2: Donde diga <Path-a-FoxBin2Prg> o <Path-a-las-herramientas> poner el path donde copiaron las Herramientas VFP 9 para Plastic y FoxBin2Prg (es el mismo directorio para ambas)

Nota 3: Ojo que la configuración para Diff no es la misma que para Merge!


Antes de comenzar: Descarga de las Herramientas VFP 9 para Plastic


Configuración de DIFF en PlasticSCM


  • Clickear en el icono de Preferencias de PlasticSCM
  • Seleccionar "Herramientas Diff" y "agregar" esto:
    • Herramienta Diff externa:
      "<path-a-las-herramientas>\foxpro_plasticscm_dm.exe" "'DIFF' '@sourcefile' '@destinationfile' '@sourcesymbolic' '@destinationsymbolic'"
    • Patrón:
      .pjx;.vcx;.scx;.frx;.lbx;.mnx;.dbf;.dbc     (¡usar misúsculas!)
  • Clickear OK
  • Mover la extension agregada al inicio de la lista, para priorizarla



Configuración de MERGE en PlasticSCM


  • Clickear en el icono de Preferencias de PlasticSCM
  • Seleccionar "Herramientas Merge" y "agregar" esto:
    • Herramienta Merge externa:
      "<path-a-las-herramientas>\foxpro_plasticscm_dm.exe" "'PRESERVE_WS' '@sourcefile'"
    • Patrón:
      .pjx;.pjt;.vcx;.vct;.scx;.sct;.frx;.frt;.lbx;.lbt;.mnx;.mnt;.dbf;.fpt;.cdx;.dbc;.dcx;.dct     (¡usar misúsculas!)
  • Clickear OK
  • Mover la extension agregada al inicio de la lista, para priorizarla




Configuración de Custom "Open with..." en PlasticSCM



  • Click en el icono de Preferencias de PlasticSCM
  • Seleccionar "Abrir con... personalizado"

  • Click en "Añadir..." y completar los campos:
    • Nombre a mostrar:
      (VFP) Cambios Pendientes: Regenerar Binarios
    • Ruta completa del ejecutable:
      <Path-a-FoxBin2Prg>\PlasticSCM_VFP9_Pending_Changes_Regenerate_Binary.vbs
  • Click en Aceptar


  • Click en "Añadir..." y completar los campos:
    • Nombre a mostrar:
      (VFP) Cambios Pendientes: Regenerar versiones Texto
    • Ruta completa del ejecutable:
      <Path-a-FoxBin2Prg>\PlasticSCM_VFP9_Pending_Changes_Regenerate_Text.vbs
  • Click en Aceptar


  • Click en "Añadir..." y completar los campos:
    • Nombre a mostrar:
      (VFP) FoxBin2Prg
    • Ruta completa del ejecutable:
      <Path-a-FoxBin2Prg>\PlasticSCM_VFP9_FoxBin2Prg.vbs
  • Click en Aceptar


  • Click en "Añadir..." y completar los campos:
    • Display Name:
      Normalizar Capitalización de un archivo
    • Full path to the executable:
      <Path-a-FoxBin2Prg>\Normalize_FileNames.vbs
  • Click OK


  • Click en "Añadir..." y completar los campos:
    • Nombre a mostrar:
      (VFP) Todos los Archivos: Regenerar Binarios
    • Ruta completa del ejecutable:
      <Path-a-FoxBin2Prg>\PlasticSCM_VFP9_All_Files_Regenerate_Binary.vbs
  • Click en Aceptar


  • Click en "Añadir..." y completar los campos:
    • Nombre a mostrar:
      (VFP) Todos los Archivos: Regenerar versiones Texto
    • Ruta completa del ejecutable:
      <Path-a-FoxBin2Prg>\PlasticSCM_VFP9_All_Files_Regenerate_Text.vbs
  • Click en Aceptar




sábado, agosto 16, 2014

PlasticSCM: ¿Qué es nivelar un rama?

Por: Fernando D. Bozzo

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.


Hasta la próxima!

viernes, agosto 15, 2014

PlasticSCM: Sincronización con GitHub

Por: Fernando D. Bozzo

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 del primer 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.




Hasta la próxima!