Usar foxbin2prg con git y github/bitbucket

[Arturo Ramos]

Hola foro,

Una consulta para Fernando Bozzo y su extraordinaria herramienta que permite el control de versiones con VFP; creo que esto puede ayudar a más de uno por aquí.

Fernando, antes que nada muchas gracias por la herramienta, ahora estamos haciendo pruebas con ella pero tenemos algunas dudas sobre cómo sería la forma correcta de trabajar la dinámica de binario -> prg -> binario.

Aquí en la empresa usamos Git y GitHub/Bitbucket desde hace muchos años para nuestros proyectos y lo queremos hacer ahora para los proyectos de VFP.

Nos puedes dar una idea de como estructurar el proceso de cambio de versiones, sobre todo cuando "re-armas" los binarios, como controlar que un binario que se va a "re-armar" no tenga cambios locales.

En el grupo de factura-electronica-mexico tenemos la clase que hace todo el proceso en un repositorio de GitHub pero como sólo es un .prg tal cual pues no tenemos ese problema.

Espero que este tema sirva para los interesados en el control de versiones de sus sistemas; Git es una de las mejores herramientas de control de versiones de código abierto y libre de uso; GitHub y Bitbucket son hospedajes de código basados en web llamados repositorios, GitHub es de registro gratis y puedes crear los repositorios que quieras pero de acceso libre/público puedes contratar una cuenta para crear repositorios cerrados/privados, en Bitbucket se pueden crear repositorios privados con acceso para hasta 5 usuarios y es compatible con Git.

http://git-scm.com/

https://github.com/

https://bitbucket.org/

Saludos.

Arturo Ramos

www.ircsasoftware.com.mx

Cancún, México.

[Fernando D. Bozzo]

Hola Arturo!

Disculpa que tardé tanto en responder, pero cuando preguntaste justamente estaba escribiendo una nota sobre el merge en Visual FoxPro con video incluido. Me llevó bastante tiempo (todo el finde), pero creo que valió la pena.


La nota es esta:
http://fdbozzo.blogspot.com.es/2014/02/foxbin2prg-control-de-codigo-fuente-con.html

Y este el video de YouTube (es el mismo de la nota):
http://youtu.be/sE4wQ50Itqg


Si con esto seguís teniendo dudas, preguntá sin miedo. Para eso estamos.


Saludos!

[Fernando D. Bozzo]

Arturo, ¿pudiste leer lo que escribí y el video? ¿Te quedaron dudas?

El sábado, 22 de febrero de 2014 20:07:33 UTC+1, Arturo Ramos escribió:

[Arturo Ramos]

Si Fernando, muchas gracias, leí todo y creo tener una idea, quiero ver el video y aplicar lo que explicas en algo real, eso es lo mejor, intentare llevar el proceso a las herramientas que uso.

¿Has usado PlasticSCM con repositorios en la nube como GitHub o Bitbucket?

Vi que se puede usa una app que sirve de "enlace" entre el repositorio local y el web, que permite usar PlasticSCM como cliente de GitHub, ¿lo has usado?

http://codicesoftware.blogspot.com/2012/04/using-plastic-scm-as-github-client.html

Gracias, cualquier duda te la comento.

Saludos

Arturo Ramos

www.ircsasoftware.com.mx

Cancún, México.

[Fer]

Hola Arturo :

Si, con GitHub, de hecho las herramientas (scripts) que hice para Plastic las trabajé con Plastic como repositorio local y lo sincronicé con GitHub con un simple clic derecho sobre la rama principal y eligiendo GitHub como destino de sincronización. Ya no requiere instalar nada extra, viene todo integrado.
Lo que sí me pasó al principio con otro proyecto que quise subir fue que no pude, y me quedó la idea de que fue porque en el primer check-in protegi muchos archivos, así que para este proyecto lo hice distinto, protegi como primer archivo el readme.txt solo, y luego hice el check-in del resto aparte, y con eso funcionó. Lo del readme.txt primero es importante porque el primer archivo es el que GitHub muestra en la página principal.

En estos días voy a escribir la segunda parte de la nota con las dudas que me han hecho llegar, así que cualquier duda que tengas decime, así lo incorporo en la parte 2.

[Fernando D. Bozzo]

Hola Arturo:

Sobre este tema, ayer hice una pequeña actualización de la nota sobre el merge en mi blog, ya que me habían preguntado sobre eso.

¿Cómo van tus pruebas?


Saludos!

[Arturo Ramos]

Hola Fernando,

Voy a actualizar a esta última versión para probar eso de los timestamp por que es lo primero que me salió en mi merge, este fin de semana voy a hacer un ciclo completo, necesito ver como trabajar con GitHub por que necesito que el código se pueda almacenar ahí y que este disponible desde cualquier parte, no me sirve que tenga que poner un servidor en las oficinas y que los programadores tengan que trabajar a fuerzas en una red local.

Iré documentando todo e informando aquí cualquier detalle.

Muchas gracias.

Saludos.

[Fer]

Hola Arturo:

Me parece genial. Aprovechá los 2 scripts incluidos para conversiones masivas, que junto con FoxBin2Prg en solitario son un trío para hacerles un acceso directo en la carpeta SendTo del perfil del usuario en Windows y mejorar la productividad.

Cualquier cosa en la que pueda ayudarte, avisame.

Saludos!

[Arturo Ramos]

A ver, eso si no te lo entendí,

Estoy haciendo el paso de binario a texto a binario de uno por uno, por ahora en pruebas he trabajado con algunos forms pero explicame eso por favor.

Gracias.

[Fer]

Yo incluí un Readme.txt y dos scripts .vbs en los cuáles explico cómo funcionan y donde ponerlos.

Se copian los 3 archivos (el EXE y los 2 VBS) en un directorio (ej: c:\utiles_scm), se les crea un acceso directo y se mueven los accesos directos a la carpeta SendTo del perfil del usuario local, y se renombran para quitarles el agregado inicial de "acceso directo" y listo, a partir de ese momento podés elegir un archivo y enviarlo a FoxBin2Prg o elegir un grupo de archivos o un directorio y enviarlo (click derecho / enviar a) cualquiera de los 2 scripts, de acuerdo a lo que quieras regenerar, si binarios o texto, de modo que con un par de clicks regenerás todos los binarios de un proyecto.

[Fer]

Hola Arturo:

Te convendría leer este artículo actualizado con lo último, para que conozcas bien las vistas y opciones que tenés:

http://fdbozzo.blogspot.com/2014/02/foxbin2prg-detalle-de-vistas-datos-de.html

Saludos.-

[Fernando D. Bozzo]

Hola Arturo:

Acabo de sacar nueva versión de estas herramientas y del conversor:

Herramientas: http://fdbozzo.blogspot.com/2014/03/nueva-version-v248-de-las-herramientas.html
Conversor: http://fdbozzo.blogspot.com/2014/03/nueva-version-v11914-de-foxbin2prg.html

Creo que te podría convenir suscribirte a mi blog para enterarte de estas actualizaciones enseguida, ya que podrías perderte alguna actualización importante. No suelen haber grandes cambios porque todos los formatos están finalizados, pero sí que surgen correcciones, optimizaciones y alguna que otra opción de productividad.

Lo más importante es que en la nota de publicación de FoxBin2Prg suelo comentar las mejoras un poco más en detalle, para que se entienda qué llevó al cambio, cuál era el fallo, qué situación me reportaron, etc.


Saludos!

[Arturo Ramos]

Hola Fernando,

Pues todo bien, he creado mi entorno, instalado y configurado todo lo necesario, hice mis primeros dos commits (checkin) e incluso sincronice mi local con GitHub.

https://github.com/ircsasw/VFPPlastic

Durante el proceso salieron algunas dudas, a ver que me puedes comentar.

- ¿Es necesario manejar los archivo .gitignore para Git?, ¿Que archivos ignorar?

En mis anteriores intentos por llevar control de versiones de mis sistemas he usado archivos ,gitignore para evitar que en el repositorio se versionen los archivos binarios de VFP

https://github.com/ircsasw/VFPconGit

https://github.com/ircsasw/VFPconGit2

- Hablando del workspace (local), ¿Qué archivos son los que se deben ignorar?

- Al instalar y configurar PlasticSCM se me ocurrió usar MySQL como base de datos del backend, ¿Lo recomiendas?

- ¿Puede mi programador trabajar en el proyecto desde su casa o en otra ciudad?, ¿Cómo?

Muchas gracias por tu ayuda hasta aquí, ahora paso a lo bueno... trabajo en equipo, merge y "distribuido".

Continuo informando.

Arturo Ramos

www.ircsasoftware.com.mx

Cancún, México

[Fernando D. Bozzo]

Contesto sobre tu post.

El domingo, 2 de marzo de 2014 09:25:17 UTC+1, Arturo Ramos escribió:

Hola Fernando,

Pues todo bien, he creado mi entorno, instalado y configurado todo lo necesario, hice mis primeros dos commits (checkin) e incluso sincronice mi local con GitHub.

https://github.com/ircsasw/VFPPlastic

Durante el proceso salieron algunas dudas, a ver que me puedes comentar.

- ¿Es necesario manejar los archivo .gitignore para Git?, ¿Que archivos ignorar?

En mis anteriores intentos por llevar control de versiones de mis sistemas he usado archivos ,gitignore para evitar que en el repositorio se versionen los archivos binarios de VFP

https://github.com/ircsasw/VFPconGit

https://github.com/ircsasw/VFPconGit2

Si va a haber al menos un integrante del equipo que vaya a usar Git directamente, y no el GUI de Plastic, entonces sí que va a necesitar ese archivo, si no, no.
Los archivos a ignorar, tanto en Plastic (ignore.conf) como en Git (.gitignore) deben ser los que no se quieren subir al control de código, por lo que típicamente hablaríamos de los siguientes en FoxPro:

.fxp, .lnk, .scc, .tmp, .bak, .dbf, .fpt, .cdx, .dbc, .dct, .dcx, .mpx, .mpr

Exceptuando los datos (dbf/dbc), el resto de binarios de FoxPro deberían versionarse también. Nunca trabajé con Git solo porque me parecía un poco complicado lo de tener que hacer todo desde la ventana de comandos, y por otro lado suelo hacer pruebas de escritorio en el mismo directorio de la aplicación, lo que Git subiría también, y tener que tener en cuenta eso me complicaría la forma de trabajo y me llevaría a duplicar el sistema en otro directorio fuera de Git para poder hacer pruebas. Git lo usé solo dos veces, por medio de Plastic, el primer intento que fué fallido por haber subido todo junto de una vez, y el segundo intento que fué con el proyecto de las herramientas para Plastic, que ahí funcionó porque primero suí un solo archivo (readme.txt) y luego el resto.

Haciendo el control desde Plastic esto no ocurre, ya que solo subís los archivos del directorio que te interesen, y el archivo ignore.conf te filtra los archivos y extensiones que no querés subir ni ver, pero seguís teniendo el control de no incluir manualmente lo que no quieras y así poder trastear tranquilamente con el sistema o haciendo las pruebas de escritorio necesarias, lo que a veces implica hacer pequeños programitas de prueba de concepto como el que hice el otro día para testear la velocidad de ICase vs Case.

 

- Hablando del workspace (local), ¿Qué archivos son los que se deben ignorar?

Hay que ignorar los del punto anterior

 

- Al instalar y configurar PlasticSCM se me ocurrió usar MySQL como base de datos del backend, ¿Lo recomiendas?

Hace solo unos meses que lo estoy usando, así que no conozco todo lo que soporta o las ventajas/desventajas de usar una BDD u otra, pero según indican en su web, son compatibles con varias BDD, incluyendo MySQL. Igual hay algo interesante: Si en el peor caso pasara que Plastic no se integrara bien con una BDD y alguna característica no funciona como se espera, siempre se puede hacer un Fast-Export de los proyectos (repositorios) que quedan en un archivo que es compatible con el Fast-Export de Git, y se puede volver a importar en otra BDD distinta.
También se puede usar la herramienta de migración (componente servidor) que viene incluida para pasar todo a otra BDD. En teoría no deberías tener problemas con lo que elijas.

 

- ¿Puede mi programador trabajar en el proyecto desde su casa o en otra ciudad?, ¿Cómo?

Sí, esa es la idea. Cada desarrollador debería montarse su propia BDD local, aunque para un proyecto normal le deberían alcanzar los 4 GB que permite el SQL CE 3.5 por reporitorio, teniendo en cuenta que un reporitorio debe contener solo un proyecto (pjx) y sus componetes. Luego, a la hora de sincronizarse con los demás, lo hará por medio de la sincronización a Git, que es donde los demás harán los mismo.
Algo muy importante es que cada desarrollador tenga su propia rama de trabajo que dependa de la principal, y eso es una de las cosas que vamos a intentar ver en la práctica. En este punto las herramientas que hice para Fox juegan un papel importante, ya que lidio con un problema que no se suele tener en cuenta: la capitalización de los archivos. Tanto Plastic como Git están pensados para ser multiplataforma, lo que quiere decir que en Linux, Unix y Mac también deben funcionar, pero resulta que Windows es el único SO que no respeta si un archivo lo escribís ASI o Asi, en cambio para el resto de plataformas esto equivale a dos archivos distintos. Durante las conversiones de texto a binario y viceversa, una de las cosas que se hacen es ajustar la capitalización de las extensiones a minúsculas, ya que Fox tiene la mala costumbre de cambiarlas de forma aleatoria dependiendo de qué hagas, así que con este tema no deberíamos tener ningún problema.