Migración de git a Perforce

git-p4

Question

Tengo la tarea de migrar mi equipo y mi fuente de git a Perforce, y estoy buscando ideas sobre cómo mover el historial de git a p4.

Sería feliz mover solo la rama maestra. Sin embargo, incluso eso está resultando problemático.

Estoy usando la maravillosa herramienta git-p4. Creo un área de destino en mi espacio de trabajo p4, y uso git p4 clone //depot/StuffFromGit para comenzar a rastrearlo en git-p4. Yo injerto todos los cambios de mi repositorio git en el clon git-p4. Entonces puedo git p4 submit y listo, todos los cambios son empujados a p4.

Funciona muy bien cuando el historial de git se ve así, bonito y lineal:

A---B---C---D

El problema viene con varias personas trabajando en el proyecto. A pesar de que están trabajando en master, eso todavía crea ramas que se dividen y se fusionan. Aún así, git-p4 maneja valientemente esto:

A---B---C---E
/--D--/

git p4 atraviesa OK, confirmando ABCDE en orden (o ABDCE, primero el historial de cualquiera de las personas).

El problema surge cuando, por ejemplo, C y D cambian el mismo archivo, y E es una combinación real-honesta a la bondad. git p4 rebase falla aquí; rebobinará las confirmaciones, pero durante la reproducción aplicará C primero, luego intentará D y encontrará un conflicto. Entonces se detendrá, pidiéndome que me fusione. Bueno, E contiene la combinación, ¡pero me está pidiendo que fusione a mano! ''git p4 submit'' fallará de forma similar, solo que ahora p4 rechazará el cambio previo a la fusión.

Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging main.cpp CONFLICT (content): Merge conflict in main.cpp Failed to merge in the changes. Patch failed at 0005 Changing main

Así que ahora estoy atascado. ¿Hay alguna forma de sanear el historial de git o hacer que git-p4 lo entienda? Es frustrante ya que las fusiones están ahí.

Pensamientos que he tenido:

• Use git filter-branch para eliminar toda mención de archivos en conflicto. Me gustaría hacer llegar los comentarios del historial, aunque faltan muchos cambios de archivos. Con alrededor de 3000 confirmaciones en el historial, terminaría eliminando todo el historial de archivos clave (ocupado). Al final de la importación de los archivos filtrados, agregaría los archivos faltantes haciendo una confirmación final de HEAD.
• Vuelque la historia, haga un solo p4 de confirmación de la CABEZA (simple pero triste).
• No pasar a la p4: he trabajado esa idea durante el mayor tiempo posible.

Ninguno de los cuales son realmente grandes. ¿Alguna idea sobre cómo git ''gt p4 rebase'' o ''git p4 submit'' para trabajar?

Answer 1

¿Has revisado la herramienta "sastre"? Es una compilación para sincronizar diferentes VCS: es. Se supone que tiene soporte Perforce.

Como nota al margen, mi primera reacción sería cuestionar seriamente la decisión, pero supongo que ya lo has hecho.

Answer 2

Creo que debería intentar con Tortoise SVN y luego Hg considerando la actualización de una sola sucursal o puede decir migración. Asegúrese de tener todo el volcado clonado para estar en el lado seguro. Buena suerte !

Answer 3

La opción de "simplemente tirar la historia antigua" no es tan mala como parece: puedes mantener tu git repo a su lado para siempre, en caso de que alguien necesite revisar las cosas viejas. Desafortunadamente, simplemente no hay manera de representar la compleja vista de la historia de git en sistemas lineales de estilo antiguo como svn y p4.

La razón principal para mirar hacia atrás en la historia antigua es para cosas como ''git annotate'' (supongo que p4 tiene una herramienta similar). Si eso es todo lo que quieres, entonces tal vez lo que realmente quieres hacer es aplastar todos tus compromisos de fusión solo con uno de sus padres (para que parezcan un solo compromiso en lugar de una combinación). Es más parecido a lo que svn y p4 habrían registrado en su propio modelo histórico, donde las fusiones simplemente se ven como una única confirmación en el flujo lineal. Probablemente puedes hacer esto con git-filter-branch o similar. Por supuesto, esto perdería toda la historia que sucedió en las sucursales secundarias ... pero los usuarios de p4 están acostumbrados a no tener esa información.