versionamiento - Determinación de la última lista de cambios sincronizada en Perforce

qué es la gestión de versiones

Question

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

Answer 1

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

Sincronización p4 @CHANGELIST_NUM p4 cambia -m1 //...#have | awk ''{print $ 2}''

Te da el número de lista de cambios que puedes usar donde quieras. Actualmente estoy buscando una manera más simple que p4 cambia -m1 //...#have.

Answer 2

No estoy seguro de si obtuvo la respuesta que necesitaba, pero tuve un problema similar. El objetivo era escribir en nuestro registrador la versión específica del proyecto. El problema fue que, mientras hacemos nuestro propio archivo MAKE, el sistema de compilación general está controlado por nuestra gestión de configuración. Esto significa que todas las soluciones que dicen "sincronizar con algo y luego hacer algo" realmente no funcionan 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 cambios -m1 "./...#have" El resultado 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 usted sabe que realizó sin tener que verificar forzosamente) ) Espero que esto ayude.

Answer 3

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

p4 counter change

hace el trabajo, solo cuenta la última lista de cambios.

Answer 4

Para una compilación seria (una que se está preparando para las pruebas), especifique explícitamente la etiqueta deseada o el número de lista de cambios, sincronícela con la etiqueta y empújela en los artefactos de compilación.

Si no se proporciona una lista de cambios (o etiqueta), use el p4 counter change para obtener el número de cambio actual y anótelo. Pero aún necesita sincronizar todo usando ese número de cambio.

No creo que pueda lograr exactamente lo que desea, ya que, en general, todo el espacio de trabajo no está sincronizado con un número determinado de lista de cambios. Uno puede sincronizar explícitamente algunos archivos a revisiones antiguas, y luego un solo número de lista de cambios no tiene sentido. Es por eso que se requiere una nueva sync para garantizar que un solo número de lista de cambios represente con exactitud la versión del código.

Respecto a los comentarios: Sí, mi respuesta está destinada a ser utilizada por los gerentes de configuración que preparan una compilación para ceder a la garantía de calidad. Nuestros desarrolladores normalmente no se sincronizan como parte de una compilación; hacen una compilación antes de enviarla, de modo que puedan asegurarse de que sus cambios no rompan la compilación o las pruebas. En ese contexto, no nos molestamos en insertar una etiqueta de repositorio.

Con su enfoque, está asumiendo que todo su espacio de trabajo se sincronizó a la cabeza en el momento de su última presentación de la lista de cambios, y que la lista de cambios incluía todos sus archivos abiertos. Es muy fácil confundirse con esas suposiciones, difíciles de detectar y terriblemente caras en términos de tiempo perdido. Por otro lado, resolver el problema es fácil, sin inconvenientes. Y debido a que un número de lista de cambios puede especificarse explícitamente, no importa qué revisión necesite ni cuán rápido esté cambiando la base de código.

Answer 5

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

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

ya que este último parece ejecutarse en el servidor y puede fallar en grandes árboles fuente 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 del uso de P4G.py de la presentación de línea de comando 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

Answer 6

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

p4 changes -s submitted -m1

luego sincronízate con ese cambio y grábalo en la información de revisión. La razon es la siguiente. Aunque Perforce recomienda lo siguiente para determinar la lista de cambios a la que se sincroniza el espacio de trabajo:

p4 changes -m1 @clientname

ellos notan algunos inconvenientes:

• 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 del 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 elimine estrictamente los archivos).

Si primero debe sincronizar y grabar más tarde, Perforce recomienda ejecutar el siguiente comando para determinar si ha recibido un puntaje por los errores anteriores; debería indicar que no se ha sincronizado o eliminado nada:

p4 sync -n @changelist_number

Answer 7

Si está usando P4V, puede hacer esto gráficamente:

• En la pestaña Tablero (Ver-> Tablero) elija una carpeta y verá una lista de listas de cambios con las que aún no se ha actualizado la carpeta. Tenga en cuenta 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 tu lista de cambios actual.

Answer 8

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

Desde la línea de comando use:

p4 changes -m1 @<clientname>

Y simplemente reemplace con el nombre de las especificaciones de su cliente. Esto producirá salida de la forma:

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.

Answer 9

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''

Answer 10

p4 changes -m1 @clientname que es la forma "recomendada" de hacerlo para mi cliente toma aproximadamente 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