2009-12-11 19 views
13

Digamos que he creado una rama en forzado de nuestra base de código. Aquí está la especificación rama:Integración de archivos movidos a la fuerza

//depot/code/main/... //depot/code/branch/... 

Luego, en la rama, por ejemplo muevo el archivo bifurcado a.txt -> b.txt usando

p4 integrate //depot/code/branch/a.txt //depot/code/branch/b.txt 
p4 delete //depot/code/branch/a.txt 

Ahora, digamos que algunos cambios se realizan en a.txt en main que me gustaría tener integrado en b.txt en la rama

Cuando intento integrar utilizando la especificación de rama original, no refleja los cambios realizados en a.txt en main en b .txt - ¿hay alguna forma de que los cambios realizados en la presentación principal aparezcan en el archivo renombrado?

La especificación de sucursal es bastante grande (cientos de cambios) y se cambiaron los nombres de algunos archivos en la sucursal, por lo que me gustaría tener una forma automática de hacerlo. Avíseme si puedo aclarar algo aquí - sería útil tener una pizarra;)

¡Gracias! Sam

Respuesta

3

Perforce 2009.1 tiene nombres propios adecuados, lo que podría ayudar con esto, probablemente, y en cualquier caso solo para futuros cambios de nombre. Ver Perforce 2009.1 release notes, en particular:

#177023 * ** 
    The new 'p4 move' command allows for better support for 
    renaming files. A file must be already opened for 'edit' 
    or 'add' in order to be moved. Moved files can be synced, 
    resolved and diffed against the repository just like files 
    opened for 'edit'. See 'p4 help move' for more info. 

Puedes añadir el cambio de nombre en la especificación rama. Entonces, al menos, las integraciones serán automáticas, incluso si la especificación de rama será aún más larga y más complicada.

+3

Por lo que yo entiendo, los * únicos * beneficios del movimiento p4 son que puedes mover y editar un archivo en una sola lista de cambios atómicos, y hasta que puedas comprobar que la lista de cambios más sincroniza propagará los cambios de la fuente al objetivo. * Después * de que lo haya registrado, se comporta de la misma manera que una bifurcación, una acción de edición y una acción de eliminación, excepto que son inseparables. No ayuda con la integración de movimientos de una rama a otra. No es lo que se llama "renombrados de primera clase" en otros sistemas de control de fuente. – Weeble

+0

Creo que podría estar en lo cierto, se ve de esa manera, aunque, con los metadatos registrados en la base de datos, Perforce podría agregar un manejo adecuado en el futuro. Anteriormente era imposible diferenciar una rama de un nombre nuevo. –

+0

No, incluso con un movimiento 'p4' apropiado, la integración no funcionará como debería. –

1

No lo creo. Como no existe un número directo p4 rename, debe integrar y eliminar: una vez que lo haya hecho, las integraciones de otra rama ya no irán al archivo correcto. Al menos esa ha sido mi experiencia.

+0

Gracias - Actualizado para mostrar qué comandos se emitieron realmente - en realidad usé p4v para hacerlo. – SamBeran

+0

Creo que 2009.1 agrega los nombres correctos, lo que no ayuda con el historial –

3

La única forma que conozco de que Perforce maneje esto para usted es usar la especificación de rama para mapear el archivo anterior en el original al nuevo archivo en la rama. Tal vez eso ha cambiado con el nuevo comando de movimiento en las versiones recientes de Perforce, pero no es lo que he experimentado.

+0

Pero, ¿funciona esto cuando renombra recursivamente y todo el directorio? ¿Debo hacer una especificación de rama para todos los archivos uno por uno? Aparentemente, hacer una especificación de rama en el directorio no funciona. – Calmarius

+0

@ Calmarius, si cambia el nombre del directorio y los archivos en el directorio, necesita ambos. Si solo cambiara el directorio, podría hacerlo solo con el directorio. Si los nombres cambian de manera consistente, es posible que pueda usar comodines para simplificar la especificación. –

2

Puede crear secuencias de comandos para la creación de una especificación de ramificación para manejar archivos movidos utilizando la salida de p4 fstat.

Usar la siguiente como punto de partida:

ROOT_PATH="//depot/books/..." 
FIRST_CHANGE=91212 

p4 fstat -Os -T headChange -F "headAction=move/* headChange>$FIRST_CHANGE" $ROOT_PATH|grep headChange | sort -u|while read DUMMY1 DUMMY2 change; do p4 describe $change; done|grep "moved from"|sed 's/\.\.\./\t/g; s/\#[0-9]*//g; s/ moved from//g;' 

Esto encontrará todos los archivos en la // depot/libros/... que se han movido en el cambio 91212 o posterior

Para nosotros, la salida de este se parece a

//depot/books/bar.txt //depot/books/foo.txt

lo uso para la elaboración de una especificación de rama.

10

Puede agregar el modificador '-3' para usar un nuevo motor de integración, que detectará los archivos de destino que se movieron previamente con 'p4 mover', y automáticamente 'reorientar' para seguir las operaciones de movimiento .

p4 integrate -3 //depot/code/main/... //depot/code/branch/... 

integrará los cambios en //depot/code/main/a.txt a //depot/code/branch/b.txt.

Esta es la función 'undoc' en la versión actual 2010.2, pero será el comportamiento predeterminado en la próxima 2011.1.

+0

+1 ¡Bien visto! Eso hace el truco. –

Cuestiones relacionadas