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!

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!

Reglas mínimas y buenas prácticas de programación

Por: Fernando D. Bozzo

Las reglas que se indican a continuación, son buenas prácticas de programación que sirven, no sólo para trabajar con control de código fuente, sino para toda la programación en general.

Aunque para algunos sea obvio, para otros no lo es tanto, así que es mejor explicar los motivos de esto.

¿Qué son y para qué sirven las buenas prácticas?

Las buenas prácticas no existen desde siempre, sino que se fueron desarrollando como resultado de la experiencia común de muchos desarrolladores y empresas dedicadas al desarrollo de software, como Microsoft y otras.

En esas experiencias se han pasado muchas veces por situaciones conflictivas, que luego de haber identificado fallos o problemas comunes, y luego de haber analizado los motivos que llevaron a ellos, se han ido perfeccionando ciertas prácticas que minimizan la posibilidad de los mismos.

Otra ventaja de las buenas prácticas, es que tienen a facilitar el mantenimiento del código, no solo por la persona que lo hace, sino por otros, lo que permite "normalizar" la forma de hacer las cosas, bajar los tiempos de desarrollo y maximizar la eficiencia.

Finalmente, el uso de estas normas minimiza los problemas y las diferencias a la hora de tener que mezclar el código de dos desarrollos sobre los mismos componentes (llamado merge), aumentando la posibilidad de que sea automático y no requiera intervención manual.

Buenas prácticas de programación

La siguiente lista de recomendaciones es lo mínimo que conviene tener en cuenta en todos los desarrollos, tanto trabajando en solitario como en equipo.



1. Convención de nomenclatura de variables (VFP)

Está detallada en la ayuda de FoxPro y en el MSDN de Microsoft

Ejemplos:
Parámetros => tcCadena, tnNumero, tdFecha, tlBoolean, taArray, toObjeto
Variables Locales => lcCadena, lnNumero, ldFecha, llBoolean, laArray, loObjeto
Variables Privadas => pcCadena, pnNumero, pdFecha, plBoolean, paArray, poObjeto
Variables Publicas => gcCadena, gnNumero, gdFecha, glBoolean, gaArray, goObjeto



2. Convensión de nomenclatura de objetos (VFP)

Está detallada en la ayuda de FoxPro y en el MSDN de Microsoft

Ejemplos:
custom => cus_nombre
label => lbl_nombre
form => frm_nombre
checkbox => chk_nombre
editbox => edt_nombre
listbox => lst_nombre
spinner => spn_nombre
pageFrame => pgf_Nombre
page => pag_Nombre
commandButton => cmd_nombre



3. Checkin y checkout de componentes (SCM/VFP)

Antes de hacer un checkin o un checkout de componentes, es conveniente limpiar el entorno para evitar problemas:

CLEAR ALL
CLOSE ALL
(y ahora se puede hacer el checkin o checkout)



4. Cambio de changeset (Plastic/VFP)

Al igual que en el caso anterior, es conveniente hacer el CLEAR ALL / CLOSE ALL, pero además es conveniente revisar y refrescar la vista de Cambios Pendientes, ya que si hubiera archivos modificados, generaría un aviso.



5. Trabajo en ramas (SCM)

Regla de oro: Nunca se debe trabajar o modificar en la rama personal de otro usuario, ya que se le puede ocasionar una inconsistencia en el desarrollo. La rama de trabajo personal es como el maletín de cada uno, no se comparte y es actualizada por el propietario exclusivamente.

Si se quieren compartir ramas, se deberá hacer con ramas que no sean personales (como una rama de una tarea) y solamente se debe actualizar mediante merge o cherry pick, nunca manualmente.



6. Sesiones de FoxPro

Evitar cambiar el directorio de una sesión de FoxPro que sea usada para modificar componentes (o sea, no usar CD <directorio> o SET DEFAULT TO <directorio> si se modifican programas con MODIFY), ya que los programas se suelen cachear en la memoria, y al modificar en otra ubicación se podrían provocar problemas de ruta inválida sobre todo en las clases y forms.



7. Parámetros

Usar LPARAMETERS en vez de PARAMETERS y si hay que agregar parámetros a un método, agregarlos siempre al final, nunca en medio, que eso rompe la compatibilidad de los programas.

Ejemplo agregando nuevo parámetro "tnCosto":
LPARAMETERS tcNombre, tnEdad, tnCosto




Como todo, esta lista no es definitiva, pero al menos es una buena base para poder trabajar de forma "compatible" con otros desarrolladores.


Hasta la próxima!

PlasticSCM: Cómo configurar el usuario Administrador del Servidor

Por: Fernando D. Bozzo

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) ):

C:\DESA\dvcs_vfp9>cm setowner -user=fdbozzo repserver:win7u:8087


Una vez configurado el usuario Administrador, lo verificamos (reemplazar win7u por vuestro nombre del Servidor Plastic):

C:\DESA\dvcs_vfp9>cm showowner repserver:win7u:8087
repserver:win7u:8087 fdbozzo Usuario

5 - Desactivar licencias de usuario

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.


Hasta la Próxima!

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

Por: Fernando D. Bozzo

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

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

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

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

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

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


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


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

Recursos de software necesarios (links):

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

Todo lo que estamos viendo está aquí:

[Blog]- Prácticas de VFP 9 con control de código fuente desde CERO

Cualquier duda, me escriben o preguntan en el foro.

Fernando D. Bozzo

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

Por: Fernando D. Bozzo

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

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

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

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

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

• Se pueden comparar los binarios usando archivos de texto estilo PRG

• Se puede saber qué se cambió en cualquier momento del tiempo, incluso entre versiones no consecutivas (por ejemplo, hace 3 versiones atrás)

• Se puede saber quién hizo un determinado cambio, incluso a nivel de cada línea de código

• Se pueden obtener varias estadísticas, como, por ejemplo, cuántos cambios se hicieron desde la última versión, o qué componentes cambiaron

• Se puede tener un equipo de desarrolladores que puede trabajar en los mismos componentes (forms, librerías de clases, menús, etc) y que pueden hacer merge (mezcla) de código concurrentemente y obtener binarios FoxPro funcionales de esas mezclas sin bloquearse entre ellos

• Cada desarrollador tiene su copia local del sistema, donde puede hacer todas las pruebas que necesite sin tener interferencias o bloqueos por los cambios de los demás

• Si un desarrollador comete un error, los demás no pagarán las consecuencias ni quedarán bloqueados por ello

• Un desarrollador puede trabajar en la versión actual del sistema, mientras otro puede estar trabajando en el parche de la versión anterior con código más antiguo, y ambos no se verán afectados

• Se puede trabajar en más de una versión a la vez (esta versión, la próxima, un parche, etc) usando ramas

• Se tiene la opción de trabajar en un proyecto con gente que está en sitios geográficamente separados. Esto permite que tu trabajes en tu casa, yo en la mía y ambos podamos compartir el mismo repositorio, por ejemplo, GitHub o BitBucket, como repositorio intermedio

• Se pueden sincronizar varios repositorios de código fuente para backup, para replicación o para otros usos

• Se tiene la opción de "deshacer" un cambio, o muchos cambios, que afectan a uno o varios componentes de forma segura y volver a una versión anterior

• Se puede ser libre de los formatos privativos y usar formatos libres que pueden ser usados por más de una herramienta SCM, lo que permite pasarse de una a otra herramienta

• En definitiva, se tiene el completo control de todos los aspectos del desarrollo de un sistema, de sus versiones, sus cambios y evitando los bloqueos entre miembros del equipo

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



¿Llevas el control de las versiones de tu programa?

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

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

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



¿Cómo comparas dos versiones de un archivo?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

FoxBin2Prg: Control de código fuente con PlasticSCM

Instalación de PlasticSCM paso a paso

Programas para control de versiones


Hasta la próxima!

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

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

• Actualizada la versión de FoxBin2Prg (solo el EXE) a la versión v1.19.30

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!