Nueva versión v1.19.47 de FoxBin2Prg

[Fernando D. Bozzo]

Hola a tod@s:

Solo les quería comentar que hay una nueva versión de esta herramienta de conversión bidireccional binario-texto con algunos arreglos y algunas características nuevas, como la importación de datos desde DB2 a DBFs y algunos nuevos métodos API:

https://vfpx.codeplex.com/wikipage?title=FoxBin2Prg

Lo pueden usar solo, o con cualquier herramienta de Control de Código, Herramienta de Diff o editor de texto.


Saludos!

Fernando D. Bozzo

[francisco prieto]

Excelente Fernando. La voy a chusmear.

--
Has recibido este mensaje porque estás suscrito al grupo "Visual Foxpro Latinoamérica" de Grupos de Google.
Visita este grupo en https://groups.google.com/group/vfplatino.

[Augusto Ortiz]

Muchas gracias!!!

Ya lo bajo y lo pruebo.

Augusto Ortiz

[Esteban H]

Gracias Fernando.

 

Bajando…

 

Saludos.

 

Esteban.

 

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Fernando D. Bozzo
Enviado el: jueves, 09 de junio de 2016 04:42 a.m.
Para: mundovisualfoxpro; publice...@googlegroups.com; vfpl...@googlegroups.com
Asunto: [vfp] Nueva versión v1.19.47 de FoxBin2Prg

 

Hola a tod@s:

[Hugo C.]

Excelente herramienta.

Saludos.

[Carton Jeston (9.0.0.7423)]

Hola Fernando:

Ya intente empezar a usar esto hace mas de un año y por el camino me quede, siempre hay que dejarlo por otras cosas mas importantes... que no lo son tanto cuando te llega el problema y te acuerdas del control de codigo :D

Hace un par de meses empece a usar tu herramienta independiente para comparar dos binarios y ha sido de gran ayuda para empezar, aunque ahora quiero dar el gran paso. De hecho si quiero empezar a hacer las cosas bien, se me hace imprescindible adoptar este sistema antes de hacer otra cosa. Y como no, aprovecho para felicitarte por tu trabajo y que mejor manera que otro usuario que lo use ;)

Y cuento un poco a todos un poco lo que me he encontrado al instalar...

Lo cierto es que la instalacion es copiar y pegar, otra cosa es plastic que es muy laboriosa pero con los tutoriales de tu blog es mas o menos sencillo. Algun problema me dio alguna antigua licencia y plastic no reconocia la nueva, asi que lo borre todo y lo hice desde el principio y sin problemas.

Cabe señalar que durante la configuracion del servidor plastic tienes que reiniciar para ver los cambios y se puede evitar entrando en los servicios de windows y buscar PLASTIC, detener/iniciar o reiniciar y ya esta.

Ahora mismo estoy jugando con plastic y una carpeta de pruebas con mi aplicacion, he hecho algunos changeset y aun me queda estudiar para aplicarlo correctamente.

Hay un detalle tonto, puse el workspace la carpeta donde estan mis fuentes (tranquilo, son de prueba) pero me resulta molesto que los archivos de texto se generen en la misma carpeta, ya que me "contamina" visualmente el contenido. ¿hay algun modo de separar carpeta original del workspace? Si es asi me vale con una indicacion, ya seguire hurgando yo... ;)

[Fernando D. Bozzo]

Hola,

Me alegra un montón que comiences a usar Control de Código. Ya descubrirás que, bien usado, luego no se puede vivir sin el :D

Respecto de separar las vistas texto de los binarios, no es posible, se generan juntas justamente para ayudar a no olvidar que forman parte indispensable del "trío" cuando se sube el código a la herramienta de Control de Código. Igualmente tampoco es para tanto, ya que cuando usás el gestor de proyectos de VFP solamente ves lo de VFP, los demás solo los ves si usás el administrador de archivos, y en la vista de "Items" o de "Cambios Pendientes" de Plastic obviamente hay que verlos para poder tratarlos.

La separación que sí te conviene hacer es la de toda la vida, que es tener subdirectorios para FORMS, CLASES, PRGS, etc.

Lo de la licencia lo podías arreglar rápido si leias esto antes (el punto 13):

PlasticSCM: ¡Houston, tenemos problemas!


Todos los artículos de Plastic los podés buscar mediante la etiqueta plasticscm.


Cualquier duda, acá estamos :D

[Douglas Sánchez]

Hola Fernando, gracias por tu aporte al foro.

Una consulta: Tiene algún video para ir paso a paso para usarla y alguna forma de uso en Youtube.com

Saludes

DSànchez.

[Fernando D. Bozzo]

Hola Douglas,

La verdad es que no, para usar FoxBin2Prg en solitario no hice ningún video, pero sí que hice algunos sobre su uso con PlasticSCM.

Si tenés alguna duda de uso, no dudes en preguntar, además tenés varios artículos en mi Blog.

Saludos!

[fmo2004fmo]

VISTA PREVIA EN REPORTES

*Hace mucho tiempo que lo utilizo en mis reportes*

*Obtenido hace tiempo en la web.*

Parece una ADAPTACIÓN de

"How to change the title of Print Preview window"

"1001 Things You Wanted to Know About Visual FoxPro"

"Chapter 17 Managing Reports"

*------------------------------------------------------------------------------------------------------------------*

oRep =Createobject("Form")

With oRep

   .Caption=DTOC(DATE()) + space(10)+"MiReporte.frx"  &&  "Titulo de Ventana del Reporte"

   .Icon= "\ICONOS\ventana.ico"  && icono

   .WindowState= 2

   .Closable= .f.

   .MinButton= .F.

   .MaxButton= .F.

   .Show()

Endwith

Report Form MiReporte.frx Preview Window (oRep.Name)  &&  aqui muestra el reporte en vista previa*

oRep.Release

*------------------------------------------------------------------------------------------------------------------*

ver También:

http://fox.wikis.com/wc.dll?Wiki~MaximizePrintPreview

[Carton Jeston (9.0.0.7423)]

Gracias Fernando por la informacion. De hecho ahora mismo el trabajo no me deja parar pero necesito prioritariamente empezar a dominarlo. Tengo una version estable de la aplicacion para actualizar a mis clientes y me han pedido unos pequeños cambios que a estas alturas me ponen los pelos de punta tener que tocar nada.

Aunque hago copias de seguridad, tengo que tener bien claro que es lo que añado o cambio y siempre queda el riesgo de que se te pase algo. Con tu aplicacion diff ya con solo anotar que prg o formulario has toqueteado, ya puedes saber en todo momento que hiciste exactamente y se lo recomiendo a todo los que empiezan con esto, porque se benefician desde el primer minuto mientras vas aprendiendo el control de versiones.

Estoy en desacuerdo en algo,  la separacion de toda la vida es el subdirectorio ".", es decir, todo junto en la misma carpeta y ademas como no, las bases de datos. Al final vas organizando las cosas, informes, graficos, etc... que es lo recomendado ;)

Lo de la licencia, probe tambien el metodo que indicaba ahi y alguna cosa mas y no habia manera de que lo reconociera. Tal vez se cambio algo mas en la configuracion o yo hice algo mal, porque lo hice de semana en semana. Me costo menos reinstalarlo desde cero y cuando me salio de nuevo algo sobre la licencia, hice lo que indica ahi y si la reconocio.

A ver si consigo tener un poco mas de tiempo para esto, porque tengo que aprender mucho sobre muchas mas cosas a pesar de los años que llevo con xbase...

El viernes, 10 de junio de 2016, 14:24:20 (UTC+2), Fernando D. Bozzo escribió:

Me alegra un montón que comiences a usar Control de Código. Ya descubrirás que, bien usado, luego no se puede vivir sin el :D

[Javier Bernal]

Como siempre Fernando, por tu aportación, Gracias y Saludos

[Luis Maria Guayan]

Gracias por el aporte Fernando 

[Carton Jeston (9.0.0.7423)]

He tenido un verano muy ajetreado, a ver si me dejo caer mas por aqui...

Me ha pasado algo curioso que nunca recuerdo que me haya ocurrido. Ademas del backup de versiones, anoto en un cuaderno los cambios principales de cada version. Hasta ahi bien, pero a veces ocurre que el caos se apodera de nuestra vida...

Me quede programando a medias una version y estuve un mes sin tocar nada, cuando volvi tenia algunos errores y no sabia de donde venia y lo peor, la hoja que use no la pase a limpio y por lo visto la tire. Intente empezarla de nuevo y otro paron de dos semanas pero en este caso no lograba terminar unas rutinas correctamente y me junte con dos versiones en desarrollo y ninguna buena. Al final cogi la ultima estable y fui añadiendo poco a poco de esas dos, revisando con tranquilidad cada punto de la lista y cada fallo lo resolvia uno por uno, anotando todas las comprobaciones.

¿Y que tiene que ver todo esto? Que de haber tenido por fin el control de versiones funcionando, nada de esto me habria pasado y no solo es por el tiempo perdido sino por la tranquilidad de saber exactamente por donde me quede y que la aplicacion seria mas estable.

Asi que estoy deseando de una vez tener la version nueva estable y ya no hago nada en la siguiente sin el control de versiones. Aqui me mostraron que hacia falta, ahora se fuera de toda duda que es imprescindible...

[Fernando D. Bozzo]

Hola:

Supongo que ahora mismo estás bastante ocupado, pero si no es así, yo te diría que no esperes a la versión "definitiva" o "estable", ya que podrías comenzar a sacarle provecho desde ya durante el desarrollo y las pruebas.

Claro que esto es así en el caso de que hayas hecho algunas pruebas con el control de código y tengas más o menos claro cómo es la operativa, que si tenés que comenzar desde cero, entonces te va a retrasar un poco.

Yo calculo que en 8-10 hs de práctica tendrías lo necesario para comenzar a usarlo, pero eso dependerá realmente de lo que tardes en tomarle el ritmo.

Si al final vas a usar Plastic, yo te diría que uses la versión oficial (5.4.xxx), ya que las anteriores, como la que usamos en los cursos pasados (5.0.44.xx) ya están discontinuadas, y la nueva funciona bien.

Cualquier duda, avisame y te hecho una mano,

Saludos! :)

[Carton Jeston (9.0.0.7423)]

El problema es el tiempo, sobre todo el tiempo seguido que le dedico. Ya lo he intentado dos veces y he avanzado mas, lo he dejado por el tema del trabajo y cuando vuelves tienes que volver a repasar todo :D

No te alarmes, tengo la version 5.4.16.740 con esta version del foxbin2prg con el programa dentro para trastear, pero para dar el salto definitivo tengo que poner un poco de orden y para eso quiero tener primero una version estable. Y a partir de esa ya hago una nueva en desarrollo con el control de versiones y si algun cliente me reporta un error, arreglare la estable que esta en produccion pero cualquier añadido o mejoras de la aplicacion ya lo hago en la nueva.

Paradojicamente, por falta de tiempo no me he puesto al dia en esto y los problemas de no tenerlo aun me hacen perder mas tiempo del que emplearia en aprender. Cuando llegue el momento, despues de repasar todo de nuevo y tenerlo listo, te bombardeare a preguntas para ver si de una vez consigo pasar la ola ;)

un saludo

[Carton Jeston]

A la tercera va la vencida... de año en año y parece que Agosto sea el mes del control de codigo. La explicacion logica es que con el calor programo menos, me cuesta pensar mas y mas facil es equivocarme... y me acuerdo del control de codigo :D

 En este año he reordenado un poco la aplicacion separando en subcarpetas formularios, clases, informes, etc. por comodidad para el control y porque ya tocaba. No se porque me veo como Moises en aquella pelicula "la loca historia del mundo"... va con tres tablas y dice: "les traigo los quince mandamientos" se le cae una y se le rompe y vuelve a empezar "les traigo estos diez mandamientos"... Bueno, si las reglas de las buenas practicas me las dieron en tablas, el catastrofico y acelerado cambio de aplicaciones de dos a windows hizo que rompiera todas las tablas. El resultado, años perdidos arreglando el estropicio...

Y aqui me tienes repasando por donde me deje, ya decidido terminar este asunto pendiente y me surge una duda. Hice los accesos directos en sendto de foxbin sin problemas y funcionan, pero el de normalizar no lo tenia creado en su dia y al hacerlo no logro hacerlo funcionar. He probado con acceso directo al vbs, al caps.exe y algunas variantes pero no doy con al tecla. Esto es lo que sale con el vbs... a ver si a alguien le ha pasado.

un saludo

[Fernando D. Bozzo]

Hola:

Intentá instanciar en la ventana de comandos de Fox el objeto de Fox, así:

oo = createobject("visualfoxpro.application.9")

Si al darle ENTER te da un error, entonces es q

[Fernando D. Bozzo]

...apreté una tecla y se envió incompleto.

Decía que si te da error, entonces es que no tenés registrado el objeto application de FoxPro.

En ese caso el arreglo es fácil, usá la ruta a tu vfp9.exe, de esta forma en una ventana de comandos abierta como admin:

"c:\program files (x86)\microsoft visual foxpro 9\vfp9.exe /regserver"

Esto registra el objeto visualfoxpro.application.9 (si estás usando VFP 9, claro :)

Saludos.-

[Carton Jeston]

Exacto, eso era el problema. En su dia instale en la ruta normal de C: pero lo movi a R: por tener todo juntito y poder acceder a esa unidad desde cualquier windows instalado.

p.e. R:\vfp9sp2\vfp9.exe /regserver

No es lo normal encontrarse con esta situacion, pero si alguien usa VFPA puede que en algun momento tenga este problema y tu solucion es la correcta.

No estaria mal añadir la solucion como anexo a "Houston tengo un problema" :)

Ahora toca seguir trasteando a ver si consigo dominar lo basico, es algo que me hace mucha falta.

Muchas gracias!!!!

[Carton Jeston]

Fernando, hace casi 60 dias que no tocaba foxbin2prg/plastic y casi perder la mayoria del tiempo en ver donde me quede (como siempre) le he dado un empujon y ya empiezo a balbucear con el control de codigo de una manera bastante operativa. Otra cosa sera cuando me equivoque y me meta en un lio. ;-)

Tenia alguna duda de la forma de operar entre foxpro-foxbin2prg-plastic pero se me ocurrio buscar en youtube foxpro plastic scm y ahi habian unos videos tuyos que viendo un par de veces me ha clarificado mucho el asunto.

Te cuento esto para que no dejes que se pierda y añadir los enlaces de videos en los articulos de tu blog para dar un valor añadido a esa pequeña biblia que tienes montada :-)

Nos vemos










 

[Fernando D. Bozzo]

Gracias por el recordatorio, en cuanto me haga un rato veo donde linkearlos! :D

Un abrazo,

Fernando.-

[Fernando D. Bozzo]

Hola,

Acabo de hacerte caso con esto, y agregué el registro de vfp9.exe en "Houston, tenemos problemas!"  :D

Saludos y gracias!

Fernando.-

[Carton Jeston]

Mucho mejor, ya que estaban los recursos creados era una pena que estuviera un poco desperdigado.

De hecho estoy haciendo un pequeño experimento que pronto te pongo por aqui. ;)

[Carton Jeston]

Por cierto, habia pensado retomar el rediseño de mi aplicacion pero sin meterme presiones de tiempo como en el primer intento, tomando mi tiempo para aplicar TODAS las buenas practicas desde el inicio.

Llegados a este punto, pienso que si lo voy a hacer porque no en otro lenguaje pero en base a alguna experiencia pasada, quizas el camino mas largo sea el mejor, creo que es mas facil reciclarme en un entorno mas familiar y luego que resulte mas facil saber lo que quiero hacer en un nuevo lenguaje. ¿que opinas?

[Fernando D. Bozzo]

Yo creo que si tenés el tiempo para hacerlo, es buena idea. Porque por un lado vas a poder implementar tu nuevo diseño mucho más rápido, por hacerlo en un entorno conocido, y esa experiencia te va a servir para pasarlo a otro lenguaje.

Desde ese punto de vista, y sabiendo que VFP es RAD, digamos que el primer intento sería como hacer una maqueta funcional para comprobar el nuevo diseño, que de paso te permitiría hacer ajustes y mejoras, y que la segunda en el nuevo lenguaje ya sería una implementación final, aunque hay que tener en cuenta de que hacer algo en otro lenguaje nunca sale del todo bien a la primera y al final siempre terminás refactorizando y mejorando también.

Fuera de lo anterior, lo de usar VFP (u otro lenguaje monolítico) como lenguaje para hacer pruebas de concepto o maquetas, en muchos casos puede ser una buena idea, ya que es una técnica que se usa para implementar "Productos Mínimos Viables" de forma rápida y luego hacer la implementación en el (o los) lenguajes definitivos.

Saludos.-

[Carton Jeston]

En este caso hablo de un diseño completo con mucha refactorizacion con el fin de tener un nuevo modelo final.

La actual tiene un largo desarrollo, muchas partes son prehistoricas y otras aprovechan mas las clases, monopuesto, bases de datos dbf, todas las malas practicas aplicadas al 100%, etc. asi que toca normalizar.

En estos dos ultimos años he refactorizado, aplicado mejor clases visuales y ultimamente he empezado a usar el control de versiones y aunque funciona, no me parece suficiente. El ahorro de tiempo que me supondra la nueva version en coste de mantenimiento posiblemente sea diez veces menor. Muchos años preocupado porque el VFP se quedara obsoleto cuando el problema era yo.

Mirare si hay un hilo de buenas practicas por alguna duda que me va saliendo.
Muchas gracias!!!

[Carton Jeston]

¿recuerdas lo de tu entrada con todos los videos organizados?

Me ha vuelto a pasar lo de siempre, casi un mes sin tocar el proyecto con plastic y ya se me habian olvidado algunas cosas o me sentia inseguro de hacerlas de un modo u otro. Recorde los videos (siempre olvido los mismos pasos y mira que es facil) y en un minuto lo tenia claro. Antes me hubiera llevado una mañana.

Asi que gracias de nuevo y te lo digo para que sepas que tus esfuerzos no caen en saco roto ;-)

[Fernando D. Bozzo]

Qué bueno, gracias por comentarlo :-P

[José Luis (VFP 9 SP 2. 09.00.0000.7423)]

Carton Jeston  y  Fernando disculpen que meta la cuchara aquí pero me interesa saber de qué se trata el tema entablado entre ustedes.

[Fernando D. Bozzo]

Es sobre control de código fuente. Si buscás el título del asunto en el foro, vas a encontrar el hilo entero.

Te dejo el link:
https://groups.google.com/d/msg/publicesvfoxpro/MEpJeCsgbGg/-wzqwxSzDAAJ

[Carton Jeston]

Sin problemas, yo pregunte lo mismo hace un tiempo. Estoy usando plasticscm y la utilidad Foxbin2Prg de Fernando para llevar un control de versiones del codigo fuente. Aun lo estoy usando como principiante pero incluso asi tienes la ventaja de saber que cambiaste en el codigo entre una version y otra de tu aplicacion y recuperar una version anterior si algo sale mal a un punto en que todo funcionaba.

Hoy me ha ocurrido la clasica corrupcion del proyecto, he desecho los cambios del pjx/pjt y solucionado. Antes un drama si no tenias un backup muy reciente. Pero eso es lo mas basico, se puede mezclar diferentes versiones, trabajar en diferentes ramas para cada problema e incluso trabajo en equipo y yo no tengo ni idea del 10% y voy con mucho respeto.

Para empezar usaria la aplicacion fb2p_diff.exe para comparar binarios, si tienes la precaucion de documentar en un cuaderno los archivos que cambias entre versiones, ya es practico desde el primer momento.

Pero para aprender bien, mejor usar una copia de tu aplicacion y jugar con ello. Yo tuve prisa por tener el control de codigo y estas cosas mejor despacito. Tambien puedes usar Foxbin2Prg independientemente y ya con mucha paciencia, leyendo el blog de Fernando y preguntando por aqui se aprende.

Bueno, por no hablar que si hay 10 mandamientos de las buenas practicas, yo en algun momento me confundi y pense que eran 10 tareas a realizar. Vamos, que si yo he podido hacerlo, cualquiera puede!!! Por ejemplo, tener todo junto en la misma carpeta, un autentico caos. Asi que antes de meterme en esto he tenido que trabajar mucho este ultimo año para tenerlo un poco mas ordenado y valio la pena.

un saludo

[Carton Jeston]

Fernando, he hecho una pequeña ayuda de como cambiar la ubicación del repositorio en plasticSCM, algo sencillo que no habia visto por los tutoriales y quizas puedas aprovechar algo para tu blog. No tiene que ver con replicar, sino pensando en que me resulta mas facil hacer copias de seguridad o simplemente quitarlo de la misma unidad que esta instalado windows para tenerlo en la otra particion de datos.


CAMBIAR UBICACION DEL REPOSITORIO EN PLASTICSCM

Como comente antes, cuando tengo una version final me gusta guardar toda la carpeta del proyecto y ahora adjuntare a la misma una copia del repositorio en ese momento. Soy muy clasico en eso y creo que el control del codigo fuente te da ventajas y puede dar una falsa sensacion de seguridad y se te olvide que pueden haber problemas con windows, roturas de disco o virus.

Ahora mi mundo es mas seguro con el backup de siempre y el control del codigo fuente con FoxBin2Prg+PlasticSCM ;-)

[Fernando D. Bozzo]

Hola Carton,

Gracias por el artículo. Sobre todo me alegra de que estés pudiendo sacar provecho del Control de Código Fuente. Ya ves que una vez que te habituás a usarlo luego no podés pensar en el desarrollo (cualquier lenguaje) sin él :)

Además el poder revisar el historial de cambios, sabiendo qué cambiaste en cada changeset o incluso entre versiones es impagable.

Un abrazo!

Fernando.-

[Fernando D. Bozzo]

Listo, publicado en el Blog:

https://fdbozzo.blogspot.com.es/2018/01/plasticscm-cambiar-la-ubicacion-del.html


Un abrazo!

Fernando.-

[Carton Jeston]

Cuando compartes un trabajo en internet, solo se compensa todo ese tiempo cuando ves que realmente es util y lo estan usando. Me atreveria a decir que es una herramienta imprescindible para el fox, junto con foxypreviewer y VFP10/C++ COMPILER ya que le da otra dimension y mas futuro a foxpro. No me olvido de FoxyDB ni de otras herramientas de otros compañeros que merecen estar, pero aun no he llegado ahi. :D

 

Me ha costado este año pasado eso de trabajar en paralelo con la version actual y la nueva ya en plastic, reestructurando las carpetas de la aplicacion y comprobando todo. Y apenas estoy empezando y ya veo los beneficios reales y las horas que me va a ahorrar. Cuesta un poco instalar y cambiar la forma de trabajar, pero viene ser como cuando cambias tu coche de toda la vida por uno nuevo, necesitas un tiempo hasta que haces las cosas sin pensar. Como bien dices, ahora cuando miro otros lenguajes de las cosas prioritarias esta el control de codigo fuente y si no es posible, no me sirve :D

Por cierto, tuve un error al hacer merge y decia que estaba mal client.conf pero no existia y luego fui a la entrada de tu blog "Houston tengo problemas" y en la seccion de MERGE pone esto pero le falta el @sourcefile:

"<path-a-las-herramientas>\foxpro_plasticscm_dm.exe" " 'PRESERVE_WS' '@sourcefile'"

Mi problema es que al copiar y pegar en la instalacion desde el blog, me faltaba una comilla. Al comprobar el tutorial de instalacion esta correcto como arriba.

A ver si logro publicar este mensaje, ya sin fotos ni nada, porque llevo toda la mañana y no hay forma :D

[Fernando D. Bozzo]

Acordate de que en el directorio donde bajaste las herramientas para Plastic, hay un README.txt con toda la información de setup para la integración de FoxBin2Prg, tanto en Plastic como en Windows.

Saludos.-

[Carton Jeston]

Si, ahí también le echo un ojo pero me he acostumbrado mas al blog :D

Por cierto, acabo de subir un añadido al articulo que has publicado aclarando la necesidad de detener el servicio para hacer correctamente las copias de los repositorios. Lo mencione pero he preferido ampliar la información para evitar problemas y con algún truquito para su automatización :D

un saludo

[Carton Jeston]

Lo cierto es que ahora que tengo controlado las bases de datos del repositorio, hago una copia previa de las mismas y del workspace y después toda clase de perrerías para probar sobre material real :D

[Carton Jeston]

Una sugerencia tonta: ¿ves interesante un acceso al menu con el boton derecho con una opcion "Cambios Regeneracion total" que independientemente de que archivo selecciones regenere todas las versiones de texto y seguido las binarias? ¿o es mejor seguir como hasta ahora fijandote bien antes de dar a checkin?

De momento no estoy trabajando con multiples ramas, una tarea una rama, porque voy con el tiempo justo haciendo una revision para terminar la version estable. Aun asi, abro una rama por subversion y con todos esos changesets documentados y cuando he terminado varias tareas, la subo al main. No sera muy ortodoxo, pero a mi me vale hasta que tenga mas seguridad y tiempo para hacer mejor las cosas ¿que opinas?


Otra historia de foxbin2prg :
Cuando tienes un error y empiezas a modificar formularios... al final era una tonteria, solo cambiar una linea pero te ha llevado un buen rato. Siempre haces copias de todo el trabajo antes de ponerte a modificar cosas pero no lo hiciste pensando que seria algo sencillo. Esto puede ser un drama, pero como tienes localizado el problema y lo anterior ya lo tenias controlado con un checkit, deshaces todos los cambios y ya solo modificas la linea que estaba mal. Esto es algo simple para todas las opciones que tiene pero hace que todas las horas empleadas aprendiendo ahora tienen su recompensa. ;-) No quiero imaginar el tiempo perdido, las pruebas y la inseguridad en la estabilidad del programa que tendria ahora mismo.

un saludo

p.d. Si alguno aun no ha probado el foxbin2prg+plasticSCM ya esta tardando :D :D :D

[Carton Jeston]

Aqui un esquema de lo que me referia en el anterior mensaje, mi modo de trabajo provisional...

[Fernando D. Bozzo]

Hola!

Te contesto sobre el post.

El 16 de enero de 2018, 8:26, Carton Jeston <carton...@gmail.com> escribió:

Una sugerencia tonta: ¿ves interesante un acceso al menu con el boton derecho con una opcion "Cambios Regeneracion total" que independientemente de que archivo selecciones regenere todas las versiones de texto y seguido las binarias?

Si te referís al menú para Plastic, exceptuando el envío directo a "FoxBin2Prg" o a "Normalize File Capitalization", todas las demás opciones de "Pending Changes: xxx" y "All files: xxx" no miran qué archivo elijas (podés elegir cualquiera), lo único importante es es elegir 1 solo archivo (cualquiera), ya que esas opciones están preconfiguradas para trabajar sobre un tipo de archivo ("Regenerate Binaries" o "Regenerate Text versions") y además definen el ámbito ("All files" o solo "Pending changes")

Por lo dicho, veo que una opción de ese tipo incluso hasta podría ser peligrosa, dado que si te equivocás vas a tener todo un proceso encima de generación y regeneración que además de pesado puede hacerte perder los últimos cambios. Además normalmente no es necesario hacer ambas cosas.

Creo que el origen de esta confusión podría ser que al principio de todo el proyecto, en algún lado puse que convenía regenerar todo hacia un lado y hacia el otro (doble conversión), pero al poco tiempo (y ya con más práctica) puse que solamente hacía falta hacer una conversión para simplificar el proceso.

Lo encontré, el artículo era "FoxPro 9: Creando un componente y añadiéndolo al control de código PlasticSCM", en el punto 4. Ya lo actualicé, quité ese punto y actualicé el siguiente.

 

¿o es mejor seguir como hasta ahora fijandote bien antes de dar a checkin?

Sí, esto es lo más práctico y fácil. Si se trabajó con el IDE de VFP modificando componentes, entonces solamente hay que generar los textos en la vista de "Cambios pendientes", por el contrario si se estuvo trabajando directamente sobre los textos (por ejemplo para reemplazos masivos), entonces hay que regenerar solamente los binarios afectados.

 

De momento no estoy trabajando con multiples ramas, una tarea una rama, porque voy con el tiempo justo haciendo una revision para terminar la version estable. Aun asi, abro una rama por subversion y con todos esos changesets documentados y cuando he terminado varias tareas, la subo al main. No sera muy ortodoxo, pero a mi me vale hasta que tenga mas seguridad y tiempo para hacer mejor las cosas ¿que opinas?

La forma en que lo hacés está bien, cada checkin que hagas debería tener una funcionalidad terminada y probada, y pasar un grupo de funcionalidades juntas a /main es lo habitual.

No es necesario usar varias ramas, y solamente lo vas a encontrar útil cuando tengas más seguridad y quieras poder trabajar en distintas mejoras o fases del proyecto a la vez, pero que no necesariamente deban salir juntas.

Si mirás las ramas en GitHub de FoxBin2Prg (https://github.com/fdbozzo/foxbin2prg/network) vas a poder ver que cada bug (o grupo relacionado de bugs) tienen su propia rama, y más hacia atrás vas a ver que las distintas mejoras y nuevas funcionalidades inicialmente comenzaron en una rama separada, para poder decidir a último momento si la incluía en la Release o si la dejaba para la siguiente o no la sacaba. Esa es la ventaja práctica de las ramas.

[Carton Jeston]

Ojo Fernando, nada de lo que pone abajo es urgente y tienes vida mas alla del fox, asi que tomalo con calma que ya me sabe mal darte la paliza con estas cosas :-)

Me alegra ver que ya no es necesaria esa doble conversion, menos clicks son menos problemas.

Tengo que ver esto de los reemplazos masivos y no tener que bucear en formularios cuando hay que cambiar muchas cosas. No se tiene que hacer a la ligera pero le veo potencial.

Lo de las ramas me lie con una al principio y me daba conflictos y cuando supe hacer el backup/restore de los repositorios ya no me dio miedo trastear hasta arreglarlo (me lo cargue varias veces). Este tema requiere un poco mas de practica pero ya empiezo a comprender como aplicar y mejorar en el dia a dia. Ese ejemplo en github es muy visual y comprensible al mostrar varios ejemplos reales.

De momento las tablas libres las tengo fuera, creo que cada vez que añadia datos me salia en el control de cambios y era molesto. Creo que se puede usar plastic para controlar la estructura pero no se si valdra la pena si mas adelante cambio a bases de datos.

Hay otra cosa que me gustaria hacer es cuando tenga una version estable de 2018, llegado a ese punto hacer una copia y a partir de ahi empezar la 2019 con cambios en estructura o lo que sea. La 2018 solo tendra parches que a su vez translado a la 2019. Eso lo hacia manual, ¿con plastic se puede hacer eso en dos repositorios/workspace distintos de un mejor modo que copia y pega? ¿O quizas se usa todo en el mismo repositorio jugando con ramas paralelas como me ha parecido ver pero cuando sea mas experto?

Otra cosa es un desarrollo nuevo solo con buenas practicas, ahi si que tengo que hacerlo totalmente aparte :D

Lo cierto es que tengo la misma sensacion que en los 90,cuando consegui meterme la base de lenguaje C en la cabeza, a partir de ahi todo fue mucho mas facil. Como siempre, gracias por tu ayuda ;-)
un saludo

Creo que el origen de esta confusión podría ser que al principio de todo el proyecto, en algún lado puse que convenía regenerar todo hacia un lado y hacia el otro (doble conversión), pero al poco tiempo (y ya con más práctica) puse que solamente hacía falta hacer una conversión para simplificar el proceso.

Sí, esto es lo más práctico y fácil. Si se trabajó con el IDE de VFP modificando componentes, entonces solamente hay que generar los textos en la vista de "Cambios pendientes", por el contrario si se estuvo trabajando directamente sobre los textos (por ejemplo para reemplazos masivos), entonces hay que regenerar solamente los binarios afectados.

[Fernando D. Bozzo]

Las tablas libres deben estar fuera de Plastic (o sea, mantenerlas como archivos Privados, no quitarlas del directorio donde está el workspace!). Realmente el workspace es el espacio de trabajo real, no solo el directorio donde se sube el código. Comento esto porque hay algunos que usan los directorios de trabajo reales en un sitio, y luego cuando quieren subir las cosas al control de código hacen una copia al workspace. Eso no es nada bueno, duplica el espacio usado, el código y encima tiene la posibilidad de olvidarse de poner algo importante y perderlo o sobreescribirlo por error.

Lo de las ramas, una vez que lo probás e internalizás su uso, es muy simple: Imaginalas como versiones paralelas de tu sistema, fotos tomadas en distintos momentos, que podés mantener separadas, mezclar o borrar, pero fundamentalmente lo importante es que tenés un backup instantáneo de todo hasta el punto y el momento que elijas ir. O sea que si ahora vas a un changeset del año pasado (ej: algo del 1 de diciembre), vas a ver todo tu sistema en ese punto tal como lo tenías (excepto las tablas), y lo mismo se aplica a cada rama que hagas.

Entonces si pensás en las ramas y en que en cada una podés tener distintos desarrollos de tu sistema (por ejemplo, una rama donde ya comiences a trabajar en la versión del año que viene), podrías mantener esa rama separada sin mezclarla en ningún momento con la actual, cosa de que los desarrollos no se mezclen, pero pudiendo mantener ambos desarrollos separados. El único problema serían las tablas, que si implica hacerles cambios en las estructuras no vas a poder tener ambas versiones de forma concurrente (salvo que hagas un backup de las mismas)

Llega un punto donde podés hilar muy fino y sacar una de las mejores capacidades del control de código, que es cuando para ciertos componentes importantes hacés protecciones (checkin) por separado, lo que te permite pasar esas librerías específicas entre ramas y no todos los archivos modificados.

Te doy un ejemplo que uso a diario:

Tengo dos ramas; una rama con la Release actual del proyecto y otra rama donde estoy llevando unas modificaciones para mejorar, limpiar y normalizar varios componentes, pero en algunos componentes (clases, forms) tengo que hacer algunos cambios funcionales para probar algunas cosas. El tema es que los componentes que no tengan cambios funcionales, sino solamente cambios por limpieza o normalización (nomenclaturas de variables, limpieza de código viejo comentado, etc) me interesa pasarlos a la rama de la Release, pero no quiero pasar los componentes con cambios funcionales porque necesito hacer varias pruebas antes, y tampoco me interesa esperar hasta último momento porque puede pasar tiempo hasta que lo tenga listo. ¿Cómo hago para pasar unos y no los otros, siendo que modifiqué todo junto? Fácil; hago checkin de los componentes por separado (por ej: la librería lib1.vcx/vct/vc2, desmarcando el resto), y así con cada librería o componente que quiero poder pasar luego a la otra rama, y finalmente hago checkin del resto de componentes con cambios funcionales.

Una vez que tengo todo protegido en mi rama de trabajo (en varios changesets), paso uno por uno (y en orden más antiguo a más nuevo) los changesets que corresponden a las librerías sin cambios funcionales (por ej: la librería lib1.vcx/vct/vc2) con cherry-pick a la rama de la Release, resuelvo los conflictos que haya (si soy el único haciendo cambios nunca hay conflictos y es todo automático) y listo, ya tengo la rama de la Release nivelada con todos los cambios no funcionales.

Si te preguntás para qué puede servirme hacer esto: Esto lo hago para que las librerías normalizadas (sin cambios funcionales) puedan ser usadas por el resto del equipo, que se podrán llevar a sus ramas de trabajo propias, sabiendo que no estoy introduciendo cambios funcionales que puedan romper algo, y que cuando tengan que modificar esas librerías, estarán en un estado de modificabilidad y mantenimiento mejor que el que tenían al inicio, facilitando algunas de estas tareas, ya que el código se entiende mejor cuando está bien formateado y limpio.

Otro de los motivos puede ser justo lo contrario: Que me interese tener separado un cambio funcional particular (por ej: un nuevo método o clase) de una librería solamente para que otro compañero (o yo mismo) pueda actualizarse esa librería en solitario, sin todos los demás cambios en el resto de componentes. En ese caso aplico lo mismo; protejo (checkin) esa librería por separado del resto y luego puedo hacer el cherry-pick de ese changeset solamente a la otra rama donde lo necesite.

Como ves, hay muchos casos de uso para las ramas.

Tenés más ejemplos, incluyendo el típico caso del "arreglo urgente" en estos artículos:

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

PlasticSCM: ¿Qué es nivelar una rama?

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

...una cosa interesante que suele pasar cuando se trabaja con control de código, es que a medida que te familiarizás con los conceptos y "los viajes en el tiempo" (el cambio de un changeset a otro:), cuando releas algunos artículos vas a ir descubriendo algunas cosas que en un principio no habías entendido o no te quedaban claras, y que de pronto se empiezan a aclarar :)

[Carton Jeston]

Si, tengo las tablas excluidas como privado en el workspace, ya que el control de codigo lo puedes volver loco a cada cambio de un dato. El workspace no deja de ser la carpeta que contiene la aplicacion de toda la vida con todas sus cosas, simplemente que el control de codigo controla formularios, informes, prg, etc. si borras una tabla que necesita tu aplicacion, dejara de funcionar.

Ahora bien, me intriga si no se controlase el binario de la tabla libre pero cuando haces un cambio en la estructura la exportas a SC2, sabrias cuando las has cambiado. No es algo que me inquiete pero es un problema interesante. Crear algo nuevo en otro lado y copiarlo dentro se me ocurriria hacerlo en un formulario o elemento nuevo que tuviese desarrollado en otra carpeta pero nunca como metodo de trabajo para actualizar algo ya existente.

Sobre la concurrencia de las tablas, siempre que añadas campos nuevos sin modificar las caracteristicas de los existentes o  tablas nuevas, deberian funcionar ambos... pero (y estoy pensando sobre la marcha) como hice el pasado año la tarea de separar carpetas de datos, formularios, etc. ahora tengo la capacidad de poder ejecutar una subcarpeta 2017 o 2018 con todas las tablas libres simplemente cambiando un parametro o una variable a la hora de ejecutar segun que version del programa.Y ya cuando use bases de datos, solo cambiar el nombre de la misma y ya esta. Mira por donde las buenas practicas empiezan a simplificar las cosas :-D

Como bien dices, hay muchas cosas que ahora las veo claras y logicas conforme subo un peldaño nuevo pero aun me queda un poco para comprender todo el potencial de las ramas, asi que me toca leer varias veces lo que me has puesto y aplicarlo en el momento de trabajar con ello. Cuando llegas cierto punto punto de no retorno es cuando empiezas a comprender mucho mas rapido, muy importante para mi saber hacer copias de los repositorios y el workspace para no tenerle miedo  :-D

Lo mas importante es la cantidad de tiempo que he ahorro solo usando a nivel basico que antes perdia averiguando que habia tocado o por donde me habia quedado dos semanas antes. El esfuerzo extra de los ultimos dos o tres años empieza a materializarse y puedo pensar en nuevas opciones.

Por cierto, nunca entendi porque plastic se instalaba en la barra de herramientas de Word, pero que bien me puede venir cuando redacto distintos documentos y hago revisiones ;-)

un saludo

[Fernando D. Bozzo]

Cuando instalás Plastic, por defecto instala la extensión para Office si lo detecta, pero eso se puede desmarcar al instalar. Lo mismo que la integración con el Explorador de archivos.

En la configuración por defecto de FoxBin2Prg se generan solamente las estructuras de las tablas en los DB2, así como de los DBC, y esto es importante porque así tenés controlado en cada versión qué cambios estructurales hiciste (nuevo campo, nuevo índice) o si cambiaste algún tipo de dato o clave de índice. Además te permite poder regenerar la tabla y el DBC desde su tx2 correspondiente, aunque esta opción no está habilitada por defecto, justamente para evitar sobreescribir las tablas.

Lo que sí es recomendable es generar los textos de los DBF (estructuras e índices, por defecto) y de los DBC y protegerlos en Plastic, para poder hacer el control que te comento.

No sé si lo hayas visto, pero por si te interesa y te es útil FoxBin2Prg soporta la opción "ClassPerFile" que sirve para generar un archivo .vc2 por cada clase de una librería, lo que es muy útil cuando se tienen librerías con muchas clases y donde hay muchos cambios.

Por ejemplo, para una teórica "libreria.vcx" con 4 clases (clase1..4), generaría estos archivos:

libreria.vc2          => Contiene los nombres de las clases de la librería

libreria.clase1.vc2

libreria.clase2.vc2

libreria.clase3.vc2

libreria.clase4.vc2

Una ventaja de esta opción es que facilita bastante el merge de las librerías, ya que solamente realizás el merge sobre las clases individuales que cambian y no sobre todo el archivo entero.

Esto por defecto no está habilitado principalmente por mantener la compatibilidad con la forma en que lo manejaba SourceSafe (todo en un archivo), pero se puede cambiar.

Saludos.-

[Carton Jeston]

Cuando instale plastic en su dia no desactive la opcion de office, una molestia verla ahi pero lo comentaba que ahora estoy pensando como sacarle partido con documentos que reviso. Ahora quiero usar control de version para todo  :-D

Tenia generados los db2 desde hace un tiempo pero lo saque todo del control. Acabo de actualizarlos y ya meto los db2 bajo control a partir de ahora.

La opcion classperfile no la conozco y aunque ahora tengo las clases separadas, creo que lo usare cuando me meta en programacion en capas. Tambien tengo una libreria con muchas funciones de proposito general, como letradni y cosas asi. ¿hay alguna opcion que las separe?

Y para acabar, un mirada hacia atras... cuando el tiempo te da la razon :-)

El viernes, 10 de junio de 2016, 14:24:20 (UTC+2), Fernando D. Bozzo escribió:Me alegra un montón que comiences a usar Control de Código. Ya descubrirás que, bien usado, luego no se puede vivir sin el :D
La separación que sí te conviene hacer es la de toda la vida, que es tener subdirectorios para FORMS, CLASES, PRGS, etc.

[Fernando D. Bozzo]

Para separar funciones (no clases) de una librería realmente no hay nada automático, pero siempre podés copiar cada método de la misma a otro sitio (ej: a un prg) directamente desde el vc2.

Respecto de la opción de clase por archivo, es una opción de todo o nada, o sea, para todas las librerías del proyecto o para ninguna, salvo que tengas un setup distinto en cada directorio y tengas 2 directorios de clases (no recomendable)

[Carton Jeston]

Me imagino que debe ser la modificación del archivo foxbin2prg.cfg.txt, cambiando 0 por 1 para cambiar esta funcion que esta en la carpeta programas-plasticscm5-vfp. (asi lo ilustro un poco para quien lo lea) :-)

*-- "CLASS PER FILE" OPTIONS (UseClassPerFile: 1) / OPCIONES DE "CLASE POR ARCHIVO" (UseClassPerFile: 1)
* UseClassPerFile: 0            && 0=One library tx2 file, 1=Multiple file.class.tx2 files, 2=Multiple file.baseclass.class.tx2 files including DBC members / 0=Una archivo librería tx2, 1=Múltiples archivo.clase.tx2, 2=Múltiples archivo.clasebase.clase.tx2 incluendo miembros DBC

Ahora un detalle interesante... Entre tantas opciones de los accesos directos, a veces tener el bin2txt o txt2bin tan cerca despues de unas horas quemandote los ojos con la pantalla me puede dar un susto. Por ejemplo, en windows he hecho una copia del "foxbin2prg - binary2text" como "#GENERATEXTO#" en el apartado send to y lo veo arriba del todo.

En PLASTIC en sus preferencias no parece que permita cambiar el orden una vez configurado (ignoro si hay algun modo), asi que he creado otro nuevo "cambios de txt a bin" abajo y he borrado el primero, asi que la primera opcion es la que siempre uso para regenerar textos a binario solo con cambios. Es una chapuza pero me evito problemas y si la opcion de regenerar el binario a partir del texto ya no es necesaria antes del checkit, casi mejor delegarla a un segundo plano o cuando creamos estas entradas durante la instalacion, tener en cuenta este detalle.

Menudo rollo he soltado, espero que se me entienda :-)

un saludo

[Fernando D. Bozzo]

El archivo de configuración para funcionar realmente se debe llamar foxbin2prg.cfg (sin el .txt final). Lo del .txt final lo puse hace bastante porque me habían solicitado si podía hacer algo para evitar que se sobreescriba este archivo cada vez que se bajaba de Thor o de GitHub, y por eso decidí renombrarlo para mantenerlo como documentación y que con quitarle el ".txt" funcione.

Como ves, usando 1 es solo para las clases y forms, y con el 2 también lo hace para los componentes de los DBC (conexiones, etc)

Lo de las preferencias en Plastic (el menú de opciones personalizado) lamentablemente solo permiten ordenarse en el orden en que las ponés, sin posibilidad de reordenar. El ordenamiento que elegí fue teniendo en cuenta las operaciones habituales y la agrupación fue a propósito para que las que actúen solamente sobre los "Cambios pendientes" estén bien separadas de las que actúan sobre "Todos los archivos", ya que al principio por tenerlas desordenadas me pasó más de una vez que al querer procesar solamente cambios pendientes (que ahora ubico primero) había elegido "Todos los archivos", y sobre un sistema con más de 1500 archivos.... era un poco demasiado :)

Además, dentro de cada grupo, mantuve el mismo orden interno (binarios / texto) ya que al comenzar a usarlo seguido, me dí cuenta que al final muchas veces terminás usando las opciones por la posición que tienen y ya no las lees (al menos a mí me pasó), y es más fácil y mecánico, pero bueno, al final es mejor que cada uno las ubique como mejor vea. Lo que pasa que cuando se debe hacer para normalizar en varias instalaciones, conviene que todos los desarrolladores de un equipo tengan lo mismo y de la misma forma, para que uno pueda usar el sitio de otro sin problemas.

Lo mío fue más rollo :D

[Fernando D. Bozzo]

Ah, olvidaba un punto:

En el "Send to" de Windows, yo prefiero usar directamente el acceso directo de FoxBin2Prg, porque dependiendo de si elegís un binario o un texto, te hace la conversión al opuesto, y si elegís un directorio te pregunta qué tipo de conversión hacer. Pero nuevamente, es cuestión de gustos y por eso están los scripts (.vbs) que convierten a un único sentido.

[Augusto Felix Ortiz]

Carton

Mañana te paso donde se guarda la configuración del menu para modificarlo por fuera de plastic

Augusto

 

Enviado desde mi teléfono con Windows 10

un saludo

 

 

[Carton Jeston]

Fernando, no es un problema real , solo me he percatado que tras varios dias maratonianos, cuando la cabeza y la vista estan agotadas, era facil cometer el error. Respecto al Send to, si usas Plastic no lo tocas, es mas bien si quieres usar Foxbin2prg independientemente. Al final es cuestion de preferencias de cada uno, lo importante es que funciona. ;-)

Augusto, he estado mirando en los .CONF, asi que no se si hay otro archivo o esta en alguna base de datos.

Gracias a ambos.

[Fernando D. Bozzo]

Hola, lo que comenta Augusto creo que está en un XML dentro del directorio de Plastic

[Augusto Ortiz]

Hola,

Aquí les paso el camino y el nombre del archivo que contiene la información del menú.

Dado que es una carpeta del perfil de usuario, deberán cambiar el nombre Augusto por el que les corresponda.

 

C:\Users\Augusto\AppData\Local\plastic4\openwith.conf

 

Abrazo

Augusto

 

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Fernando D. Bozzo
Enviado el: jueves, 25 de enero de 2018 05:00
Para: publice...@googlegroups.com
Asunto: Re: [vfp] Re: Nueva versión v1.19.47 de FoxBin2Prg

 

Hola, lo que comenta Augusto creo que está en un XML dentro del directorio de Plastic

 

 

[Carton Jeston]

Siempre se me olvida mirar dentro de esas carpetas, local, localLow o roaming, a pesar de que muchisimos programas la usan para sus cosas (no me gusta nada). En concreto, este archivo es de texto plano y con copia-pega puedes cambiar el orden de la lista sin problemas. Buen trabajo :-)

Tambien veo informacion que me ayuda a entender un poco la instalacion plastic y puede resultar muy facil portar toda esa configuracion a otro pc desde una instalacion original :-D

Gracias a ambos.

[Carton Jeston]

ah, una curiosidad dentro de las opciones de VFP... ¿para que sirve aqui plastic o es algo residual?

[Fernando D. Bozzo]

Esa opción de Plastic dentro de VFP habilita la API compatible con la antigua forma de trabajo de SourceSafe, donde se hacia chequin por archivo wn vez de lote de archivos como ahora.

Es horroroso ver un changeset por cada archivo e inmanejable. Lo probé en su momento con un proyecto de pruebas a ver qué pasaba, pero es un retroceso. Casi como usar SourceSafe, pero con un IDE más lindo.

[Carton Jeston]

Cualquier cambio mínimo requeriría varios changesets, una locura. Mejor nos quedamos como estamos que vamos bien :-)

un saludo

[Carton Jeston]

OT: El control de codigo tiene un problema, cuando lo pruebas todo tiene que tenerlo. Estaba mirando una herramienta para crear juegos para ZX Spectrum y... tiene control de codigo con git!!! .... igual me estoy obsesionando :D :D :D

[Augusto Felix Ortiz]

Jajaja asi es, a mi me pasa igual

Abrazo

Augusto

 

Enviado desde mi teléfono con Windows 10

 

De: Carton Jeston
Enviado: sábado, 27 de enero de 2018 10:07
Para: Comunidad de Visual Foxpro en Español

Asunto: Re: [vfp] Re: Nueva versión v1.19.47 de FoxBin2Prg

[Augusto Felix Ortiz]

Y otra cosa fantástica al menos con plastic, es que podes trabajar desconectado, por lo que cada desarrollador puede trabajar en su casa y luego conectarse y hacer los chekin…

En fin a mi me mejoro muchísimo el trabajo

Abrazo

Augusto

 

Enviado desde mi teléfono con Windows 10

 

De: Carton Jeston
Enviado: sábado, 27 de enero de 2018 10:07
Para: Comunidad de Visual Foxpro en Español

Asunto: Re: [vfp] Re: Nueva versión v1.19.47 de FoxBin2Prg

[Fernando D. Bozzo]

No sé si lo sabías, pero todo el repositorio de foxbin2prg en GitHub (https://github.com/fdbozzo/foxbin2prg.git) lo subo desde Plastic :)

PlasticSCM: Sincronización con GitHub

Podés crearte un repositorio local vacío y sincronizarlo con cualquier repositorio GitHub.

Como son casi todos públicos, solo necesitás tener una cuenta de GitHub.

Te podés bajar todo, aunque luego no puedas subir cambios (por los permisos).

Yo lo hice con un par de proyectos ajenos porque es muy interesante ver cómo crean las ramas los demás, cómo trabajan y qué cambios van subiendo.

Igual la opción de usar el cliente git es una buena opción. git es un muy buen cliente, aunque menos didáctico que Plastic :D

Saludos!

[Carton Jeston]

Lo de github lo puse como una curiosidad, si tuviera que hacer un control de fuente sobre un programa para ZX Spectrum o cualquier otra cosa, usare plastic que como bien dice, tiene la ventaja de trabajar desconectado. :D

[Fernando D. Bozzo]

Ojo que con el cliente git también se puede trabajar desconectado! Es un sistema DVCS distribuido como Plastic, por lo que se pueden crear repositorios git locales y luego sincronizarlos con repositorios externos.

De hecho, cuando se clona un repositorio git con "git clone" desde la ventana de comandos (o desde un gui), se crea un repositorio local donde se pueden hacer merges, moverse por el historial, hacer diff y todo lo demás!

La verdad que las opciones que hay ahora mismo de control de código son varias, y hace el panorama muy interesante y abierto, y la conectividad de Plastic con GitHub le da un plus muy útil.

[Carton Jeston]

He estado casi tres semanas fuera, así que retomo el programa y empiezo a trabajar. Ningún drama, ya que tras un breve repaso se por donde me quede a niveles subatómicos lo que antes era a ojimetro y siempre tenia problemas.

Definitivamente es control de código fuente es imprescindible en cualquier lenguaje y me doy cuenta del tiempo que perdía por no tenerlo por no hablar de la seguridad de revertir en cualquier momento. Lo digo por aquellos que leen y aun se lo están pensando, FoxBin2Prg+PlasticSCM es la OSTIA.

Aun me queda mucha practica para manejar con soltura en algunas situaciones, pero ya lo iremos viendo por aquí según puedan.

OT Nota aclaratoria del Viernes: ¿que es la ostia? Cuando te la coges con una mano, luego con la otra y lo que sobra, eso es la ostia :-)  Esto para diferenciar con blasfemar:  https://www.diccionariodedudas.com/hostia-u-ostia/

[Carton Jeston]

Una pregunta con miga...

Tengo mi PROGRAMA1, con su REPOSITORIO1 y su WORKSPACE1. El repositorio lo guardo en una carpeta D:\PLASTIC

Ahora tengo otra aplicacion llamada PROGRAMA2, REP2 y WORK2.

Cambio de workspace por defecto segun con que trabaje.

Los Workspace estan cada uno en su carpeta bien separados, pero los repositorios tengo la impresion que se guardan revueltos en la misma carpeta.

¿Hay algun modo de guardar los repositorios dentro de D:\PLASTIC con subcarpetas tipo D:\PLASTIC\PROGRAMA1 y D:\PLASTIC\PROGRAMA2?. Creo que no, pero tampoco se tanto del tema.

A la hora de hacer backups, me gusta guardar cada repositorio con su workspace, aunque por ahora parece que guardare todos los repositorios de la carpeta D:\PLASTIC y luego los workspace por separado.

¿alguna idea?

[Fernando D. Bozzo]

Hola:

Hasta donde yo sé, todos los repositorios Plastic se guardan en un mismo sitio, ya que solamente son las bases de datos, y creo que no se pueden cambiar las ubicaciones de forma independiente, ya que la misma indica la ubicación de todas las BDD.

Hay un tipo de backup en particular que resulta muy útil: La exportación a formato Git (Fast-Export)

https://fdbozzo.blogspot.com.es/2014/09/plasticscm-como-configurar-la.html

Lo bueno de esta exportación, es que al ser en un formato que es un estándar, se puede volver a importar luego en otro repositorio Plastic o incluso en uno de GitHub.

Yo lo he utilizado en algunos casos donde por algún motivo haciendo pruebas había dejado la BDD de Plastic con alguna incongruencia, entonces creaba una nueva BDD (Repositorio) y volvía a importar el archivo generado por el fast-export.

Es una buena opción para conocer.

Saludos!

[Augusto Ortiz]

Hola,

En mi caso utilizo SQL Server y cada repositorio se crea como una Base de Datos nueva con el nombre Plasticrep_x dónde x es el numero del repositorio (1,2,3,4…,n), por otro lado hay una Base Plasticrepositories dónde esta los datos de configuración general y referencias a cada Base Plasticrep_x, por lo tanto haciendo un backup de cada repositorio (Plasticrep_x y Plasticrepositories ) en tu workspace tienes el ordenamiento que buscas.

Desconozco con otras bases de datos como funciona.

Abrazo

Augusto

 

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Fernando D. Bozzo
Enviado el: domingo, 18 de febrero de 2018 20:10
Para: publice...@googlegroups.com
Asunto: Re: [vfp] Re: Nueva versión v1.19.47 de FoxBin2Prg

 

Hola:

Saludos!

 

 

[Carton Jeston]

Fernando, creo como tu que por lo menos con la version 5.4 no se puede, pero como siempre dando otras opciones para que no me aburra aprendiendo cosas nuevas :D Me apunto esto, que ya lo vi en tu blog pero aun no he llegado. Se parece mucho a un sistema de backup de un foro mysql que usaba.

Augusto, en sqlite te pone rep_1... rep_2... etc y no veo que separe como dice Fernando, asi que he pensado que quizas sea una opcion interesante (solo los de plastic sabran si es factible o no) en una futura version. De hecho, le he soltado el rollo en el foro de plastic...

http://www.plasticscm.net/topic/20514-possible-improvement-in-name-repositories/

Creo que tiene la utilidad de que si tienes la opcion de que guarde segun el nombre del repositorio, tendras los archivos en la misma carpeta pero numerados independientemente con su nombre correspondiente. A la hora de que exista un problema critico con el sistema, puedes guardar cada cosa sabiendo exactamente que es.

De momento, me conformo con hacer backup de todo y probare el Fast-Export para tener una opcion mas que la clasica del copia-pega.

Si alguien mientras sabe algo de esto o si lo arreglan, que lo suelte por aqui  ;-)

[Carton Jeston]

He recibido esta solucion al tema que comentabamos de los repositorios, sobre tener diferentes nombres o ubicaciones de los mismos al crearse en su carpeta. No se si lo acabo de entender, ¿permite subrepositorios o algo asi? Alguna idea vosotros que sois mas expertos?

you can create repositories like this:

c:\wkspaces\codice\01plastic\bin\client>cm mkrep core/area2 c:\wkspaces\codice\01plastic\bin\client>cm lrep --format="TABLE" 1 default localhost:8787 1_1 default/test localhost:8787 3 core localhost:8787 3_1 core/area1 localhost:8787 3_2 core/area2 localhost:8787

And you will get the indented structure but you can't customize the root ids (1 and 3).

By using the subrepositories you will create databases inside databases giving you less root databases to manage (good for big corporations).

[Fernando D. Bozzo]

La verdad es que no llegué a ese tipo de uso, pero según lo que entiendo por el ejemplo, permite crear las bases de datos en subdirectorios de donde las suele colocar, no en cualquier directorio a elección fuera del directorio de Plastic, que era lo que querías.

Pero igualmente podría servirte, aunque seguirías teniendo una carpeta para el desarrollo (el workspace) y otra para la BDD, aunque aislada de las otras.

[Carton Jeston]

Pues con la aclaracion que me hizo, me he dado cuenta que quizas no necesitaba tanto. La culpa la tiene este comando...

cm lrep --format="TABLE"

me genera esto:

 11 MYPROGRAM localhost:8087
 13 MYGAME localhost:8087
 14 test localhost:8087
 14_1 test/x1 localhost:8087
 14_2 test/x2 localhost:8087

Resulta que tengo repositorios REP_1 al REP_14 pero realmente MYPROGRAM (11) y MYGAME (13) serian los importantes. He preguntado para confirmar si los que no aparecen son restos de pruebas y se pueden eliminar, con lo que tendria identificados los repositorios realmente importantes y con eso me valdria.

Tambien he preguntado si se puede ver desde el "ide" la informacion dentro de un repositorio a que fichero pertenece aunque con el comando me vale.

Y lo ultimo, si una base de datos sqlite como REP_14 llega a su maximo fisico, si se crea un tipo de REP_14_0001 o algo parecido. Asi sabria que en esa carpeta de repositorios quien es quien y puedo tener bien diferenciados los diferentes proyectos, ya sean de fox, manuales de texto, juegos o lo que sea.

Que esten todos los repositorios juntos no es un problema siempre que esten identificados, al contrario para hacer el backup  me viene perfecto. La culpa de esto la tiene Fernando, ahora quiero usar el control de codigo hasta para la  lista de la compra. :D

Ya os dire cuando sepa algo mas.

un saludo

[Carton Jeston]

De momento tengo un bat que me puede ser util REPDIR.BAT

@echo off
cls
"c:\Program Files\PlasticSCM5\client\cm" lrep --format="TABLE"
pause

Que apunta al CM.EXE en la carpeta "c:\Program Files\PlasticSCM5\client\" donde deberia estar segun la version de plastic que tengas.

Ya se que esto es algo basico y no estoy descubriendo la rueda, pero nunca doy por hecho que todo el mundo lo sabe y pongo para que todo el mundo lo entienda aunque lo sepan. ;)

[Fernando D. Bozzo]

Cuando un repositorio se llena, tengo entendido que no se crea otro nuevo automáticamente, y por eso avisan de las limitaciones de tamaño de cada BDD. Por eso cuando se está llegando al límite, siempre se puede hacer un fast-export (es formato texto) y configurar Plastic para otra BDD más potente (e importar el fast-export anterior).

Yo por ejemplo desde hace bastante uso SQLite como BDD, y no creo que vaya jamás a usar los 140TB que permite :)

FireBird creo que permite 64TB

Lo qué sí, opciones no faltan :D

[Carton Jeston]

He tenido un lapsus de los buenos, no se porque tenia en mente los limites de 4GB en las FAT32, todo el dia arreglando problemas de uno y otro y se me mezclan las cosas :D

He rectificado la pregunta en el foro de plastic en este sentido y el de los repositorios no activos en la carpeta. He hecho una prueba (antes el backup) y he borrado todos los .SQLITE que no aparecen en la lista que genera el bat y el repositories.plastic.sqlite que es el indice de todos ellos y funciona a la perfeccion. Ahora se exactamente cada archivo de repositorio esta relacionado con el workspace o proyecto correspondiente.

Lo dicho, voy a usar control de fuentes para todo, incluso para manuales que voy creando y luego no se por donde lo deje :D

[Carton Jeston]

Confirmado por plastic.

Solo se puede saber via comando que nombre de repositorio corresponde a los archivos REP_xxx.SQLITE como ya apuntamos antes.

"c:\Program Files\PlasticSCM5\client\cm" lrep --format="TABLE"

Cuando haces muchas pruebas, tienes en la carpeta fisica de los repositorios un monton de REP_xxx y si quieres limpiar, hacer copias de seguridad o simplemente saber que es cada cosa es muy util.

En mi caso, he eliminado todos los .SQLITE EXCEPTO repositories.plastic.sqlite y los repositorios activos en PLASTICSCM y que me salen en la lista en consola.

Al ser una carpeta comun y unica, puedo usar plastic en otros proyectos, lenguajes o lo que se me ocurra, o bien copiar el repositorio y el workspace y trasladar todo un proyecto a otro pc, etc. Quizas no sea importante pero me gusta no ir a ciegas cuando se guardan datos valiosos :D

un saludo

[Carton Jeston]

Fernando, mira si puedes añadir este comando en tu articulo del blog sobre cambiar la ubicacion repositorios, asi no se pierde :D

[Fernando D. Bozzo]

Hecho! :)

[Carton Jeston]

Como siempre muy bien explicado y ampliado ;)

Por lo menos el tema de donde guardan los repositorios, como cambiarlos e identificar cada uno de ellos deja de ser algo casi esotérico y tendremos a buen recaudo la base de datos de plastic.

En este sentido, ya no hay nada mas que averiguar, aunque siempre me puedo inventar algo. De hecho ya estoy repasando otros articulos del blog... (suena a amenaza pero no...) :D

Ahora me pregunto si alguien no esta usando foxbin2prg+plasticScm, que se anime a invertir tiempo en adaptarse aunque sea un minimo de uso. Aun me falta controlar muchas cosas, pero el beneficio de tiempo y seguridad a estas alturas es muy grande. No es tan dificil ahora que lo veo en perspectiva, sobre todo por los nuevos conceptos y la forma diferente de hacer algunas cosas.

Y quizas el "miedo" de experimentar al principio, que puede ser subsanado sin problemas con copias de seguridad previas del workspace (proyecto) y los repositorios (base de datos plastic) y que espero que sirva para simplificar un poco a los que empiezan.

un saludo

[Fernando D. Bozzo]

Me alegra un montón que le hayas podido sacar provecho, y sobre todo que haya servido mi insistencia en los años previos, prácticas online incluidas (aunque no todos pudieron en su momento) :-D

[Carton Jeston]

Ya lo creo, a pesar de insistir que estoy lejos de dominar, pero la tranquilidad es grande.

Un ejemplo reciente... empece a trastear informes y al acabar nada de aquello valia... si se me hubiese olvidado una copia de seguridad tradicional antes de meterme con ello, seria un problema.Con el control de codigo, deshaces los archivos que te indica el propio programa y a seguir con otra cosa.

Son pequeños detalles que sumados se convierten en un metodo de trabajo imprescindible.

Tu sigue insistiendo que yo seguire entrando en bucle diciendo lo mismo al estilo machacon de una teletienda :-D