¿Es posible importar un repositorio MKS Integrity a git?

StackOverflow https://stackoverflow.com/questions/1314218

Pregunta

Sólo necesito el árbol fuente y su historia.No me importan los requisitos/problemas por ahora.Jugué un poco con la línea de comando para descubrir si podía obtener una lista de paquetes de cambios para el tronco y algunas de las rutas de desarrollo.Pensé que debería ser posible extraer una diferencia para cada paquete de cambios y usarla para reproducir todos los cambios desde la primera confirmación en git.Algo como esto:

  1. obtenga el primer compromiso y agréguelo a git
  2. obtener el siguiente CP
  3. obtener diferencia para CP
  4. aplicar diff al directorio de trabajo de git
  5. agregar y confirmar cambios en git
  6. repetir con (2.) hasta el último CP

También puede reemplazar el paquete de cambios con el punto de control (sería suficiente para mí).

Una forma más sencilla sería simplemente retirar un CP y agregarlo/comprometerlo con git.Pero entonces perderías la pista de las operaciones de agregar, eliminar, mover y cambiar el nombre.

¿Alguien sabe cómo obtener una diferencia unificada de "si diff"?Eso ya ayudaría mucho.

¿Algunas ideas?

Editar2:
Se agregó una respuesta que muestra cómo realicé la migración...

¿Fue útil?

Solución

El problema con Integridad MKS es su repositorio único en el que todo reside:

  • requisitos,
  • planes de prueba,
  • Casos de prueba,
  • características,
  • tareas de desarrollador,
  • solicitudes de implementación

Dado que esos datos pueden evolucionar independientemente unos de otros, a su propio ritmo, importarlos todos en un repositorio Git sería una mala idea:solo puedes clonar todo el contenido de un repositorio de Git (incluso si puede limitar la profundidad de ese clon).
Eso significa que obtendrá todos los documentos, aunque solo esté interesado en el código.
Una exportación de MKS Integrity implicaría definir primero muchos repositorios Git para que actúen como submódulos.

Sólo necesito el árbol fuente y su historia.

Como siempre, recomendaría sólo importar:

  • las etiquetas principales (para cualquier producto que tenga más de un año, o cualquier período con el que se sienta cómodo, no necesitará el examen completo porque es muy antiguo)
  • todos los sellos (mayores y menores) de los últimos años.

Y no importaría todo en uno repositorio Git a menos que esté seguro de que todas sus fuentes representan uno sistema desarrollado como un todo (y no varios "módulos" desarrollados de forma independiente)

Una forma más sencilla sería simplemente retirar un CP y agregarlo/comprometerlo con git.

Esa sería la manera de proceder.

Pero entonces perderías la pista de las operaciones de agregar, eliminar, mover y cambiar el nombre.

¡No!¡No podrias!Git lo hará inferir esas operaciones.
Esa es la ventaja de ser un archivo. Contenido VCS.

Otros consejos

No puedo publicar el programa real que escribí, porque yo no lo hice en mi tiempo libre. Sin embargo, puedo publicar cómo lo hice. Debe ser fácil que hacerlo de nuevo con cualquier lenguaje de programación. La herramienta que escribí emigró sólo una rama a la vez. Me gustaría decirle qué rama quiero (por ejemplo 1.21.1) y el de partida y revisión que termina en la rama (por ejemplo 4 y 78 volvería a migrar todas las revisiones a partir de 1.21.1.4 hasta 1.21.1.78). Tener todas las ramas en una cesión temporal I establece que el directorio .git utilizar para importar a.

  • comenzará a partir del bucle de revisión para poner fin a la revisión
    • CURRENTREV = BRANCH.loopcounter
    • crear el directorio de recompra
    • mover el .git dir en el directorio de recompra
    • mover el archivo en el directorio .gitignore repo
    • chdir en el directorio de recompra
    • crear mks caja de arena dentro de la dir repo a través de "si createsandbox -P MKS_PROJECT_PATH --yes --projectRevision = CURRENTREV
    • Obtener Descripción de revisión a través de "si viewprojecthistory --rfilter = rango: CURRENTREV-CURRENTREV"!, La salida de captura
    • usuario extracto, fecha, etiqueta (s), los comentarios de salida anterior
    • "git add."
    • tubería extrae información desde arriba en "git commit -qf -" (no se puede hacer -m si desea que varias líneas como el comentario de puesto de control)
    • caja de arena gota a través de "si dropsandbox --yes index.pj"
    • mover .git y .gitignore a un lugar seguro (para la próxima iteración)
    • eliminar todos los archivos que quedan en el directorio recinto
    • mover al directorio padre (..)
    • eliminar caja de arena / repo dir
  • crear dir git final
  • .git movimiento y .gitignore en dir git final
  • "git reset CABEZA --hard"

Hecho.

MKS utiliza algún tipo de codificación ASCII para su cuerda y Git generalmente utiliza UTF-8 así que tengan cuidado problema al importar los metadatos en GIT (nombres de usuario, comentarios, etiquetas, etc.).

Para más ramas hacer esto:

  • en la comprobación de directorio Git la revisión en la rama debe iniciar y crear una rama ( "git checkout -b NEWBRANCHNAME")
  • se mueven ahora .git y .gitignore al lugar de guardar y borrar todo el directorio
  • ahora hacer lo mismo que el anterior

Una cosa más: "si" es la herramienta de línea de comandos MKS. Así que o bien es necesario especificar su ruta completa o poner a su paso en la ruta de búsqueda.

Fwiw, si diff diff lamentablemente no es compatible actualmente unificado. Hay una solicitud de cambio de tener que hacerlo, pero aún no han sido demasiados clientes que solicitan esa característica.

RENUNCIA:. Yo trabajo para PTC (que adquirió MKS)

Esto funciona para los puestos de control ...

https://gist.github.com/2369049

Por desgracia, los puntos de control son aparentemente la única cosa que realmente tiene sentido del MKS -> GIT, como un puesto de control es realmente lo más parecido a la "instantánea", que GIT pide una confirmación.

MKS tiene tantos conceptos incompatibles (por el seguimiento de versiones de archivos, ramas que no son como las ramas de GIT, puestos de control, etc.) que todos pueden evolucionar de forma independiente el uno del otro, es muy difícil saber cómo migrar una historia sensata en GIT . Probablemente hay muchas maneras de hacerlo y ninguno de ellos más "correctas" que el anterior.

Dicho esto, me gustaría escuchar algunas buenas ideas. :)

Me gustaría ver una solución que captura el control de versiones por archivo de una manera sensata. En algunas de las discusiones que hemos lanzado en torno a la idea de tratar de alinear MKS versiones para cada fichero de tiempo comprometerse-o algo así. De esa manera podemos formular el concepto de "repo" evolucionando a través de una confirmación que contiene los cambios en varios archivos.

Yo uso esta herramienta para importar paquetes de cambio de MKS en Mercurial, importarlo a git debe ser bastante similar; o puede importar en Mercurial primera, y una herramienta de git utilizar para importar siguiente mercurial.

https://github.com/arsane/py-mks2hg.git

Se tratará de averiguar todos los paquetes de cambio que, bajo el proyecto especificado, y se comprometen a nuevo repositorio Mercurial en orden.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top