Herramienta de control de versiones interoperable con otras herramientas de control de versiones

Estamos comenzando a reevaluar el software de control de versiones que se utilizará en nuestra empresa. Seleccionamos ClearCase hace unos 15 años y Subversion hace seis años, por lo que todavía tenemos algunos entornos con VOB de ClearCase que usan las GUI de ClearCase y entornos más recientes que usan repositorios de Subversion y algunas GUI como TortoiseSVN.

Con el tiempo, algunos proyectos se esforzaron por migrar de ClearCase a Subversion, pero todavía tenemos varios que continúan con ClearCase porque ha funcionado.

Git parece ser la opción popular entre muchas personas en estos días, pero me pregunto si podemos separar el problema en dos o tres subproblemas:

  • Seleccione una única herramienta de control de versiones de back-end (p. ej., Git) para alojar únicamente los repositorios.
  • Seleccione una o más herramientas de control de versiones si es necesario (por ejemplo, Git, git-svn, git-hg, git-cc, GitSwarm) que los equipos usarán para interactuar con los repositorios de back-end, o permita que los equipos seleccionen sus propias herramientas.
  • Seleccione interfaces gráficas o basadas en la web (por ejemplo, TortoiseGit, Stash, SourceTree) para interactuar con las herramientas de control de versiones seleccionadas, o permita que los equipos seleccionen sus propias herramientas.

Esto surgió después de que leímos lo siguiente sobre los repositorios duales para permitir que los diferentes equipos continúen con su flujo de trabajo actual hasta que estén listos para incorporarse a Git o lo que sea que decidamos migrar:

La herramienta de control de versiones de back-end debe:

  • Tienen poco o ningún costo de licencia.
  • Admite repositorios de Windows y Linux/UNIX, así como clientes.
  • Lo ideal es que sea interoperable con los productos heredados de ClearCase y Subversion para que los equipos puedan seguir usando esos productos hasta que decidan migrar.
  • Proporciona un gran rendimiento para que las operaciones no se ralenticen más de lo que lo hacen actualmente con los repositorios ClearCase VOB y Subversion.
  • Mantenga los datos del repositorio en un formato abierto en lugar de un contenedor propietario para que podamos migrar fácilmente los repositorios a otra herramienta en otros 5 a 15 años si es necesario.

Si esto se puede hacer y se recomienda, ¿existen repositorios de control de versiones que se ajusten a esto que podamos comenzar a buscar y comparar?

Dudo que cualquier sistema de control de versiones use un formato estándar. Hasta ahora he visto Subversion, Git y Mercurial y cada uno usa un formato propietario. De todos modos, puede usar la interoperabilidad para copiar todo el historial del proyecto en otro sistema más adelante.
Git y Bazaar tienen una excelente comunicación bidireccional con SVN y prácticamente todos los demás sistemas VCS.
@Alejandro probablemente te refieres a un formato personalizado . Ninguno de estos formatos es propietario. Además, herramientas como reposurgeon y otras han establecido el formato git-fast-import como un cuasi-estándar. Pero normalmente se requiere mucho esfuerzo para que sea bidireccional (excepto con Git y su puente Subversion).

Respuestas (1)

Git ofrece dicha funcionalidad con SVN. Básicamente ofrece un flujo bidireccional entre un repositorio Git y un repositorio SVN y varios comandos para administrar esa conexión.

Herramienta de control de versiones interoperable con otras herramientas de control de versiones
RespuestasAquíPolítica de privacidad1y, 0v