2010-11-03 9 views
13

versión corta:Perforce: Encuentra lista de cambios de origen de una rama

Después de ramificación en P4, ¿cómo puedo encontrar la lista de cambios "fuente" de la rama?

Versión larga:

Digamos que tengo una rama principal de mi proyecto en

//project/main/... 

La última lista de cambios presentado aquí es @ 123, cuando decido crear una rama de la versión 1.0 en

//project/1.0/... 

De P4V, se crea una nueva lista de cambios (digamos @ 130), resuelta y enviada.

desde la CLI, se vería algo como esto:

p4 integrate -c 123 -o //project/main/... //project/1.0/... 
p4 submit 

Más tarde, miro las listas de cambios bajo //project/1.0, y ver la lista de cambios @ 130 contiene una gran cantidad de archivos ramificados. ¿Cómo puedo averiguar la lista de cambios no. que esto fue originalmente ramificado de (es decir, @ 123)?

+0

Nitpick: El comando CLI es 'p4 integrate // project/main/... //project/1.0/...'. ('-c 123' fallaría porque' -c' especifica una lista de cambios * pending *. En su ejemplo 123 es una lista de cambios ya * enviada *.) –

+0

@Jon ¿Trabaja para Perforce? Sucede que contacté con su apoyo ayer y señalaron el mismo error que cometí :). El momento fue perfecto. Por cierto, sugiero que use 'p4 filelog' básicamente con los mismos parámetros que usas para' p4 changes', pero creo que tu solución da resultados más claros (es decir, puedo mirar la lista de cambios que necesito, en lugar del "filelog "versión que es mucho más detallada". –

+0

Sé que di una respuesta incorrecta originalmente, pero la revisé totalmente y procedí de una manera totalmente diferente. Solo quería notificarte; No estoy seguro de si los solicitantes son notificados de las respuestas revisadas o no. – Chance

Respuesta

8

p4 changes mostrará una lista de listas de cambios presentados, opcionalmente se filtró para una ruta específica.

p4 changes //project/main/... 
Change 123 ... 'Very last change.' 
Change 122 ... 'Next-to-last change.' 
Change 100 ... 'Only two changes to go...' 
... 

no es una sorpresa, pero, como usted ha encontrado, p4 changes es menos útil al integrar todos esos cambios en un solo cambio:

p4 changes //project/1.0/... 
Change 130 ... 'Integrated everything from main.' 

El truco es utilizar la opción -i que incluye cualquier lista de cambios integrada en los archivos especificados.

p4 changes -i //project/1.0/... 
Change 130 ... 'Integrated everything from main.' 
Change 123 ... 'Very last change.' 
Change 122 ... 'Next-to-last change.' 
Change 100 ... 'Only two changes to go...' 
... 

para obtener exactamente lo que quiere (123) que necesita para escribir un guión que filtra la salida de p4 changes -i //project/1.0/... para eliminar cualquier cambio que aparece por p4 changes //project/1.0/... (y luego tomar el cambio restante más reciente).

(Al explorar, con frecuencia también encuentro la opción -m max útil. Este límites cambios en el 'max' más reciente. Esto ayuda a su salida no fluya fuera de la pantalla cuando hay muchos cambios.)

+0

Pero, ¿tengo garantizado que el cambio más reciente en 'p4 cambia -i' que no está en' cambios p4' será el padre de un conjunto de cambios determinado? Puedo fusionar el conjunto de cambios 123 en la rama X, y luego fusionar el conjunto de cambios 20. Entonces, ¿cómo puedo encontrar directamente el elemento primario de un determinado conjunto de cambios? –

+0

@AlexanderBird, no, no creo que esta solución funcione al fusionarse en cambios que ocurrieron antes de los cambios que ya se han fusionado. –

+0

No es muy útil en bases de código grandes. 'Demasiadas filas escaneadas (más de 9000000); ver 'p4 help maxscanrows'. ' – Calmarius

0

Respuesta corta:

Usar el gráfico de revisiones en P4V es un paso atrás en el tiempo e investigar la historia de integración. Video on the Perforce website.

He utilizado con éxito el gráfico de revisión en las ramas con miles de archivos para seguir cuando un cambio en particular se integró en una rama. Es por eso que lo recomendé y lo vinculé a un video de capacitación ya que la mayoría de la gente lo subestima porque no saben cómo usarlo.

Respuesta larga:

... [Eliminado]

ACTUALIZACIÓN: Como el gráfico de revisiones al parecer, es inviable, puede resolver este quizá mediante un proceso/política, es decir, cuando se realice la integración, agregue una nota en la descripción "Branched @ CL 123". Usamos este enfoque nosotros mismos al integrar desde un troncal a líneas de liberación.

+0

Tener un par de cientos de archivos en cada rama hace que el enfoque 'Ver gráfico de revisión' sea inviable, desafortunadamente. Como el comando que crea la integración especifica la lista de cambios de origen, esperaba que la información se guardara en alguna parte y no sé dónde buscarla. Supongo que siempre existe el enfoque confuso de verificar las marcas de tiempo de las listas de cambios en la rama fuente y encontrar la más cercana a la marca de tiempo de la integración. –

+0

Con respecto a la actualización de su respuesta: * utilizamos * algo similar en nuestro proceso; Solo esperaba que hubiera una manera automática, y a nadie le importaba buscarla. –

1

No conozco ningún comando simple que realice lo que le gustaría hacer. Si usted está dispuesto a la escritura un poco y el comando no tiene que ejecutar rápido que tal vez podría intentar algo así como la escritura de los siguientes para todos los archivos ramificados:

  1. encontrar el archivo fuente/revisión de un archivo objetivo

    p4 FileLog //project/1.1/foo.bar#1
    //project/1.1/foo.bar
    ... # 1 6416 cambio rama en 2009/07/10 por foo @bar (texto) 'Release 1.1'
    ... ... rama de // project/main/foo.barra de # 1, # 2

  2. Obtener la lista de cambios a la que fue sometido el archivo de origen/revisión.

    p4 fstat //project/main/foo.bar#2
    ... depotFile //project/main/foo.bar
    ... headAction edición
    ... texto headType
    ... headTime 1201771167
    ... headRev 2
    ... headChange
    ... headModTime 1201770971

  3. Repita para todos los archivos en la rama y seleccione el cambio más alto no (headChange anterior), que debe ser el último cambio enviado al padre antes de la bifurcación para ese archivo específico. Puede obtener una lista completa de todos los archivos bifurcados utilizando, p. "p4 archivos //proyecto/1.0/...#1".

(o tal vez tomar el camino más fácil y pedir ayuda Perforce)

0

respuesta Actualizado: Creo que esto va a funcionar. Pruebe esto:

p4 interchanges from_branch to_branch 

Esto mostrará los cambios no integrados de su rama principal a su rama de publicación. Creo que puedes usar el número de lista de cambios superior menos 1 para encontrar tu lista de cambios de origen. interchanges es una característica de CLI de Perforce no documentada. Para obtener más información, escriba p4 help interchanges para obtener más información sobre este comando.

Nuevamente, I piensa esto funcionará. Puede haber algunos casos especiales en los que no será así, pero creo que es un problema difícil e importante.

+1

Nitpicking bit: si la rama se ejecutó cuando el cambio 120 fue el último cambio presentado en // project/main, y el cambio de integración presentado fue numerado 129, entonces main 120 y [email protected] deberían ser idénticos para la mayoría de los propósitos prácticos, pero recuerda que puedes editar el objetivo antes de enviarlo "promocionando" el objetivo para agregarlo usando "p4 edit" y luego modificando el contenido del archivo. – rjnilsson

+0

Después de la integración, es posible que necesite seleccionar cuidadosamente las listas de cambios para la portancia posterior desde la principal a la 1.0.Quiero la integración inicial CL desde/main (@ 123 en mi ejemplo) para ver exactamente qué se agregó a main después del punto de integración. (Es plausible que haya cambios en/main entre @ 123 y @ 130) –

+0

Acabo de recibirlo. Se está derivando de una lista de cambios anterior, no (necesariamente) la más reciente. – Chance

0

Si se usa la ficha historia en P4V le mostrará todas las listas de cambios presentados contra una rama, a fin de buscar en esto por

//project/1.0/... 

una vez que haya encontrado la lista de cambios más antiguo presentado, a continuación, en cualquiera de los archivos en esa lista de cambios ver el gráfico de revisión para ello, esto le mostrará la rama desde la cual se integró el archivo (y el resto de los archivos).

Veré si puedo volver con los comandos p4 para hacer lo mismo.

1

Dado que ninguno de las respuestas hasta el momento proporcionan el código para encontrar la fuente o la lista de cambios raíz de una sucursal, pensé que proporcionaría una línea para hacer precisamente eso. Este enfoque se basa en la sugerencia de @Cwan e imprimirá la lista de cambios "principal" a partir de la cual se creó la rama. El argumento FIRST_BRANCH_CL debe reemplazarse por la lista de cambios de creación de ramas (es decir, la primera lista de cambios enviada a la nueva rama). Como ejemplo concreto, reemplazando FIRST_BRANCH_CL con 130 de la pregunta original, este one-liner generaría 123.

p4 describe -s FIRST_BRANCH_CL | perl -lne 'if(/^\.\.\. (.+#[0-9]+) .+$/) {print quotemeta $1}' | xargs p4 filelog -m1 | perl -lne 'if(/^\.\.\. \.\.\. branch from (.+#[0-9]+)/) {print quotemeta $1}' | xargs p4 fstat | perl -lne 'if(/^\.\.\. headChange (\d+)/) {$MaxCL=$1 if($1 > $MaxCL)} END {print $MaxCL}' 
+0

¡Oye, parece que realmente funciona! Lo probé en una de nuestras sucursales, después de encontrar la misma información usando los pasos manuales descritos por Jon-Eric. Aunque lleva un tiempo correr. – fencekicker

+0

Bueno, pero creo que sería genial si explicaras el razonamiento detrás de tu trazador de líneas. – Kostas

0

"p4 integrado" funcionó para mí. Busque "copiar desde" en la descripción

Cuestiones relacionadas