2008-09-05 11 views

Respuesta

83

recomiendo lo contrario para construir sistemas automáticos: primero debe obtener la última lista de cambios desde el servidor usando:

p4 changes -s submitted -m1 

luego sincronice con ese cambio y grabarlo en la información de revisión. La razon es la siguiente. Aunque Perforce recommends the following para determinar la lista de cambios a la que se sincroniza el espacio de trabajo:

p4 changes -m1 @clientname 

que tenga en cuenta unos aspectos críticos:

  • Esto sólo funciona si no se ha presentado nada del espacio de trabajo de que se trate.
  • También es posible que el espacio de trabajo del cliente no esté sincronizado con ninguna lista de cambios específica.

y hay una Gotcha adicional que no mencionan:

  • Si la más alta lista de cambios al que la sincronización se produjo archivos estrictamente borrados desde el espacio de trabajo, se informará de la próxima más alta lista de cambios (a menos que , también, archivos estrictamente eliminados).

Si primero debe sincronizar y registrar más tarde, Perforce recomienda ejecutar el siguiente comando para determinar si ha sido afectado por los errores anteriores; se debe indicar nada se sincroniza o se retira:

p4 sync -n @changelist_number 
+1

Gracias por la información adicional. –

+0

¿Por qué es que "Esto solo funciona si no ha enviado nada desde el área de trabajo en cuestión"? – gdw2

+0

Si envía un cambio, 'p4 cambia -s enviado -m1' devolverá su número de lista de cambio. Por ejemplo, supongamos que sincronizas con la lista de cambios 5, esperas un par de horas y luego envías la lista de cambios 10. El comando de cambios anterior devolverá 10. – Rinn

25

Sólo para responder a esto mismo de acuerdo con la sugerencia de utilizar Stackoverflow como un lugar para guardar fragmentos técnicas de Jeff ....

Desde el uso de línea de comandos:

p4 changes -m1 @<clientname> 

Y basta con sustituir el nombre de su cliente spec. Esto producirá salida del formulario:

Change 12345 on 2008/08/21 by [email protected] '....top line of description...' 

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

+0

Estoy recibiendo: Solicitud demasiado grande (más de 1500000); ver 'p4 help maxresults'. – user674669

+0

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

+1

¿Cuál es el nombre del cliente? Tengo el espacio de trabajo del puerto del servidor? Nombre de usuario ??? – marsh

5

Para una compilación seria (una que se está preparando para probar), 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 p4 counter change para obtener el número de cambio actual y grábelo. Pero aún necesita sincronizar todo utilizando ese número de cambio.

No creo que pueda lograr exactamente lo que desea porque, en general, todo un espacio de trabajo no está sincronizado con un número de lista de cambios en particular. 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 un nuevo sync para garantizar que un solo número de lista de cambios represente con precisión la versión del código.


En cuanto a los comentarios: Sí, mi respuesta está diseñada para uso por los administradores de configuración que preparan una acumulación de dar a control de calidad. Nuestros desarrolladores normalmente no se sincronizan como parte de una compilación; hacen una compilación antes de enviar — para 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 esa lista de cambios incluye 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.

+0

Erickson: buena sugerencia, pero creo que cubre un conjunto ligeramente diferente de circunstancias que 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, tal vez trabajando en otro proyecto, no haga un envío entre la sincronización y la llamada al contador p4. Por lo tanto, creo que su sugerencia es probablemente la mejor cuando el sistema de compilación está haciendo una atracción distinta a la compilación. Mi respuesta cubre casos en los que la sincronización se puede separar a tiempo de la compilación. Ambos son válidos dependiendo de las circunstancias, creo. –

12

es posible que trate de encontrar el número máximo cambio 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 sólo un poco mejor que

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

ya que esta última se parece funcionar en el servidor y puede fallar en grandes árboles de origen debido a los límites "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 por JTGoldstone, Red de Información Kodak/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 
2

El mejor que he encontrado hasta el momento es realizar la sincronización con la lista de cambios que desee construir y luego usar los cambios -m1 //...#have para obtener la lista de cambios local actual (revisión).

p4 sincronización @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.

+0

+1 para la secuencia de comandos awk – Watt

6

También puede utilizar el comando cstat:

ayuda p4 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' 
3

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

p4 counter change 

hace el trabajo, sólo 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, INCLUIDAS las listas de cambios pendientes (es decir, las que aún no se han enviado). Por lo tanto, cualquier usuario que inicie un nuevo trabajo en su cliente afectará este número. Esto será diferente de la última lista de cambios sincronizada con el espacio de trabajo local. – jasonmray

0

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 sabe que ha hecho a sí mismo sin ir a forzosamente para comprobar). Espero que esto ayude.

2

p4 changes -m1 @clientname que es la forma "recomendado" que lo haga por 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

+0

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

+1

El nombre de @marsh client (o también workspace) es el nombre de un objeto forzado que contiene el mapeo desde el servidor depo a su sistema de archivos local – gsf

+0

Subiendo esta respuesta, ya que responde la pregunta real en lugar de decir "no hagas eso "(Que es un punto válido, pero no responde la pregunta). –

2

Si está utilizando P4V puede hacerlo de forma gráfica:

  • En la pestaña Panel (Ver-> Panel de Control) seleccionar 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.
Cuestiones relacionadas