jueves, marzo 13, 2014

FoxPro 9 y PlasticSCM: Como deshacer un changeset sin borrarlo

Por: Fernando D. Bozzo

Hay ocasiones en las que necesitamos deshacer un changeset porque algo salió mal, y en esta situación tenemos 2 alternativas:

1) Borrar el changeset
2) Hacer un merge substractivo

Si bien en ambos casos podemos alcanzar el mismo objetivo, hay motivos para no eliminar un changeset y en su lugar hacer un merge substractivo:

  • Si nuestro repositorio está sincronizado con un repositorio externo como GitHub, BitBucket u otro y el changeset que queremos deshacer ya está sincronizado, no podemos borrarlo, porque en cuanto sincronicemos nuevamente se volverá a restablecer como estaba
  • Si el changeset que queremos deshacer no es el último, sino uno intermedio, puede ser contraproductivo tener que deshacer todos los changesets posteriores solo por este, además en esos changesets posteriores podría haber muchos cambios bien hechos y por ahi solo queremos deshacer una sola operación o cambio de archivo que se realizó en el changeset en cuestión
  • Si queremos preservar el historial de todo lo hecho y en algún caso queremos volver a realizar los cambios que ahora vamos a deshacer
  • Si el changeset lo queremos deshacer solo temporalmente, porque contiene un cambio sin terminar y haya que entregar una versión del software sin el mismo
Estos y otros motivos, son suficientes para hacer un merge substractivo.


¿Cómo se hace esto?


Muy fácil, se seleccionan dos changesets con el ratón (click en el changeset de la izquierda, y luego ctrl+click en el changeset de la derecha), luego un click-derecho en cualquiera de los dos changesets y se verán solo dos opciones:

- Merge Avanzado
- Mostrar diferencias entre changesets seleccionados

Con "Mostrar diferencias" podemos ver cuál es la situación que se deshará. Si hay archivos eliminados, entonces se mostrarán, y si hay cambios hechos, también.





Con "Merge Avanzado" se abre un segundo menú donde una se las opciones es "Merge substractivo", se elige esta opción y luego se elige "Procesar merges":


Como se observa, lo que antes se mostraba como eliminado, ahora se volverá a agregar. Una vez procesado el merge estos cambios pasarán a ser Cambios Pendientes todavía sin confirmar, que en el Explorador de ramas se verá así:



El último paso, es comprobar visualmente en la vista de Cambios Pendientes de que es todo correcto, y confirmar los cambios haciendo checkin.

Nota:
En esta misma pantalla conviene confirmar si los tipos de archivo están siendo bien reconocidos por Plastic, como por ejemplo los archivos sc2, vc2, pj2, etc, que genera FoxBin2Prg (en este caso los 4 marcados), ya que podrían estar incorrectamente identificados como "bin" en vez de "txt". En el caso de haber archivos mal identificados, aquí podemos arreglarlo, haciendo click-derecho sobre el archivo de texto, eligiendo "Cambiar tipo de revisión" y luego "texto" (o binario, según corresponda), y luego sí procedemos al checkin. Esto mismo se puede hacer en la ventana de items.




Así se ve el merge substractivo una vez hecho el checkin:



Dejo aquí un video corto con el ejemplo completo.
http://youtu.be/G8QhIsPnQrQ


Hasta la próxima!


lunes, marzo 10, 2014

Nueva versión v1.19.16 de FoxBin2Prg (arreglos)

Por: Fernando D. Bozzo

Está liberada la versión v.1.19.16 de FoxBin2Prg con los siguientes cambios:

  • Arreglo bug vcx/scx: las propiedades pierden la visibilidad hidden/protected cuando no tienen valor asignado (Ryan Harris). Afecta a los binarios que tengan definidas propiedades así.
  • Arreglo bug vcx/scx: valor character con longitud >255 en propiedad de addobject, se regenera con tag <fb2p_value> incluido (Ryan Harris). Difícilmente se encuentren propiedades con esta longitud de valor asignado en tiempo de diseño, pero si las hay, se estaban restaurando con un tag <fb2p_value> incluido como parte del valor. Afecta a los binarios que tengan definidas propiedades así.
  • Arreglo bug vcx/scx: Al regenerar binario con procedimiento vacío hace que se cuelgue FoxPro al intentar modificar
  • Arreglo bug scx/vcx: Si la clase tiene un comentario multilínea, el binario generado se puede corromper (Tested on: Ffc\_frxcursor.vcx). Otra rareza encontrada en uno de los archivos de las FCC que vienen con Fox, una librería con una clase cuyo comentario es multilínea (tiene un pedazo de documentación pegado dentro!). Afecta a los archivos tx2 generados, y a los binarios regenerados desde éstos.
  • Arreglo bug: Si _memberdata contiene CR entre sus valores, esos valores pueden perderse al regenerar el tx2. Caso encontrado en un par de librerías de las FFC que vienen con Fox. Afecta a los archivos tx2 generados, y a los binarios regenerados desde éstos.
  • Arreglo bug: Los valores de las propiedades con espacios a la derecha pierden esos espacios Caso encontrado en un par de librerías de las FFC que vienen con Fox. Afecta a los archivos tx2 generados, y a los binarios regenerados desde éstos.
  • Arreglo de bug: cuando 2 o más métodos contienen el mismo nombre (ej: met y met2) se genera mal el tx2 (Ryan Harris). Afecta a librerías o forms que usen nombres de métodos contenidos dentro de otros nombres, por ejemplo, "mimetodo" esta contenido dentro de "mimetodo1" y dentro de "mimetodo2". Afecta a los archivos tx2 generados, y a los binarios regenerados desde éstos.

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!

Nueva versión v2.4.10 de las herramientas FoxPro 9 para PlasticSCM

Por: Fernando D. Bozzo

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

- Actualizada la versión de FoxBin2Prg a la versión v1.19.16


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.


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!

domingo, marzo 09, 2014

FoxPro 9: Modificando un componente que ya está bajo control de código

Por: Fernando D. Bozzo

En esta nota ya partimos de la base de un componente que ya está bajo control de código, y que lo queremos modificar y subir nuevamente (proteger)

Los pasos son los siguientes:

1) Hacemos los cambios necesarios en nuestro form y lo cerramos


2) CLEAR ALL / CLOSE ALL en la ventana de comandos


3) Vamos a la vista de Cambios Pendientes en Plastic y la refrescamos




4) Seleccionamos cualquier archivo (no directorio), click-derecho y seleccionamos:
> Abrir / Abrir con (VFP) Cambios Pendientes: Regenerar versiones Texto


5) Se mostrará un mensaje de confirmación y se refrescará la vista automáticamente:



6) Ponemos un comentario describiendo lo hecho (es importante!) y hacemos Checkin de los cambios.
 Ojo: Prestar atención a lista de cambios que se muestra siempre, ya que indica qué se agregará, qué se modificará y qué se borrará.





Ups! Me da error!


Si al intentar realizar la conversión a texto o a binario sale el mensaje "Error 1705, Denegado el acceso al archivo", es porque el componente está abierto o fue modificado y no se hizo el CLEAR ALL / CLOSE ALL correspondiente:




Así que la solución es fácil: Se repite desde el punto 2 antes comentado.



¿A que es fácil? ;-)


Nota: Aunque el ejemplo comentado fue sobre un form, esta misma operativa se aplica al resto de binarios: clases, reportes, menus, el proyecto pjx, etc.


También puede interesarte:
PlasticSCM: Hice un checkin erróneo de un archivo nuevo ¿cómo lo arreglo?


FoxPro 9: Creando un componente y añadiéndolo al control de código PlasticSCM

[Esta nota fue extraída desde la nota sobre ramas, para mantenerla por separado]

Por: Fernando D. Bozzo

Todos sabemos crear un form, pero para agregarlo al control de código tenemos que hacerlo con cuidado y siguiendo unas sencillas reglas para evitar que el SCM nos dé problemas luego.

1) Se crea el form en una sesión de FoxPro dentro del directorio elegido para el espacio de trabajo:

MODIFY FORM forms\frm_test1

2) Se programa dentro del mismo lo que haga falta y al terminar se graba, cierra y CLEAR ALL (siempre!)

3) Se abre la GUI de Plastic y se va al vista de Items, seleccionando la opción Items del panel izquierdo, se pulsa el icono para refrescar la lista de archivos, se ubica el form (el scx, no el sct!) y con click-derecho sobre el mismo se elige "abrir / Abrir con FoxBin2Prg", lo que genera la vista texto y ajusta la capitalización de los binarios origen (SCX/SCT => scx/sct):



(NOTA: El punto 4 fue quitado porque ya no es necesario)

¿Porqué importa el ajuste de la capitalización de los archivos?


Tener la capitalización bien ajustada es fundamental para que luego no haya problemas con GitHub o que incluso el mismo Plastic los tome como archivos distintos.


Para quienes solo hayan trabajado con Windows, esto es raro, pero en otros sistemas operativos (Linux, Unix, Mac...) el mismo nombre con distintas capitalizaciones de mayúsculas/minúsculas lo trata como archivos distintos y por lo tanto se muestran ambos!, cosa que Windows no puede.

Nota: Una posible mejora en FoxBin2Prg para evitar el paso de regenerar el binario siempre, como el paso anterior, sería que haga un ajuste automático de capitalización de los archivos origen y no solo de los archivos destino, lo que dejaría todo el proceso en un solo paso.


5) Ahora que el archivo está normalizado (vean la capitalización en la captura de abajo), ya se puede agregar al control de código fuente, cosa que se hace una sola vez. Observen que la columna Estado muestra "Privado" para estos archivos nuevos. Esto es porque esos archivos todavía no están controlados por Plastic.

Prestar especial atención a los dos pasos anteriores de generación de texto y luego binario, porque si esto no se hace correctamente, luego puede pasar que se suba al SCM un archivo a medias o que no coincida con la versión texto, o que directamente no la tenga o que esté mal capitalizado, lo que es muy probable que pueda dar algún error al sincronizar con GiHub (solo si se configuró esta sincronización, que normalmente no es requerida), y no olvidarse del archivo del proyecto (PJX) que también debe convertirse!



En la imagen de arriba pueden observar que los archivos que agrego el control de código son los del formularios más la versión texto generada antes, y que los tres están correctamente capitalizados.


6) Finalmente, nos cambiamos a la vista de "Cambios Pendientes" (en el panel izquierdo), escribimos un comentario descriptivo de lo que hicimos, confirmamos visualmente (o sea, miramos) que los archivos que vamos a subir son los que deben ser (o sea, que no sean un .BAK u otra cosa), también verificamos si en la lista figura que se van a eliminar archivos (por las dudas) y si nos parece que todo está bien, pulsamos el botón Checkin.

Observen como los archivos tienen Estado "Añadido":


Felicitaciones! Han hecho su primer Checkin en Plastic! :-)


También puede interesarte:
FoxPro 9: Modificando un componente que ya está bajo control de código
PlasticSCM: Hice un checkin erróneo de un archivo nuevo ¿cómo lo arreglo?

viernes, marzo 07, 2014

PlasticSCM: Hice un checkin erróneo de un archivo nuevo ¿cómo lo arreglo?

Por: Fernando D. Bozzo

A todos nos puede pasar que estamos trabajando en algo, y en un momento dado queremos proteger los cambios, entonces vamos al SCM, elegimos los archivos y hacemos checkin.... pero luego nos damos cuenta de que cometimos un error, ¿cómo lo arreglamos?

   Si el error detectado es de capitalización de un archivo recién agregado, pero al cual todavía no hicimos checkin, es muy fácil: Ir a la ventana de Cambios Pendientes y seleccionar el botón "Deshacer cambios". Problema resuelto, se soluciona el problema de capitalización haciendo la conversión texto/binario que ya comenté en el punto 3 y 4 de la otra nota, y se repite el proceso de agregar el archivo.

   Si el error detectado es de capitalización de un archivo agregado y que además se le hizo checkin, entonces habrá que hacer una copia del mismo (en un zip por ejemplo) y eliminar el último changeset creado, así:


1) Seleccionamos el changeset anterior con click-derecho:


2) Elegimos la opción "Apuntar workspace a este changeset":



2.b) ¿Muestra un error?: Si les muestra un error como el de la imagen, pueden elegir entre las opciones que ven en la imagen, y que ahí mismo están explicadas:




3) Hacemos click-derecho en el changeset a borrar (siempre es el último) y elegimos "Borrar changeset":


4) Y listo, el changeset fue borrado y el nuevo changeset actual es el anterior:


5) Finalmente, como se ha borrado un changeset que en este caso consistía en archivos agregados al SCM, esto implica que Plastic los borrará del directorio de trabajo, y por eso hicimos el ZIP en un paso anterior. Simplemente se vuelven a descomprimir los archivos, se procesan con FoxBin2Prg (solo si son binarios Fox) pasándolos a texto y binario nuevamente, se comprueba la capitalización y se vuelven a agregar al control de código.


Esto también se puede hacer cuando se protege un cambio que no se quiere guardar, pero lo ideal es solo hacer el checkin cuando se tiene certeza de que lo que se sube es correcto.


Video de ejemplo:

FoxPro 9: Deshacer Merge de 2 ramas en PlasticSCM




Importante:
Para evitar estos inconvenientes, es mejor verificar visualmente la capitalización de los archivos justo antes de que se vayan a proteger, y no olvidar que cualquier form, clase, etc, que se haya modificado, se debe pasar primero a texto y luego del texto se debe pasar a binario otra vez, ya que en estos pasos también se hace el ajuste de la capitalización.

Otra cosa a estar atento es no subir cualquier archivo, es decir, el control de código fuente (SCM) es justamente para eso, para controlar los archivos de programa que hacemos, y no para proteger los archivos temporales (tmp) o los backup (bkp) u otro tipo de archivos que no tienen nada que ver con nuestro desarrollo.

Incluso es conveniente guardar la versión texto de las tablas (archivos DB2) y bases de datos (archivos DC2) generados con FoxBin2Prg, pero no guardar las tablas con datos, porque si no el espacio destinado para el código se agotaría bastante rápido. Recordar que todo esto se guarda en una base de datos de Plastic que se puede elegir entre la que viene por defecto  y que sirve para pequeños desarrollos o desarrollos personales (SQL Server CE - 4 GB por repositorio/proyecto), u otras bases de datos más potentes como SQL Server full, MySQL, Oracle u otras.


Nota Relacionada:
FoxPro 9 y PlasticSCM: Como deshacer un changeset sin borrarlo




jueves, marzo 06, 2014

PlasticSCM: Cómo crear una rama para comenzar a trabajar

Por: Fernando D. Bozzo

En esta nota vamos a ver cómo crear una rama en PlasticSCM, pero antes de hacerlo es necesario saber qué es un rama.
Antiguamente se usaban directorios para crear copias del sistema o de ciertos componentes con determinados cambios. Por ejemplo, si se tiene un form con una pageframe y una página, se agrega otra página y se quería guardar ambas versiones por las dudas, entonces se creaba un directorio para la versión de 1 página y otro directorio para la versión de 2 páginas, y en cada uno se copiaban los forms correspondientes.

Esto tiene el inconveniente de que no es práctico, la cantidad de directorios y copias va creciendo y es fácil perderse entre tantas copias. Además que no hay forma de mezclar los cambios de un directorio con los de otro.


Las ramas

Una rama se usa para lo mismo que se usaban los directorios con distintas versiones, mantener una serie de modificaciones relacionadas a uno o varios componentes. Qué parámetro se use para establecer esa relación puede variar para cada uno, pero lo ideal es tener una rama por usuario y por tarea, ya que la idea es no trabajar nunca sobre la rama principal directamente, hacerlo siempre sobre ramas independientes.


El changeset (o "juego de cambios")


En Plastic el icono de la casa indica un punto en la historia de modificaciones que fueron guardadas con check-in y es el equivalente a lo que antes era el directorio con una copia con cierta modificación particular, por eso es importante hacer un check-in cada vez que se  complete alguna funcionalidad, y antes de pasar a la siguiente.

Para seleccionar un "changeset" se hace click-derecho en el changeset al que se quiere ir, y se elige la opción "Apuntar workspace a este changeset", o sea, se cambia el área de trabajo a ese punto de la historia del proyecto.

Pero, ¿qué ocurre cuando se cambia de changeset realmente? Lo voy a explicar con directorios.
Imaginen que tienen un directorio llamado "c:\mi_sistema_actual" que contiene 3 archivos:

c:\mi_sistema_actual => a.txt, b.txt y c.txt

Ahora se cambian a una copia más vieja que llamaron "c:\mi_sistema_feb_2012" donde solo había 2 archivos:

c:\mi_sistema_feb_2012 => a.txt y b.txt

El archivo c.txt no existe aquí porque fue agregado más recientemente en "c:\mi_sistema_actual", entonces al cambiarse a este directorio es lógico no ver ese archivo, pero si nos volvemos a cambiar al otro, entonces sí que lo vemos.

Pues en Plastic es parecido, pero ocurre todo esto en el directorio que se ha elegido como "workspace", y recalco lo de "espacio de trabajo" porque durante toda la vida del proyecto, todos los cambios se harán en este directorio o workspace. Lo que hace Plastic es "reemplazar" los archivos "controlados" por los archivos del changeset que elijamos, borrando del workspace (directorio) los archivos "controlados" del changeset actual y descargando del servidor los archivos "controlados" del changeset elegido.

No hay que asustarse cuando hablo de "borrar", ya que esto solo lo hace con los archivos que sabe que luego puede recuperar, y por eso los archivos "no controlados" se llaman "privados" y no se tocan. Los archivos privados para Plastic es como si no existieran, aunque los muestra en la ventana de items para que podamos agregarlos al control de código si queremos, y que desde ese momento cambien al estado de "controlados".


Creando una rama


Vamos a crear una rama para que cada uno pueda realizar sus pruebas o su trabajo, y no entre en conflicto con lo que hagan los demás desarrolladores.
Como origen de esta rama se debe seleccionar el changeset desde el cuál se quiere partir, que en general es el último, pero también puede ser otro anterior.


1) Abrimos la vista del Explorador de Ramas (panel izquierdo), hacemos click-derecho en el changeset elegido para bifurcar y seleccionamos "Crear rama desde este changeset"


Figura 1


2) Luego le damos un nombre a la rama. Normalmente este nombre debería ser el de la tarea que se comenzará, algo como "nuevo-form-articulos", "petición-02332" o "tarea-nnn", pero para el caso de las prácticas que estamos haciendo lo voy a nombrar como "usuario" donde cada uno debe reemplazar "usuario" por su usuario:


Figura 2


3) Finalmente podemos ver la nueva rama con la casita, ya que en la pantalla anterior estaba marcado por defecto la opción "Apuntar workspace a esta rama":

Figura 3


Y ahora sí, teniendo cada uno su propia rama, se puede comenzar a trabajar en la tarea, lo que normalmente es abrir una sesión de FoxPro en el directorio del workspace y comenzar a trabajar.



Comprobación de la ruta de nuestra rama


Cuando se crea una rama, queda una flecha gris señalando el origen de datos de la misma, que en este caso coincide con el changeset de origen, y el panel derecho muestra su ruta completa:

Figura 4


Cuando se crea una rama de otra que todavía no tiene nada nuevo, la flecha gris sigue señalando el origen de datos de la misma, pero en este caso el origen de datos no coincide visualmente con el changeset del ejemplo anterior elegido para hacer la rama, lo que puede confundir inicialmente, pero si observamos en el panel derecho, la ruta es correcta a pesar de lo que marca la flecha gris:

Figura 5


Una vista útil para esto es la llamada "Ramas" (panel izquierdo), donde se muestra la relación entre las ramas en forma de texto, y se resalta en negrita la actual (que en la vista anterior muestra el icono de la casa).

Desde esta vista también se pueden crear sub-ramas, y en algunos casos en los que en el Explorador de Ramas no se puede clickear o seleccionar la rama buscada, por ejemplo, por estar tapada por otra, esta es la única forma de poder hacerlo sin equivocarse.

Figura 6


Bueno, ya es hora de practicar un poco!


En este punto les puede interesar:
FoxPro 9: Creando un componente y añadiéndolo al control de código PlasticSCM
FoxPro 9 y PlasticSCM: Como deshacer un changeset sin borrarlo

(Sigue en: "PlasticSCM: Hice un checkin erróneo de un archivo nuevo, ¿cómo lo arreglo?")