Determinando la última lista de cambios sincronizada en Perforce


117

Una pregunta que surge ocasionalmente es cuál es la mejor manera de determinar la lista de cambios con la que se sincronizó por última vez en Perforce. Esto a menudo es necesario para cosas como inyectar el número de la lista de cambios en la información de revisión mediante el sistema de compilación automático.


p4 changes | head -1parece más fácil que la mayoría de estas soluciones.
Sridhar Sarnobat

Respuestas:


91

Recomiendo lo contrario para los sistemas de compilación automática: primero debe obtener la última lista de cambios del servidor usando:

p4 changes -s submitted -m1

luego sincronice con ese cambio y regístrelo en la información de revisión. La razon es la siguiente. Aunque Perforce recomienda lo siguiente para determinar la lista de cambios con la que se sincroniza el espacio de trabajo:

p4 changes -m1 @clientname

notan algunas trampas:

  • Esto solo funciona si no ha enviado nada desde el espacio de trabajo en cuestión.
  • También es posible que el espacio de trabajo de un cliente no esté sincronizado con ninguna lista de cambios específica.

y hay un problema adicional que no mencionan:

  • Si la lista de cambios más alta a la que se produjo la sincronización eliminó estrictamente los archivos del espacio de trabajo, se informará la siguiente lista de cambios más alta (a menos que también se trate de archivos estrictamente eliminados).

Si debe sincronizar primero y grabar más tarde, Perforce recomienda ejecutar el siguiente comando para determinar si ha sido mordido por las trampas anteriores; debe indicar que no se sincronizó ni eliminó nada:

p4 sync -n @changelist_number

¿Por qué "Esto solo funciona si no ha enviado nada desde el espacio de trabajo en cuestión"?
gdw2

Si envía un cambio, 'p4 cambios -s enviados -m1' devolverá su número de lista de cambios. Por ejemplo, digamos que sincroniza con la lista de cambios 5, espera un par de horas y luego envía la lista de cambios 10. El comando de cambios anterior devolverá 10.
Rinn

El enlace está muerto, ¿era este artículo? answers.perforce.com/articles/KB/3458/
user31389

Tenga en cuenta que puede usar en #havelugar de @clientname, lo que le evita tener que buscar el nombre del espacio de trabajo de su cliente.
yoyo

29

Solo para responder esto yo mismo de acuerdo con la sugerencia de Jeff de usar Stackoverflow como un lugar para guardar fragmentos técnicos ...

Desde la línea de comando, use:

p4 changes -m1 @<clientname>

Y simplemente reemplácelo con el nombre de la especificación de su cliente. Esto producirá una salida del formulario:

Change 12345 on 2008/08/21 by joebloggs@mainline-client '....top line of description...'

Que se analiza fácilmente para extraer el número de lista de cambios.


Recibo: Solicitud demasiado grande (más de 1500000); consulte 'p4 help maxresults'.
user674669

@ user674669: use la opción -m1 que devuelve solo la última (1) lista de cambios
panako

Esto proporciona la información de la última lista de cambios enviada , no la última lista de cambios sincronizada , que es lo que el operador quería saber.
Andreas

@marsh Creo que en realidad es el nombre del espacio de trabajo del cliente, que por defecto es el nombre de la computadora si no se establece. Vea aquí: P4CLIENT .
Andreas Haferburg

15

Puede intentar encontrar el número máximo de cambios en la salida del comando "archivos p4". Sin embargo, el directorio de trabajo no debe contener confirmaciones posteriores a la sincronización. Esto es un poco mejor que

p4 changes -m1 "./...#have"

ya que este último parece ejecutarse en el servidor y puede fallar en grandes árboles de origen debido a los límites de "MaxResults".

$ p4 changes -m1 "./...#have"
Request too large (over 850000); see 'p4 help maxresults'.

$ p4 -G files "./...#have" | python c:/cygwin/usr/local/bin/p4lastchange.py
Files: 266948
2427657

donde p4lastchange.py se basa en el código de la presentación Using P4G.py From the Command Line de JTGoldstone, Kodak Information Network / Ofoto, 15 de abril de 2005.

#! /usr/bin/env python
import sys, os, marshal

if os.name == "nt":
    # Disable newline translation in Windows.  Other operating systems do not
    # translate file contents.
    import msvcrt
    msvcrt.setmode( sys.stdin.fileno(), os.O_BINARY )

lastcl = 0
num = 0
try:
    while 1:
        dict = marshal.load(sys.stdin)
        num = num + 1
        for key in dict.keys():
            # print "%s: %s" % (key,dict[key])
            if key == "change":
                cl = int(dict[key])
                if cl > lastcl:
                    lastcl = cl
except EOFError:
    pass
print "Files: %s" % num
print lastcl

10

Si está utilizando P4V, puede hacerlo gráficamente:

  • En la pestaña Panel de control (Ver-> Panel de control) elija una carpeta y verá una lista de listas de cambios con las que la carpeta aún no se ha actualizado. Anote el número más bajo (en la fila más alta).
  • Asegúrese de que en el árbol del área de trabajo haya seleccionado la misma carpeta que anteriormente en el tablero. Luego vaya a la pestaña Historial (Ver-> Historial) y desplácese hacia abajo hasta el número anotado anteriormente. El número justo debajo de ese número es el número de su lista de cambios actual.

9

p4 changes -m1 @clientname que es la forma "recomendada" de hacerlo para mi cliente, tarda unos 10 minutos

esto es lo que uso:

p4 cstat ...#have | grep change | awk '$3 > x { x = $3 };END { print x }'

para el mismo cliente toma 2,1 segundos


¿Cuál es el nombre del cliente? ¿Cómo puedo encontrar esta información?
pantano

1
El nombre del cliente @marsh (o también del espacio de trabajo) es el nombre de un objeto forzoso que contiene la asignación del servidor depo a su sistema de archivos local
gsf

2
Votar a favor esta respuesta, ya que responde la pregunta real en lugar de decir "no hagas eso" (que es un punto válido, pero no responde a la pregunta).
sam hocevar

1
p4 changes -m1 @clientnamecorre sin fin ... p4 cstat ...#have | grep change | awk '$3 > x { x = $3 };END { print x }'realmente funciona! ¡Gracias!
simomo

@gsf - gracias, lo probé en mi caja de Linux y funcionó.

8

También puede usar el comando cstat:

p4 ayuda cstat

cstat -- Dump change/sync status for current client

p4 cstat [files...]

Lists changes that are needed, had or partially synced in the current
client. The output is returned in tagged format, similar to the fstat
command.

The fields that cstat displays are:

    change   changelist number
    status   'have', 'need' or 'partial'

5

Para una compilación seria (una que se está preparando para la prueba), especifique explícitamente la etiqueta deseada o el número de lista de cambios, sincronice con la etiqueta, e incorpórela en los artefactos de compilación.

Si no se proporciona una lista de cambios (o etiqueta), utilice p4 counter changepara obtener el número de cambio actual y regístrelo. Pero aún necesitas sincronizar todo con ese número de cambio.

No creo que pueda lograr exactamente lo que desea, porque en general, un espacio de trabajo completo no está sincronizado con un número de lista de cambios en particular. Uno puede sincronizar explícitamente algunos archivos con revisiones anteriores, y luego un solo número de lista de cambios no tiene sentido. Es por eso que syncse requiere una actualización para garantizar que un único número de lista de cambios represente con precisión la versión del código.


Con respecto a los comentarios: Sí, mi respuesta está destinada a los administradores de configuración que preparan una compilación para entregarla a QA. Nuestros desarrolladores normalmente no se sincronizan como parte de una compilación; hacen una compilación antes de enviarla, para que puedan asegurarse de que sus cambios no rompan la compilación o las pruebas. En ese contexto, no nos molestamos en incrustar una etiqueta de repositorio.

Con su enfoque, está asumiendo que todo su espacio de trabajo se sincronizó para encabezar en el momento de su última presentación de lista de cambios, y esa lista de cambios incluía todos sus archivos abiertos. Es demasiado fácil equivocarse en esas suposiciones, difícil de detectar y terriblemente caro en términos de tiempo perdido. Por otro lado, resolver el problema es fácil, sin inconvenientes. Y debido a que se puede especificar explícitamente un número de lista de cambios, no importa qué revisión necesite o qué tan rápido cambie el código base.


Erickson: buena sugerencia, pero creo que cubre un conjunto de circunstancias ligeramente diferente al de la respuesta que proporcioné. Ciertamente, el contador funcionará si es probable que solo tenga la revisión principal y el servidor no esté lo suficientemente ocupado como para que alguien, quizás trabajando en otro proyecto, no realice un envío entre la sincronización y la llamada al contador p4. Así que creo que su sugerencia es probablemente mejor cuando el sistema de compilación está haciendo un tirón distinto y luego compila. Mi respuesta cubre casos en los que la sincronización puede separarse en el tiempo de la compilación. Ambos son válidos dependiendo de las circunstancias, creo.
Greg Whitfield

3

Para todo el depósito (no solo su espacio de trabajo / cliente)

p4 counter change

hace el trabajo, simplemente diciendo la última lista de cambios.


2
Tenga en cuenta que esto informa el número de la última lista de cambios de depósito, INCLUYENDO las listas de cambios pendientes (es decir, aún no enviadas). Por lo tanto, cualquier usuario que inicie un trabajo nuevo en su cliente afectará este número. Será diferente de la última lista de cambios sincronizada con el espacio de trabajo local.
Jasonmray

2

Lo mejor que he encontrado hasta ahora es sincronizar con cualquier lista de cambios que desee crear y luego usar los cambios -m1 //...#have para obtener la lista de cambios local actual (revisión).

p4 sync @CHANGELIST_NUM p4 cambia -m1 //...#have | awk '{imprimir $ 2}'

Le da el número de lista de cambios que puede usar donde quiera. Actualmente estoy buscando una forma más sencilla que p4 changes -m1 //...#have.


0

No estoy seguro de si obtuvo la respuesta que necesitaba, pero tuve un problema similar. El objetivo era escribir en nuestro logger la versión específica del proyecto. El problema fue que mientras creamos nuestro propio archivo MAKE, el sistema de compilación general está controlado por nuestra administración de configuración. Esto significa que todas las soluciones que dicen "sincronizar con algo y luego hacer algo" no funcionan realmente y no quería cambiar manualmente la versión cada vez que confirmamos (una fuente segura de errores). La solución (que en realidad se insinúa en algunas de las respuestas anteriores) es la siguiente: en nuestro archivo MAKE, hago p4 changes -m1 "./...#have" El resultado para esto es Change change_number on date by user @ client ' msg ' Simplemente creo el mensaje en una cadena que imprime el registrador (el número de cambio es el elemento importante, pero el otro también es útil para decidir rápidamente si una determinada versión contiene cambios que sabe que hizo sin tener que comprobarlo). Espero que esto ayude.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.