¿Es posible importar un repositorio de integridad MKS a git?

Question

Necesito solo el árbol fuente y su historial. No me importan las cuestiones de requisitos/problemas por ahora. Jugué un poco con la línea de comandos para averiguar si podía obtener una lista de paquetes de cambio para el tronco y algunas de las rutas de desarrollo. Pensé que debería ser posible extraer un diff para cada paquete de cambio y usarlo para reproducir todos los cambios desde la primera confirmación en git. Algo como esto:

1. conseguir primero comprometerse y añadirlo a GIT
2. obtener Después CP
3. obtener diff para CP
4. aplicar diff a git trabajo dir
5. complemento y confirmar los cambios a git
6. repita con (2) hasta el pasado CP

Usted también podría paquete de cambio repleace con c heckpoint (sería lo suficientemente bueno para mí).

Una forma más simple sería simplemente verificar un CP y agregar/comprometerse con git. Pero luego perderías la pista de agregar, eliminar, mover y cambiar el nombre de las operaciones.

¿Alguien sabe cómo obtener un diff unificado de "si diff"? Eso ya ayudaría mucho.

¿Alguna idea?

Edit2:
agregó una respuesta que muestra cómo en realidad lo hice la migración ...

Answer 1

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

• requisitos ,
• planes de prueba,
• casos de prueba,
• características,
• tareas de desarrollo,
• peticiones como despliegue

Desde esos datos pueden evolucionar de forma independiente uno de otro, a su propio ritmo, la importación de todos en un repositorio Git sería una mala idea: solo puede clonar 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 Integridad MKS implicaría definir primero muchos repositorios Git para actuar como submodules.

---

necesito sólo el árbol de origen y su historia.

Como de costumbre, yo recomendaría solamente la importación:

• las grandes discográficas (por algo más de un año, o lo que sea período de que se sienta cómodo que no necesitará el examinar en su totalidad, ya que es tan viejo)
• todas las etiquetas (mayores y menores) de los últimos años.

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

Una forma más simple sería simplemente verificar un CP y agregar/comprometerse con git.

Esa sería la forma de proceder.

Pero luego perdería la noción de agregar, quitar, mover y cambiar el nombre de las operaciones.

No! ¡No podrias! Git será infer those operations.
Esa es la ventaja de ser un archivo Content VCS.

Answer 2

No puedo publicar el programa real que escribí, porque no lo hice en mi propio tiempo. Sin embargo, puedo publicar cómo lo hice. Debería ser fácil rehacerlo con cualquier lenguaje de scripting. La herramienta que escribí migró solo una rama a la vez. Le diría qué rama quiero (por ejemplo, 1.21.1) y la revisión inicial y final en la rama (por ejemplo, 4 y 78 migrarán todas las revisiones desde 1.21.1.4 hasta 1.21.1.78). Para tener todas las ramas en un repositorio, proporcionaría el directorio .git para usar en la importación.

• comienzan bucle se inicie la revisión de poner fin a la revisión
  • CURRENTREV = BRANCH.loopcounter
  • crear el directorio de recompra
  • movimiento del .git dir en el directorio de recompra
  • mover el archivo .gitignore en el directorio repo
  • chdir en el directorio repo
  • create mks sandbox dentro del directorio repo v ia "si createdandbox -P MKS_PROJECT_PATH --yes --projectRevision = CURRENTREV
  • obtener descripción de revisión mediante" si viewprojecthistory --rfilter = rango: CURRENTREV-CURRENTREV ", captura de salida!
  • extraer usuario, fecha, etiqueta (s), comentarios de la salida anterior
  • "git add."
  • tubería información extraída desde arriba en "git commit -qf -" (no se puede hacer -m si desea que varias líneas como el comentario de puesto de control)
  • caída de recinto de seguridad a través de "si dropsandbox --yes index.pj"
  • mover .git y.gitignore a un lugar seguro (para la próxima iteración)
  • borrar todos los archivos restantes en el directorio recinto
  • traslado a El directorio padre (..)
  • borrado caja de arena/repo dir
• crear dir git definitiva
• movimiento .git y .gitignore en dir git última
• "git restablecer CABEZA --hard"

Do nordeste.

MKS usa algún tipo de codificación ASCII para su cadena y git generalmente usa UTF-8, así que ten cuidado con los problemas al importar 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")
• Ahora mueve .git y. gitignore al guardar su lugar y eliminar toda la dir
• ahora hacer lo mismo que el anterior

Una cosa más: "si" es la herramienta de línea de comandos MKS. Por lo tanto, debe especificar su ruta completa o poner su ruta en la ruta de búsqueda.

Answer 3

Esto funciona para los puestos de control ...

https://gist.github.com/2369049

Desafortunadamente, 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 llama una confirmación.

MKS tiene tantos conceptos incompatibles (por rastreo de versión de archivo, ramas que no son nada como ramas GIT, puntos de control, etc.) que pueden evolucionar independientemente el uno del otro. Es realmente difícil decir cómo migrar un historial sensible hacia GIT. Probablemente haya muchas maneras de hacerlo y ninguna de ellas sea más "correcta" que la siguiente.

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

Me encantaría ver una solución que capture el versionamiento por archivo de una manera sensata. En algunas discusiones, hemos lanzado la idea de tratar de alinear las versiones de MKS por archivo por tiempo de compromiso o algo así. De esta forma, podemos formular el concepto del "repo" que evoluciona a través de una confirmación que contiene cambios en múltiples archivos.

Answer 4

FWIW, por desgracia, actualmente no es compatible con diff unificado. Hay una solicitud de cambio para que lo haga, pero todavía no hay demasiados clientes pidiendo esa función.

DESCARGO DE RESPONSABILIDAD: Yo trabajo para PTC (que adquirió MKS).

Answer 5

Utilizo esta herramienta para importar paquetes de cambio de MKS a Mercurial, importarlo a git debería ser bastante similar; o puede importar a Mercurial primero, y usar la herramienta git para importar Mercurial a continuación.

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.