Use Git localmente para administrar el código de un repository de Surround SCM

Estoy buscando un puente de dos vías entre Git y Seapine Surround SCM similar a git-tfs o git-svn . Mientras escribía esto, se me ocurre que este es un pedido realmente difícil, así que espero comentarios / respuestas que realmente no es posible.

Encontré esta pregunta y no creo que realmente cubra lo que quiero. No quiero migrar lejos de Surround y no me importa si Git sabe algo sobre los historiales de files en Surround.

Mi empresa utiliza Surround SCM, que no satisface mis necesidades. He estado usando git en Cygwin para barajar el código, pero Surround arroja ajustes para cambiar las twigs de Git en un único repository de SCM. Generalmente, SCM me dice que he modificado algunos files después de cambiar las twigs de Git pero, cuando solicito un diff, me dice que los files son idénticos. Ha sido una solución útil, pero también es evidente que no es una solución muy fluida, ya que Git y Surround no hablan entre sí y no son realmente amigos rápidos.

No estoy 100% seguro de que los puentes a los que hice reference son análogos perfectos para lo que necesito. He incluido mis requisitos y casos de uso a continuación. Si hay alguna otra solución disponible que me permita realizar mis casos de uso, soy todo oídos.

Vamos a cambiar a TFS (eventualmente), así que espero una solución relativamente simple, si existe. Estoy dispuesto a invertir algo de time en investigar y configurar cosas, pero realmente no sé por dónde empezar. Incluso tengo algo de ancho de banda para escribir mi propia solución si alguien tiene consejos sobre cómo abordar eso.

Supongamos que no tengo permissions para hacer nada más que echar un vistazo a los repos existentes y comprometerme con ellos. No puedo ramificarme, crear nuevos repositorys, lo que sea.

Requisitos:

  • Funciona en Windows 7.
    • Idealmente, esto significa que es utilizable en Git bash o Cygwin, pero las soluciones GUI también son aceptables.
  • Configuración mínima / nula (es decir, una solución llave en mano o algo que solo necesita que lo apunte al directory correcto).
    • Asumir cierta competencia con Git, Cygwin y Surround y que los tres ya están instalados.
    • Tengo mucha libertad para instalar todo lo que necesito, considerando que es una computadora de la compañía.
  • Está preferiblemente bien documentado.

Casos de uso:

  • Use Git para administrar arreglos de errores paralelos e implementaciones de funciones.
    • Si realizo cambios en Git Master, me gustaría que se registren en el repository de SCM.
    • Si fusiono una twig con Git Master, me gustaría que SCM vea esos cambios y los prepare para el check-in.
    • Si creo una twig fuera de Master, no quiero que cree una twig correspondiente en SCM: al less no automáticamente. Podría ser bueno si fuera una opción, pero definitivamente no es obligatorio.

Dejaré los detalles en esto, por ahora. Puedo exponer sobre cualquiera de estas cosas, sin embargo, si no he explicado adecuadamente mis problemas y cómo me gustaría que sean corregidos.

Esta es mi solución hacky experimental. No es en absoluto un puente de dos vías, pero me permite manejar mis espacios de trabajo locales usando Git sin interrumpir Surround (hasta ahora).

Para evitar molestar a Surround:

  • Inicialice un repository Git en el directory de trabajo Surround.
    • Surround (al less, la forma en que lo configuró IT en mi empresa) ignora la carpeta .git.
    • Agregue .MySCMServerInfo a .gitignore. Asegúrese de que el patrón se vea en los subdirectorys: **/.MySCMServerInfo debería ser el truco.
  • Clona este nuevo repository de Git en una location física diferente.
    • Cualquier cambio en este repository clonado no puede ser detectado por Surround para que pueda hacer lo que quiera o necesite sin que Surround lo sepa.

Obtener cambios de los espacios de trabajo locales en el repository central de Surround es la parte hacky de todo esto y todavía no tengo los problemas.

  • Asegúrese de que su directory de trabajo Surround tenga lo último del repository.
  • Use Git para fusionar esos cambios en el repository clonado (es decir, el repository no rastreado por Surround).
  • Resuelva cualquier conflicto de combinación según sea necesario.
  • Confirme los cambios en su repository clonado.
  • Obtenga los cambios en el repository clonado al original.
  • Verifique los cambios en Surround.

Esto no es nada elegante, pero trae mucha energía Git a mi espacio de trabajo local mientras espero TFS.