Prácticas de VFP 9 con control de código fuente desde CERO - PARTE 4 - Resolución de conflictos del Merge

[Fernando D. Bozzo]

Nota:

Quienes no hicieron las Partes anteriores, todavía están a tiempo, solo comiencen por aquí:

PARTE 1 - Instalación de Plastic y conociendo FoxBin2Prg

PARTE 2 - Ramas (Branches)

PARTE 3 - Merge

Es difícil que se pierdan, aunque no hayan hecho todo, cualquier cosa, pregunten!

Bienvenidos a la PARTE 4!

Para facilitar la ubicación y poder centralizar todo, les escribo las indicaciones directamente en este link:

PARTE 4 - Resolución de conflictos del merge

Las PARTES las iré publicando en un nuevo blog que hice para estas prácticas, así lo pueden consultar sin perderse y retomar desde donde lo hayan dejado.

Saludos!

[Fernando D. Bozzo]

Hola Fidel:

En el PASO 4 - A.2, cuando hiciste el checkin del form, solo debía subir el form, pero sin querer también subiste el proyecto (binarios solamente, sin texto)

Observaciones sobre el error:

- Al generar las vistas de texto, seguramente se generó la del form pero no la del proyecto, ya que éste no tiene cambios funcionales porque el form ya existía en el proyecto. Cuando la vista texto de un binario no se genera, lo mejor es deshacer los cambios del binario, ya que no tuvo cambios reales, y así no se protege algo sin cambios.

- Probá bajarte la última verisón de FoxBin2Prg (v1.19.36) que incluye una mejora sugerida por Marcio Gomez G. en la v1.19.35 para minimizar diferencias en los binarios

​

Explicación:

Lo de deshacer los binarios sin cambios reales es por varios motivos:

1. Para que no figuren en el changeset como cambiados y así poder ver la lista de archivos que tuvieron cambios reales
2. Para no ocupar espacio demás en la BDD de Plastic
3. Porque si de este changeset tuvieras que hacer un merge o cherry pick posterior, no vas a poder comparar el contenido del proyecto
   

Saludos! :D

[francisco prieto]

Fernando...

Arranque con problemas!!!

Parte 4 -A2...

Antes de hacer el checkin hice...

1) Abrir con (VFP) Cambios Pendientes: Regenerar versiones de texto y no hizo nada... incluso presione actualizar...

Entonces probe hacer 

2) Abrir con (VFP) Todos los archivos: Regenerar versiones de texto...

Ahi me aparecio la barra de progreso y sobre el final emitio el siguiente error:

​

Le doy aceptar, pero entiendo que antes de seguir intentando debo preguntarte que hago.

Saludos,

Pancho

Córdoba

Argentina

[Fernando D. Bozzo]

Hola Pancho:

Creo que tenés una versión algo antigua de los scripts, donde había un par con ese error.
Bajate la ultima versión de GitHub de aquí (el zip de la opción a la derecha) y reemplazá los que tenés:

https://github.com/fdbozzo/foxpro_plastic_diff_merge

Saludos.-

[Fernando D. Bozzo]

Ah, Pancho, una cosa más:

No olvides que si la vista de texto no se genera, es porque el binario no tiene cambios. Lo digo por el proyecto, para que no te pase lo mismo que a Fidel, que no sé si viste lo que le expliqué en el foro.

Saludos.-

[francisco prieto]

Fer,

Ahora no me dio el error pero me mostro como cambiados los archivos foxbin2prg y me los puso como parte del ckeckin... si presiono checkin me dice que no puede actualizar archivos de solo lectura, que creo son los del foxbin2prg...

Los desselecciono o que hago?

Saludos,

Pancho

Córdoba

Argentina

[Fernando D. Bozzo]

Hola Pancho:

¿Los accesos que estás usando a FoxBin de donde los estás tomando, de esta instalación de pruebas o de un directorio externo?

Por otro lado, no entiendo por qué te aparece como solo lectura, ya que es un directorio más en el proyecto. ¿Los archivos del directorio de FoxBin2Prg los tenés con el atributo de solo lectura?

Saludos.-

[Fernando D. Bozzo]

Pancho, volviendo a ver tu captura de pantalla, veo que el error del script te dá en el directorio:

c:\Instaladores\Plastic\foxpro_plastic_diff_merge-master

Con lo cuál hay 2 cosas por separado:

1) En ese directorio es donde deberías reemplazar los scripts y demás programas de FoxBin2Prg del zip que bajaste

2) En el directorio del proyecto no reemplaces los archivos. Creo que aquí te equivocaste y te olvidaste que los estás usando desde el otro directorio (1)

Una vez hayas hecho lo de (1), no deberías tener más problemas.


Saludos.-

[Fidel Charny]

Hola Fernando!

Ayer renegué toda la mañana con la Internet hasta que me decidí hacer los 50 metros que me separan del modem para resetearlo. Luego vi que todo empezó a andar normal, pero ya me iba. Había hecho la tarea el viernes a la tarde.

1) Siempre tengo la versión actualizada de Foxbin2prg. Normalmente abro el +Fidel y veo si hay alguna novedad tuya. (luego lo cierro, porque no me llama la atención y no sé qué utilidad podría tener). 

2) El problema se generó porque (por comodidad) abrí el proyecto y ahí saltó el mensaje de cambio de direcciones. Como lo confirmé, después generé el pj2. Pero ciertamente no generó uno nuevo.

3) Para evitar esos problemas, por ahora, mientras estamos haciendo cambios en 1 form, ataco directamente el form desde la ventana de comandos.

4) Tomo debida nota de este tema.

Muchas gracias

Fidel

[francisco prieto]

Fer,

Bueno el primer problema era que las librerias no se bajaron en el lugar correcto... pero eso lo solucione saliendo del plastic y ubicando todo donde correspondia...

Pero me aparecia el FoxBin2Prg  dentro de los cambio pendientes y los deshice...

Ahora bien, ahi quice hacer checkin y me daba error asi que antes de seguir metiendo la gamba me hice un shelve...

​

 shelveanteserror.PNG

​

y al querer el shelve borrar los pendientes tambien le dio el error:

​

 errorcheckin.PNG

​

Asi que bueno estamos frenados ahi...

Saludos,

Pancho

Córdoba

Argentina 

[Fernando D. Bozzo]

Hola Pancho:

La verdad es que no sé cómo llegaste a ese nivel de lío :D

Solo había que modificar un form, y el error te da efectivamente porque estás intentando guardar cambios en el directorio FoxUnit que es un XLink de sólo-lectura al respositorio de FoxUnit.

En ese directorio no hay que reemplazar nada, y el único cambio debería ser en tu form.

En casos como este hay que preguntarse: ¿tiene sentido guardar las versiones texto de archivos que sabés que no modificaste?

Respuesta: No, todo archivo que no hayas modificado, ni tenga relación directa con lo que modificaste, se debe deshacer.

Así que la solución es deshacer todo y volver a hacer el cambio del form (o volver a copiar el que tenías hecho). Respecto de los archivos que te aparecen por generar las vistas texto con el script de "Cambios Pendientes", deshacé todo menos el SC2 del form, y ahí vas a poder hacer el checkin.

Saludos.-

El 12 de octubre de 2014, 18:29, francisco prieto <fajp...@gmail.com> escribió:

Fer,

[Fernando D. Bozzo]

Pancho:

Mientras te escribía la respuesta anterior se me ocurrió que lo que pudo haber pasado es que en vez de usar el script de "Cambios Pendientes" usaste el de "Todos los archivos", y por eso te generó las vistas texto de archivos que no habías modificado.

Saludos!

[francisco prieto]

Fernando,

Si, precisamente esa es la primer accion que tome, si relees el primer mail que te envie de esta parte...

El tema es que no me deja deshacer... siempre me da error, con lo cual no se como continuar, lo unico que se me ocurria pero no quiero hacerlo sin consultarte es eliminar la rama 2 o dejarla como esta y hacer una nueva para seguir con el ejercicio...

Que te parece?

Saludos,

Pancho

Córdoba

Argentina

[Fernando D. Bozzo]

Pancho:

No llego a darme cuenta de por qué no te deja deshacer, pero se me ocurre una forma de arreglarlo.

La idea es rehacer el workspace dvcs_vfp9, que es lo más rápido

Hacé esto:

1) Cerrá Plastic

2) Borrá el directorio .plastic del directorio dvcs_vfp9

3) Abrí Plastic y create el workspace nuevamente vinculando el repositorio con el mismo directorio, lo que va a volver a crear el .plastic

4) Ya deberías poder seguir

Saludos!

[francisco prieto]

Stop!....

Mira lo que tengo en desa\dvcs_vfp9_red

​

 dvcsvfp9red.PNG

​

Me parece que saliendo de Plastic deberia borrar foxbi2prg y foxunit... Que vaya a saber como fueron a parar ahi...

Y luego reingresar...

No te parece?

Saludos,

Pancho

Córdoba

Argentina

[Fernando D. Bozzo]

Pancho, mejor borrá el directorio completo (todo lo que hay por debajo de dvcs_vfp9_red) incluyendo el .plastic, FoxUnit y FoxBin2Prg, pero no borres el propio dvcs_vfp9_red

Así volvés a vincular el workspace y este directorio con el respositorio, lo que va a crear todo otra vez. De paso te sirve para ver ante una catástrofe cómo se recupera todo :D

Nota: Los archivos no los vas a ver apenas crees el workspace, sino cuando selecciones el changeset de donde vayas a seguir trabajando.

Saludos.-

[Fernando D. Bozzo]

Pancho, te mandé un mensaje a Hangouts, pero no sé si lo usás.

Podés acceder desde Gmail, desde Google Plus o desde la app de Hangout en Android

Saludos.-

[Fernando D. Bozzo]

Esto es lo que se ve en la rama /main al elegir el menu "ver" / "Explorar repositorio en esta rama"

​

[francisco prieto]

Fernando,

En el punto A3... antes de hacer un merge en la rama de la tarea, no hay que hacer un checkin con el boton_A...

Es decir el merge no habia que hacerlo sin cambios pendientes?

Saludos,

Pancho

PD: La buena noticia es que ya estoiy en A3!!!

[Fernando D. Bozzo]

Hola Pancho:

Para esta parte ya estoy asumiendo que saben que cuando se modifica un componente, antes de hacer el Merge a otro sitio hay que hacer el checkin de los cambios.

Algunos pasos intermedios no los pongo para ver si ya tienen adquirido el conocimiento.

En este caso tu intuición es correcta, acabas de hacer un cambio y falta hacer checkin antes de pasar los cambios con un Merge a otra rama.

[francisco prieto]

Listo...

Punto A replicado...

Aunque al replicar queria exportar un cambio en la rama main y me daba error, pero como la rama main es tuya exclui esa rama...

Saludos,

Pancho

PD: Mañana sigo si me autorizas con el punto B

[Fernando D. Bozzo]

Hola Pancho, la rama Main la estoy llevando yo porque haciendo de integrador de proyecto, como en la vida real cuando hay un proyecto y varios desarrolladores.

Si querés que integre tu rama en main , solo decime y lo hago.

De paso coméntame el cambio que querías poner en main y como lo estabas haciendo (mandá una captura)

[francisco prieto]

En realidad no queria hacer ningun cambio en main, por eso descarte esta rama al sincronizar... se ve que entre tantas idas y venidas algo habia quedado mal y me marcaba con un signo de admiracion sobre main, donde a pesar que era un cambio no lo podía replicar...

Lastima que no me avive de imprimirte la pantalla... bah, me avive, pero ya no te queria molestar, alla era muy tarde...

La sincronizacion la hago con la vista de origen y destino como siempre... cuando me aparecia este error al querer sincronizar lo podes saltear al error con lo cual queda pendiente de actualizacion.

Me acuerdo haberle dado clic para ver que era... y simplemente era la fecha y nuestros usuarios sobre el archivo de proyecto. Ese changeset lo unico que hacía era poner mi formulario dentro del proyecto, porque esta fuera del mismo... pero no es relevante que hagas ese cambio.

Saludos,

Pancho

Córdoba

Argentina

[Fernando D. Bozzo]

Hola Pancho:

Viendo tus cambios creo que entendí lo que querías hacer: agregaste tu form al proyecto (2 veces, como pongo en la captura), y luego quiciste actualizarlo en /main para que todos lo tengan actualizado.

​

Te comento los errores y soluciones de esto:

1) Modificar el proyecto para agregar tu form en 2 changesets distintos es un error:

Una buena forma de hacerlo es creando una subrama de la tarea, en el mismo changeset del que creaste la nueva rama fajprieto2 (el de arriba a la izquierda, en la imagen), así de esa forma tendrías una versión de la rama que no incluye los cambios de fajprieto2 y que solo incluiría lo que ya había. En esta rama paralela podías actualizar el proyecto solamente, hacer el checkin y finalmente nivelar desde esta nueva rama, el resto de tus ramas (la de tarea, fajprieto y fajprieto2). Así el cambio lo hacías una sola vez y lo integrabas 3 veces con merge automático.

2) Actualización de rama /main cuando hay un Integrador:

En este caso, para que tus cambios los puedan tener todos, la solución era simple: se pide al Integrador (en este caso yo) que actualice la rama /main con tu rama de tarea.

Cuando hay más de 1 desarrollador en un proyecto, siempre es conveniente que solo 1 se haga cargo de la integración en la rama /main, para evitar conflictos.

Aunque el conflicto se pueda resolver sin mayores problemas, la situación que se intenta evitar es que Persona1 haga checkin en /main y Persona2 haga lo mismo en otro momento, sin saber que Persona1 lo actualizó, lo que puede crear una actualización de doble-cabeza, ya que Persona2 tenía la "casa" en la que creía que era el último changeset de /main, pero dejó de ser cierto cuando Persona1 actualizó /main.

Saludos.-

[francisco prieto]

Muy buena la aclaración, aunque todo estos errores salieron de casualidad, porque la prueba era solo hacer un botón A o B en cada una de las ramas para resolver los conflictos de merge... no estuvo nunca en mi intención prestar atención a que al incorporar en ambos casos mi formulario al proyecto eso podría causar inconvenientes..

En cuanto a decirte, me parecía que no hacía falta, ya que todo esto es un simple (mas bien bastante complejo :) trabajo en equipo y el estar mi formulario o no en el proyecto no era algo imprescindible...

Bueno, si te parece sigo adelante.

Saludos,

Pancho

[Fernando D. Bozzo]

Sí, continuá. Cuando terminemos esta práctica vamos a hacer nuevamente una actualización de /main (yo) y luego la nivelación de las ramas de cada uno desde /main.

Cuando hagamos eso, como tu versión del proyecto ya incluye tu form, entonces todos vamos a tener el proyecto actualizado con lo que faltaba.

Saludos!

[francisco prieto]

Fernando,

Una cosa interesante para observar y preguntar...

Hasta ahora en mis programas uso a menudo Version(2) para saber si estoy en modo ejecucion o en modo diseño....

http://msdn.microsoft.com/en-us/library/aa978650(v=vs.71).aspx

Pero no conocía la existencia de StartMode, que parece tener mas posibilidades...

http://msdn.microsoft.com/en-US/library/67h9h3s2(v=vs.80).aspx

Como veo que usas esta última podrías explicarme alguna diferencia mas... ya que los help no las relacionan.

Saludos,

Pancho

Córdoba

Argentina

[Fernando D. Bozzo]

Hola Pancho:

Nunca usé version() para saber si estoy en modo desarrollo, siempre usé StartMode, ya que me da lo que necesito, que es saber si estoy ejecutando en modo interactivo (do programa. Prg) en modo exe, modo objeto ,o cómo. Los valores de la tabla indican esto.
Por ejemplo, en modo desarrollo (interactivo ) suelo mostrar mensajes o activar alguna opción de depuración que en modo exe desactivo.

[francisco prieto]

Ok,

Entonces le tendría que preguntar a alguien que haya usado ambos... ;D

El version() en mi caso lo uso ademas para otras cosas, porque como manejo mi aplicación por versiones en red si la pc del cliente es una versión inferior a la del servidor esta se actualiza automáticamente...

También al detectar que estoy en modo diseño interactúo con el debugger... en fin me llamo la atencion la propiedad y queria saber que me aportaba...

Sigo con Plastic...

Saludos,

Pancho

[francisco prieto]

Fer,

Tengo un problema con B2... En fajprieto el unico boton que existe es A... A y B existen en la rama de la tarea despues del merge que resolvi a mano en A.... Como sigo?

Saludos,

Pancho

Córdoba

Argentina

[Fernando D. Bozzo]

Hola Pancho:

Estoy viendo la ayuda de version(2):

Visual FoxPro version type:

0 - Run time version
1 - Standard Edition (earlier versions)
2 - Professional Edition (earlier versions)

Realmente no sé por qué la usás, ya que tenía sentido para distinguir entre las versiones que dice ahi, pero ¿de qué sirve esa información? o sea, ¿qué importa si el que ejecuta tiene la versión Runtime (lo que se distribuye), la Standard (el IDE más barato) o la Profesional (el IDE más caro)?

Ya te puedo decir que entre ambas la función Version() y la propiedad _VFP.StartMode no hay ninguna similitud

De cara al desarrollo y la ejecución, lo que realmente te importa es saber si estás ejecutando desde la ventana de comandos (o sea, modo desarrollo), desde un EXE, desde una DLL o como un objeto, ya que para cada caso podés tomar distintas decisiones.


El ejemplo más simple donde se usa, es para salir de un programa:

- Si estás en modo EXE (StartMode=4), vas a necesitar usar QUIT, porque si no te podría quedar el ejecutable oculto pero activo, dependiendo de cómolo hayas programado.

- Si estás en modo desarrollo (ejecunatdo desde la ventana de comandos Fox), entonces te va a interesar que al terminar el programa, salga con RETURN y no con QUIT, porque si no vas a tener que volver a abrir y configurar algunas cosas nuevamente, lo que a veces es una pérdida de tiempo, sobre todo cuando querés hacer pruebas rápidas entrando y saliendo del programa

- Si estás ejecutando en modo objeto con createobject(), no vas a querer salir con QUIT tampoco, porque si no, cerrar el objeto te terminaría la aplicación que lo usa...

- Si estás en modo DLL/EXE (COM+), probablemente te va a interesar salir con QUIT, ya que es una instancia separada en memoria, que de otra forma podría quedar en memoria.

Y finalmente tenés las condiciones que quieras habilitar dependiendo del tipo de programa que hagas. Por ejemplo, si el programa que hacés está pensando para ser usado como EXE, entonces hay cosas de depuración que podés habilitar solamente cuando ejecutes en modo Desarrollo (ventana de comandos Fox), ya que podrías asumir que si ejecutás desde ventana de comandos es porque querés depurar algo, y que desde un EXE no podés.

O imaginate un SET STEP, que se te pueda olvidar. Si no lo condicionás para _VFP.StartMode=0, cuando se ejecute (porque te olvides de quitarlo) en el EXE te saldría un error de "Característica no disponible", al igual que algunos otros comandos o funciones que están pensados solamente para el modo Desarrollo.

Si mirás el inicio de FoxBin2Prg vas a ver este código de salida:

IF _VFP.STARTMODE # 4
    STORE NULL TO loEx, loCnv
    RELEASE loEx, loCnv
    RETURN lnResp
ENDIF

IF EMPTY(lnResp) OR VARTYPE(loEx) # "O"
    STORE NULL TO loEx, loCnv
    RELEASE loEx, loCnv
    QUIT
ENDIF

*-- Muy útil para procesos batch que capturan el código de error
DECLARE ExitProcess IN Win32API INTEGER ExitCode
ExitProcess(1)    && Esta debe ser de las últimas instrucciones
QUIT

Como FoxBin2Prg está pensado para ser usado como PRG, EXE u Objeto, entonces solamente me interesa controlar que si no se usa como EXE (StartMode # 4), entonces salga con RETURN (o sea que se está usando como PRG u objeto)

En cambio, si se usa como EXE y no hay errores, salga con QUIT.

Finalmente, si se usa como EXE y hay errores, me interesa que salga con ExitProcess(1), lo que permite que si es llamado desde un programa externo, como Plastic o cualquier otro, puedan recibir como resultado de la llamada 0 (ok) ó 1 (error), que es la respuesta típica de los programas.

En fin, tiene mil usos, espero que quede más claro ahora.

Saludos.-

[francisco prieto]

Perfecto,

Solo te digo que si version(2) devuelve 0... significa que no estas en modo diseño y es asi como lo uso y funciona...

De todos modos la propiedad que vos usas es muy superior...

Gracias por tomarte el trabajo de investigar la respuesta.

Saludos,

Pancho

Córdoba

Argentina

[Fernando D. Bozzo]

¡Y es correcto! Cada botón existe solamente en su rama de trabajo particular y ambos están solamente en la de la tarea, que aúna las ramas de trabajo particulares.

Esta práctica para que se vea cómo se pueden desarrollar características por separado en distintas ramas de trabajo, cómo se pueden combinar en la rama de tarea para probar todo junto, y cómo se puede quitar alguna característica que no te interese por el momento, gracias a haberla trabajado en su propia rama :D

Si la genialidad de poder usar una herramienta de control de código es poder llegar a ese nivel de abstracción de poder "armar" tu aplicación con los sub-desarrollos que hayas separado en ramas, según lo que te interese o necesites :D

Te comento un caso real que nos toca cada dos por tres:

Imaginate que tenés una Release de producto con varias peticiones de evolutivos y correcciones, donde cada petición la desarrollás en su propia rama. Algunas peticiones son más costosas que otras, por ejemplo puede haber una petición que se haga en 4 horas y otra que requiera 3 semanas.

Ahora imaginate que estás cerca de la fecha de entrega, y que la petición más larga no llegás a terminarla, por lo que, para cumplir con la fecha inicial, decidís excluir la petición larga y la dejás pendiente para la próxima Release.

Lo que hacés, en este caso, es un merge sustractivo de la rama de tarea entera (la petición) y solamente generás la Release con el resto de peticiones. Luego, como la rama de tarea no la borrás, la continuás desarrollando hasta finalizarla y la incluís en la siguiente release usando un Cherry Pick ignorando el merge tracking (a que te suena... :) para volver a integrar la rama.

....si al final, saber manejar esto te da unas posibilidades que a muchos les suena a ciencia ficción y para nosotros es la realidad al alcance de la mano, y además en Fox :D

Me emocioné, :D

Una abrazo

[francisco prieto]

Fer,

Lo que digo es que siendo asi no puedo realizar el ejercicio.... mira lo que dice el ejercicio...

Pásense a vuestra otra rama de trabajo ("usuario") y en el evento click de cmdBoton_B, agregar lo siguiente al final y luego hagan checkin de los cambios

IF _VFP.StartMode = 0 THEN
   MESSAGEBOX( "Modo Desarrollo" )
ENDIF

como no tengo  cmdBoton_B, pregunto debo crear un boton B, ya que si pongo eso en el boton A no va a dar resultado el test...

O estoy estendiendo todo al reves hoy?

Saludos,

Pancho

Córdoba

Argentina

[Fernando D. Bozzo]

Tenés razón, lo acabo de corregir. Es el botón A para usuario, y el B para usuario2.

Saludos.-

[francisco prieto]

Fer,

Siguiendo con Plastic tengo el siguiente inconveniente despues de hacer B3 me sale la siguiente pantalla...

​

 despuesb3.PNG

​

El tema es que estos dos si bien son binarios no se si quedarme con los que estan en el origen o con los de mi espacio de trabajo...

Saludos,

Pancho

[Fernando D. Bozzo]

Hola Pancho:

Eso está en el artículo sobre merge, luego de la mitad, con la explicación de por qué:

​

[francisco prieto]

Ok,con mi error, pero B4 tambien fue automático...

Saludos,

Pancho

[francisco prieto]

Te paso la imagen de mis ramas para que verifiques que hice lo correcto

​

 DespuesB4.PNG

​

Creo que el error es que no modificamos un mismo procedimiento en ambas ramas y por eso no hubo conflicto...

Ya que después de eso hice B5 y funciona tal cual predijiste que lo haría...

Te espero para que me digas si sincronizo o no.

Saludos

Pancho

[Fernando D. Bozzo]

Hola Pancho:

Está bien lo que hiciste.

Reviendo el ejercicio, veo que originalmente lo había puesto de una forma y luego, no sé por qué, lo terminé dejando de otra que no cumple totalmente el objetivo inicial.

Saludos.-

[Ricardo Pina]

Hola Fernando

Estoy intentando hacer el merge de la rama usuario a la rama de tarea  (Punto A3) y aparentemente procesa los merge pero me deja en pantalla los 2 archivos del formulario.

Te muestro la pantalla como queda


​

Me quedaría probar el formulario resultante y hacer el chekin antes de sincronizar al repositorio, pero no se si realmente hizo el merge o debo entrar en algún otro punto antes de seguir.

--

            

                   Ricardo Pina

Desarrollo y Servicios Informáticos

                  Profesionales
               www.dsip.com.ar

 

 

[Ricardo Pina]

Hola

Ejecute el formulario y solo m trae el boton B del merge anterior, o sea que no completo el segundo merge.

Espero a ver como seguir :-(

[Fernando D. Bozzo]

Hola Ricardo:

Lo del Merge (y los binarios que quedan pendientes) estaba explicado en el artículo de PlasticSCM: ¿Qué es el merge?, después de la mitad:

El paso 2 implica seleccionar todos los binarios que se muestran en esta ventana de Merge y descartarlos, lo que significa dejar los que ya existen en el workspace (también llamado Destino), ya que han quedado desactualizados porque los cambios reales del Merge los hicimos en las versiones texto, como vemos en la siguiente imagen:

(el resto está en el artículo)

Creí que esto ya estaba sabido :'(

[Ricardo Pina]

Hola

Ahora que lo mencionas, recuerdo eso de descartar los binarios.

Mas tarde retrotaigo y vuelvo a hacer el merge.

No des nada x sabido. Mi cerebro es lo mas parecido a una nuez. :-(

[Ricardo Pina]

Hola Fernando

Hoy Intenté terminar con la Practica 4, pero al intentar hacer el Merge Avanzado - Cherry Pick no encontró ningún cambio

No me doy cuenta en donde esta el problema

TE mando la captura de la rama para que evalues, el formulario esta con las últimas modificaciones y bien

​
​

Espero comentarios a ver donde me aparte del camino, jaja

[sergio alejandro garcia mendez]

Buenas donde puedo entrar para ver y empezar mi curso me interesa mucho.

Saludos

--

Sergio A. García
correo tayi...@gmail.com

[Ricardo Pina]

Hola Sergio

En el comienxo del hilo puedes ver los link de las prácticas

Comienza leyendo la Practica1, seguramente Fernando mañana te dará de alta tu rama de trabajo si es que aún no la tienes.

Saludos

[Fernando D. Bozzo]

Hola Ricardo:


​

​En el punto C hicimos la desintegración de un cambio, simulando que tenía errores que antes deben corregirse. Este paso implicaba seleccionar 2 changesets de la rama a desintergar. Lamentablemente no fui demasiado claro respecto de esto, lo que hizo que todos lo hagan de la forma simple (como vos) y no de la otra, por lo que acabo de agregar algunas imágenes. Si mirás tu rama de trabajo vas a ver que de ella salen 2 merge a la rama de tarea, y lo que hiciste realmente fue deshacer solamente el segundo merge, cuando la idea era deshacer todos los cambios de esa rama.

En el punto D corregimos esos errores en su rama original (ricpina2 en tu caso)

En el punto E reintegramos los cambios con las correcciones de la rama de trabajo, por lo que había que hacer Cherry Pick, pero en vez de eso hiciste Merge, donde ya se incorporaron los cambios. Ahora estás intentando hacer el cherry pick sobre un merge que ya había reincorporado los cambios, y por eso no ves más cambios, porque ya está todo ahí.

Realmente con esto ya terminaste la práctica!

Lo que si, te recomiendo ver en mi rama (tarea-025) cómo hice el merge sustractivo y el cherry pick posterior, así vas a poder comprobar que por hacerlo de esa forma me mantuvo las modificaciones completas de la rama de tarea, que enste caso agregaba el botón B (doble click en la rama de la tarea ricpina2 te muestra todos los cambios acumulados de esa rama en todos los changesets que tenga).

Si querés repetir esta parte desde el merge sustractivo para que puedas terminar la tarea de la forma que estaba prevista, avisame y te digo cómo se hace, que es muy fácil, y que de paso te sirve para hacer simulaciones de "cómo quedaría esto si lo hago así" (ahora que lo pienso, de esto último podría hacer un pequeño artículo, ya que las simulaciones son muy útiles)

El 31 de octubre de 2014, 1:22, Ricardo Pina <ric...@gmail.com> escribió:

Hola Fernando

Hoy Intenté terminar con la Practica 4, pero al intentar hacer el Merge Avanzado - Cherry Pick no encontró ningún cambio

No me doy cuenta en donde esta el problema

[Ricardo Pina]

Hola Fernando

Algo de eso me imaginaba pero pudo más el gen argentino y opté por el camino facil, jajaj

Lo vuelvo a hacer, espero tu nuevo artículo de simulación o elimino los cs.E, D y C en ese orden Y los rehago.

Cuando estaba x hacer el merge substractivo se me presento la duda si debía marcar más de un cs., pero no me daba cuenta de cuales debían ser ya que el cs anterior correspondia al merge de la otra rama y le hice caso al gen argentino.

Saludos

[Fernando D. Bozzo]

Hola Ricardo:

No borres nada, que si no se va a complicar. Acordate que estando todo replicado hay que borrarlo de todas las replicaciones para que realmente se borre, o sea, en mis 2 servidores, en el tuyo, en el de Fidel y en el de Pancho, así que eso se complica.

Para hacer la simulación es fácil, desde el changeset B4, que es donde estaba el merge de ricpina2, create un rama "tarea-009-B", con lo que vas a tener una copia hasta ese punto inclusive:

​
Luego tenés que:

• Repetir la práctica del merge sustractivo (punto C del blog), para hacerlo como indica en la imagen que agregué al Blog
• El punto D lo saltéas, porque ya lo tenés hecho
• El punto E acordate que es un cherry pick lo que hay que hacer, y no un merge normal
  

Al final con esos dos pasos (C y E) ya lo tendrías bien.
Recordá que cuando hable de la rama de tarea ahora va a ser la "clonada" (tarea-009-B).

Cualquier duda avisame,

Saludos.-

[sergio alejandro garcia mendez]

Tengo una consulta sobre PLASTIC SCM este es un software de 30 días? en que otro software seria funcional si este deja de funcionar al tiempo o hay que comprarlo por medio tuyo.

Saludos

[Fidel Charny]

Sergio

Disculpa que me meta de "comedido" en esta respuesta. Pero, sinceramente, hay algo que me molesta y me lo quiero sacar de encima. 

1) No creo que Fernando D. Bozzo sea un vendedor de Plastic SCM. Nunca ofreció vender nada. Al contrario, algunos del foro utilizamos su tiempo y sus conocimientos sin costo alguno, ya por su curso de Plastic SCM, ya por los artículos de su blog. 

2) Fernando D. Bozzo es el creador de Foxbin2prg, programa que se ofrece a la comunidad en forma gratuita y que es la herramienta que permite el merge dentro de Plastic SCM y una serie de trabajos adicionales para los que se puede aprovechar.

3) Yo instalé una "free Plastic SCM Community Edition license" en abril y no tengo problemas. Solamente respondí como mejor pude una encuesta que me envió el Sr. Pablo Santos (fundador de Codice Software que tiene a Plastic SCM).

[sergio alejandro garcia mendez]

Pues nunca he dicho que sea vendedor esa es mi consulta que ofendidos son mis estimados ya que como me parece una buena herramienta quería salir de la duda para aplicarlo no para que se entre en discusiones sin sentido.

Pero gracias ya me contestaste a lo que necesitaba si no vence el programa.

Saludos

[sergio alejandro garcia mendez]

Y pregunte porque empece a ver que tenia solo 30 días de prueba he me entro la curiosidad, pero bueno como siempre aquí se jalan los pelos por los demás que mal.

Saludos

[Fernando D. Bozzo]

Hola Sergio:

No te preocupes, tu pregunta no me cayó mal para nada.

Como comentó Fidel, yo conocí ese programa hace 2 años porque vinieron a la empresa donde presto servicios a hacer una demo, y me pareció excelente.

Luego, el año pasado, la empresa decidió comprar las licencias para todos los equipos de desarrollo y yo lo comencé a usar en paralelo de forma particular para mis desarrollos personales, entre ellos FoxBin2Prg :D

Me pareció tan bueno y me gustó tanto lo de la "Licencia Comunitaria" sin coste, que me dije que era buena idea darlo a conocer y ayudar a otros que nunca usaron control de código fuente o que usaron otras herramientas más antiguas (yo usaba SourceSafe antes, por ejemplo), y así fue como nacieron los 2 cursos que hicimos en el foro, y para lo cuál hice el segundo Blog que es solo para las prácticas.

Lo de la licencia lo cambiaron hace muy poco, y ahora tenés por defecto la licencia de 30 días de prueba, pero podés escribir a Códice para solicitar la Licencia Comunitaria de forma gratuita por un año, y renovable cada año.

Esto es todo. Espero haberte despejado las dudas,


Saludos!

[sergio alejandro garcia mendez]

Nítido eso quería saber te agradezco muchísimo tu ayuda Fernando al grano.

Saludos

Pero para ser de esa comunidad no debe ser software Open Source ya que eso me confunde.

[Fernando D. Bozzo]

El 20/11/2014 23:38, "sergio alejandro garcia mendez" <tayi...@gmail.com> escribió:
>
> Nítido eso quería saber te agradezco muchísimo tu ayuda Fernando al grano.
>
> Saludos
>
> Pero para ser de esa comunidad no debe ser software Open Source ya que eso me confunde.
>

No entiendo bien, es pregunta?