PlasticSCM: Cómo trabajar en FoxPro 9 con ramas por tarea

Por: Fernando D. Bozzo

En esta ocasión vamos ver una forma de trabajar con ramas, que sirve tanto para uno como para varios desarrolladores. Si no sabes lo que es una rama, antes de seguir te convendría leer el artículo anterior sobre este tema: PlasticSCM: Cómo crear una rama para comenzar a trabajar


La norma básica a seguir es muy simple: Jamás hacer cambios en la rama principal!. Nunca!


(Bueno, las únicas excepciones son el primer add/checkin con un archivo README.txt, que recomiendo absolutamente, y la subida del proyecto FoxPro 9, que será el segundo add/checkin)

A partir de quí, lo único que se debe hacer en la rama Principal es el merge final de las demás ramas para etiquetar la versión. Todo el trabajo se debe hacer en ramas derivadas de la principal.

Antes de continuar un aviso: Para todo lo que sigue voy a asumir que la estructura de directorios de tu proyecto está encapsulada de forma que en la raíz está el proyecto (pjx) y el programa principal, y en los subdirectorios están los componentes, y que no se referencian componentes externos a esta estructura de directorios, por ejemplo apuntando a otra aplicación o ubicación de librerías como las FFC de FoxPro. Si esto no se cumple entonces no podrás obtener todas las ventajas de trabajar con control de código por las dependencias externas que tengas y tal vez de convendría leer antes: Crear un proyecto FoxPro: ¿por dónde comenzar?

Pasos a seguir para comenzar a trabajar con un proyecto nuevo

En este caso tenemos un proyecto FoxPro 9 que se crea desde cero y que desde el mismo inicio se pone bajo control de código.

• Crear el directorio en el disco donde se alojará el proyecto FoxPro 9 con su estructura de directorios
• Crear el repositorio Plastic para el proyecto
• Crear el workspace asociado al directorio para poder actualizar el repositorio
• Crear el archivo REAME.txt y subirlo a la rama Principal (agragar y check-in)
• Agregar el proyecto y subirlo a la rama principal, para dejar definida la estructura de todo el trabajo posterior (conertir archivos a texto/binario, agregarlos al control de código y check-in)
• Crear una rama por desarrollador desde el nuevo changeset recién creado
• Ya se puede comenzar a trabajar en la rama, tanto agregando un nuevo componente FoxPro al control de código, como modificando un componente FoxPro que ya está bajo control de código.
• No olvidar actualizar el PJX y generar su versión texto PJ2

Cómo agregar un proyecto existente al control de código para trabajar

Este es el caso típico para muchos desarrolladores que tienen proyectos hechos, y que ahora deciden meterlos en control de código para continuar trabajando de esta forma.
Los pasos para agregar un proyecto FoxPro existente al control de código está explicado en este artículo.
Para comenzar a trabajar con este proyecto FoxPro ya controlado, ver el siguiente punto.

Pasos a seguir para comenzar a trabajar con un proyecto existente

En este caso tenemos un proyecto FoxPro 9 que ya estaba bajo control de código fuente previamente, por lo que los nuevos desarrolladores solo deben unirse para tener lo último, crearse sus ramas y comenzar a trabajar en ellas, por lo que deben:

• Crear el directorio en el disco donde se alojará el proyecto FoxPro 9 (ojo, el directorio vacío!)
• Crear el repositorio Plastic para el proyecto
• Crear el workspace asociado al directorio para poder actualizar el repositorio
• Sincronizar el repositorio Plastic local con el repositorio remoto (esto se bajará el proyecto con archivos y directorios)
• Crear una rama personal de desarrollo desde el último changeset de la rama Principal
• Ya se puede comenzar a trabajar en la rama de desarrollo

Ejemplo de la rama de desarrollo v1.19.17 de FoxBin2Prg, que se creo a partir de la última versión v1.19.16 (círculo verde) de la rama Principal /main. Al finalizar se hará merge de la v1.19.17 de desarrollo en la rama principal nuevamente y se etiquetará la nueva versión como v1.19.17

Trabajo en ramas cuando se trabaja en solitario

Este caso es el que uso para trabajar en FoxBin2Prg, y es el modo de trabajo mínimo recomendado.

Se basa en tener:

• La rama principal (/main) donde solo se hará merge y se etiquetarán las versiones
• La rama secundaria para desarrollar
• Alguna rama puntual para solucionar incidencias solamente

Pantallazo de un momento del historial de FoxBin2Prg
(click en la imagen para agrandarlo):

Como puede verse en la captura anterior, en la versión v1.15 de la rama principal hice una rama secundaria de desarrollo para trabajar en el soporte de los menús (MNX) que llamé "Soporte_MNX" (la tarea a realizar) y que luego se convertiría en la versión v1.16.

Mientras estaba trabajando en esta tarea descubrí un error en el soporte OLE de los forms y clases, lo que debía arreglar y promocionar cuanto antes, pero sin incluir nada del nuevo desarrollo. Y es en ese momento que abro una nueva rama desde la v1.15 para hacer el parche v1.15p1
Se puede ver gráficamente que con el arreglo hecho en ese parche (un solo changeset) luego hice un merge en la rama principal, que hizo la versión v1.15p1 pública y también hice un merge en la rama de desarrollo del Soporte_MNX, ya que de otra forma si no lo hiciera así, en la siguiente versión estaría incorporando nuevamente el error que había solucionado.

Al finalizar el trabajo en esta tarea, hice el merge final en la rama principal, que etiqueté como v1.16 pública e hice una nueva rama para comenzar a trabajar en el soporte para Proceso en modo Batch. En este punto Fidel Charny me reportó una incidencia sobre el posicionamiento del menú, pero esta vez en vez de crear una rama aparte para el parche, lo mezclé en la tarea actual, en el segundo changeset de "ProcesoEnModoBatch" y liberé todo junto al día siguiente como versión v1.17. Esto lo hice así porque tanto el desarrollo de la tarea como el parche los hice en un corto período de tiempo (1 día) y no valía la pena separarlos en versiones distintas.

Sobre la conveniencia de crear un parche y versionarla por separado solo con los arreglos o hacer los arreglos dentro de la rama de desarrollo para sacar todo junto en la siguiente versión, todo depende del tipo de desarrollo que se esté haciendo y de los tiempos que se manejen.

Para un programa como FoxBin2Prg, cualquiera de las dos formas de trabajo es válida porque es un conversor y no un aplicativo comercial, y en este caso el baremo que usé es de fechas: Si el desarrollo que estaba haciendo iba para largo y surgía algún reporte de bugs en medio, no podía dejar colgados a todos con el error hasta que termine el desarrolo actual, por lo que lo conveniente era sacar y versionar un parche por separado para luego poder seguir con el desarrollo actual. Pero si el desarrollo iba a ser rápido y surgía algún reporte de fallo, entonces sí hacía el arreglo en la rama de desarrollo actual y versionaba todo junto.

Como ahora el desarrollo de FoxBin2Prg esta terminado, está en etapa de mantenimiento, por lo que las ramas que se hacen son para corregir fallos e incorporar optimizaciones.

Trabajo en ramas cuando se trabaja en equipo

Cuando se trabaja en equipo, el desarrollo es similiar a trabajar en solitario, con la diferencia de que habrá una rama por cada desarrollador, y que en general los desarrolladores harán el merge en una rama de Integración, que en el ejemplo de la imagen de abajo es /main/TESTS, y en esa rama es donde irán integrando funcionalidades terminadas.

En esta rama de Integración no se deben subir cambios incompletos nunca, ya que esta rama debería ser lo bastante estable como para que el resto de desarrolladores puedan actualizar sus propias ramas desde la misma, con bastante seguridad en que no comenzarán a tener errores provocados por una subida inconclusa o errónea.

Convendría que se defina la figura del Integrador Principal, que sería la persona a cargo de hacer la revisión final del código que se integrará y los merge de las ramas de Integración en la rama principal una vez concluida la revisión. Esta figura es muy importante en el ciclo de desarrollo, ya que tiene la responsabilidad de integrar todos los desarrollos en la rama principal.

Durante esta revisión, el Integrador inspecciona las diferencias en el código de la rama de Integración (no en la rama de cada desarrollador!) usando la herramienta de Diff, para buscar posibles problemas o cosas mejorables y detectarlas antes de que se suban a la release definitiva en la rama Principal.


Pantallazo de un proyecto con su rama principal, su rama de Integración y dos desarrolladores Dev_1 y Dev_2:

Sobre esta forma de trabajar, ya había publicado un video.

Como puede verse en la imagen de arriba, cada desarrollador va trabajando en su rama y cuando tiene una funcionalidad terminada puede hacer una de dos opciones:

• La integra con un merge en la rama de Integración, y acto seguido se actualiza su propia rama desde la de Integración para tener el trabajo de los demás. (Se puede ver que Dev_1 hizo esto en los dos primeros changesets)

• O se baja primero lo de la rama de Integración en la rama propia con un merge y luego, con todo ya intgrado en su rama, hace otro merge en la rama de Integración desde la propia. (se puede ver que Dev_2 hizo esto en su segundo y tercer changeset)

Como recomendación personal, yo creo que la segunda forma de integrar es la mejor y más segura, ya que cada uno se está Integrando en la rama propia lo que hay en la rama de Integración, con lo cual si surgieran conflictos, se resolverían en la propia rama y no se afectaría a nadie si esto se hiciera mal. Además de que esto permite que una vez realizada esta actualización local se puedan probar los cambios integrados y corregir posibles errores antes de hacer el merge nuevamente en la rama de Integración, y así se tiene cierta seguridad sobre lo que se sube, ya que en el peor caso, si surgen errores en las pruebas locales (rama propia), nadie más estará afectado aunque se actualice desde la rama de Integración.

Si se hiciera al revés (merge a Integración y posterior merge a rama propia), se corre el riesgo de que se haga algo mal durante la Integración dejando esta rama inestable, y el problema es que, aunque se detecte en las pruebas posteriores, como esta rama es pública para el resto de desarrolladores, un error puede provocar que los demás que se actualicen se les propague a sus propias ramas antes de que se pueda corregir el error, lo que puede tomar un buen rato.

Trabajo en ramas con sistemas complejos y varios desarrolladores

Este escenario es similar al anterior, pero en este caso pueden haber varias ramas intermedias para distintas funcionalidades simultáneas, lo que crea un diagrama más complejo, y en el que la figura del Integrador Principal es imprescindible, ya que es quien debe conocer qué desarrollos deben integrarse en la versión actual o cuáles son para la próxima versión.

La siguiente imagen es una simulación de lo que puede ser un sistema complejo, formado por dos proyectos cortos, cada uno con dos desarrolladores, en los que se harán dos funcionalidades distintas que confluirán en la rama de Integración y de ahí a la rama principal en la versión etiquetada como v2.0, y de un proyecto a medio plazo, también con dos desarrolladores, que se va actualizando con la release principal, pero que todavía debe continuar desarrollando y por eso no hace merge en la principal.

(Click en la imagen para agrandar)

Cuando ese proyecto de mediano plazo se deba integrar, se deberá crear primero una nueva rama de Integración que salga de la última release disponible (por ej: de la v4.0), y deberá integrar sus cambios allí para poder realizar pruebas y certificar el funcionamiento, antes de que se integre en la rama Principal.

Recomendaciones finales

Como se ve, dependiendo del tipo de proyecto a realizar, el trabajo en ramas ayuda mucho si se usa adecuadamente. Dejo algunas recomendaciones para tener en cuenta, que están basadas en las buenas prácticas y en la experiencia de varios proyectos durante bastante tiempo:

• En los componentes usar rutas relativas, nunca rutas absolutas. Esto permitirá que el proyecto sea portable e independiente de la ruta que se use para trabajar
• Para un proyecto compartido conviene predefinir y usar el mismo directorio entre desarrolladores para evitar diferencias en el pjx, que si no a cada desarrollador le detectará un directorio distinto, el cuál aceptará y esto generará una nueva diferencia innecesaria
• Hacer uso extensivo de las buenas prácticas de programación (encapsulación, refactorización, etc).
• Como mínimo se debería respetar una nomenclatura de objetos, como la sugerida por la ayuda de FoxPro. Esto no solo permite que el código se auto-documente, sino que facilita los merge manuales y maximiza los automáticos que no requieren intervención
• Usar FoxPro desde el directorio raiz del proyecto (workspace) y no cambiar la sesión a otros directorios (set default to <dir> o cd <dir>) ya que esto puede provocar problemas y bloqueos en el SCM cuando se quiera hacer un checkin o cambiar a otro changeset
• Cerrar siempre los forms, proyectos, clases y programas abiertos, y hacer CLEAR ALL antes de ir al SCM a realizar alguna tarea.
• Un bloqueo en algún archivo controlado por el SCM puede provocar un error en el checkin o que impida poder regenerar las versiones texto o binario con FoxBin2Prg y que en consecuencia se suban archivos des-sincronizados entre sí, como un binario sin su tx2 o viceversa

Hasta la próxima!

PlasticSCM: Agregando un proyecto FoxPro 9 al control de código fuente

Por: Fernando D. Bozzo

Es muy probable que tengamos proyectos que no están bajo control de código con un SCM, tanto porque sean antiguos proyectos, como porque consideramos que no ameritaban estar controlados o simplemente porque recién se está comenzando en este mundo del control de código.

Por el motivo que sea, tenemos uno o varios proyectos que queremos controlar con el SCM, así que vamos a ver un ejemplo de los pasos y configuraciones desde cero para hacerlo, asumiendo que que ya tenemos Plastic instalado y configurado.

Para el ejemplo voy a usar el proyecto FoxUnit, que es uno de los proyectos Open Source de VFPX en CodePlex para hacer Unit Testing (testing automatizado de código) que suelo usar frecuentemente, y que lo tengo en el directorio c:\desa\FoxUnit:

Como se puede observar en la captura anterior, hay archivos temporales, restos de pruebas y los archivos nos están normalizados (capitalizados), por lo tanto el primer paso es hacer esa normalización, usando click-derecho en el nombre del directorio de FoxUnit, y eligiendo la opción "Enviar a" y luego "Normalize_FileNames.vbs", que es uno de los scripts incluidos en las herramientas FoxPro 9 para Plastic.

Una vez ejecutado, los archivos quedan así:

Ahora que tenemos los archivos normalizados, vamos a crear un repositorio llamado FoxUnit, con un workspace llamado igual, ya que tanto el directorio como el proyecto ya se llaman así. La creación del repositorio y workspace ya los expliqué en el artículo de Instalación de Plastic, la única diferencia es que si Plastic ya está instalado y se quiere crear un nuevo repositorio y workspace (en ese orden), se deben seleccionar las opciones del pabel izquierdo, dentro de "Repositorios & Workspaces"

Hay dos archivos de configuración para Plastic que se deben crear en todos los proyectos que se quieran controlar, y que son "filetypes.conf" e "ignore.conf"

El archivo de configuración filetypes.conf

El archivo "filetypes.conf" sirve para indicarle a Plastic el tipo (texto/binario) de ciertos archivos que por no ser estándares pueden ser reconocidos incorrectamente. Por ejemplo, todas las extensiones texto de FoxBin2Prg, el config.fpw de FoxPro y algunas otras, por defecto se suelen reconocer como binarios. El tipo de archivo se puede ver en las vistas de Items y Cambios Pendientes, en la columna "tipo".

Para FoxPro, el filetypes.conf suele tener este contenido:

# PlasticSCM custom file types.
# Syntax: <extension>:<type>
# Type can be 'txt' or 'bin'.
# Examples:
#     .cpp:txt
#     .jpg:bin
.cfg_:txt
.cfg:txt
.fpw:txt
.prg:txt
.pj2:txt
.vc2:txt
.sc2:txt
.fr2:txt
.lb2:txt
.db2:txt
.dc2:txt
.mn2:txt

Este archivo puede estar a nivel de repositorio o a nivel del sistema. Si está a nivel de repositorio, se debe poner en la raíz del workspace, y si es a nivel del sistema, suele estar en el directorio <PerfilDelUsuario>\Configuración local\Plastic5
Si se pone a nivel del repositorio (lo recomendable), también es útil ponerlo dentro del control de código, para que los desarrolladores que se unan al proyecto tengan automáticamente la misma configuración y así no deben volver a hacerla cada vez.

El archivo de configuración ignore.conf

El archivo "ignore.conf" le indica a Plastic qué archivos no queremos ver en las vistas de Items y Cambios Pendientes. Es un filtro visual, y al igual que el filetypes.conf, puede estar a nivel de repositorio o de sistema, y en las mismas ubicaciones ya comentadas.


Para FoxPro, el ignore.conf suele tener este contenido:

*.FXP
*.LNK
!/_iniciar aqui.lnk
*.SCC
*.TMP
*.BAK
*.ZIP
*.7Z
*/FXUResults.*
*/FXUPersist*.*
.plastic
.git

Es importante conocer su sintaxis, ya que permite hacer cosas muy útiles como ocultar ciertas extensiones pero mostrarlas en un directorio particular. La sintaxis permite indicar:

• Una extensión (ej: .fxp)
• Un archivo (ej: foxuser.dbf)
• Un archivo en una ruta específica relativa a la raíz del workspace (ej: /forms/unarchivo.xml)
• Un directorio (ej: .git)
• Una negación de las reglas generales que se aplicarán a un archivo en una ruta específica (ej: !/_Iniciar aqui.lnk)

Importante: Notar que las barras de directorio no son las de Windows (\), sino el símbolo dividido (/)

Este archivo también se puede actualizar desde la GUI de Plastic, en la vista de Items y de Cambios Pendientes, haciendo click-derecho sobre un archivo y eligiendo "Añadir a la lista de cambios ocultos" donde se mostrarán 3 opciones:

• archivo.ext
• .ext
• /ruta_absoluta/archivo.ext

Agregar el proyecto FoxPro a control de código

Al fin, ya tenemos todo preparado, configurado y normalizado para agregar el proyecto, por lo que regeneramos las vistas de texto, regeneramos los binarios, agregamos el README.txt y posteriormente agregamos todos los archivos relevantes, es decir, todos menos los archivos temporales o archivos de pruebas que no formen parte del proyecto:



Generación de los archivos de texto (tx2):

Agregado del README.txt:

Checkin del README.txt con un comentario:

El Explorador de ramas muestra el segundo changeset (el primero siempre es vacío):

Agregado el control de código de los archivos del proyecto y los tx2 generados:

Comentario de checkin y checkin final:

El Explorador de ramas muestra el tercer changeset (al anterior es el README.txt y el primero siempre es vacío):

Y ya está. A partir de aquí es crear ramas para comenzar a trabajar en ellas.


Hasta la próxima! =)

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!

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!

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?