¿Cómo se puede lograr el interfuncionamiento de la gestión del control de fuente?

Question

Si bien antes se hicieron preguntas relacionadas, me gustaría ver una idea sobre cómo se puede hacer la interoperabilidad entre dos sistemas de administración de control de fuente (SCM). Por ejemplo, podríamos considerar cualquier SCM (Mercurial, Git, SVN, CVS, Perforce, ClearCase ...).

Principalmente me interesa si ClearCase se puede usar junto con SVN o Git / Mercurial.

¿Cómo puedo tener un árbol de origen mantenido por ClearCase remoto mantenido por otro SCM también (además de ClearCase)?

Mientras que otros pueden usar ClearCase, nos gustaría usar el 'otro' SCM y confirmar los cambios en ese repositorio. Los cambios en el repositorio de ClearCase deberían seguir de forma breve o periódica (y también la actualización desde el repositorio de ClearCase debe realizarse periódicamente para garantizar que tengamos las últimas fuentes)

Cualquier (otros / relacionados) ejemplos / experiencias son bienvenidos. Gracias!

PD: Esto no se trata de eliminar ClearCase (lo haría con mucho gusto), se trata de trabajar con dos controles de origen al mismo tiempo en el mismo árbol de origen.

Answer 1

Realmente recomiendo no mezclarlos. Administrar un SCM es una tarea lo suficientemente compleja como para que no desee que el usuario normal tenga que lidiar con varios de ellos.

Si todavía quieres mezclar, los SCM distribuidos como Mercurial o git tienen algo bueno, que es la capacidad de usarlos sin imponerlos a nadie. Cada desarrollador / equipo puede administrar su copia local / sucursal local en git o mercurial sin que nadie lo sepa.

git + subversion o mercurial + subversion tienen la ventaja de que volver al repositorio principal es parte de la herramienta, pero se puede vivir sin ella.

En su caso, parece que ClearCase se le impone pero desea utilizar una alternativa. Puede decidir usar git en su equipo y empujar regularmente la rama principal a ClearCase.

Answer 2

una cosa que me viene a la mente es git-svn : " It proporciona un flujo bidireccional de cambios entre un Subversion y un repositorio git. "

Answer 3

Siempre que pueda hacer que otros SCM se ignoren entre sí (a través de un tipo de archivo .cvsignore / .hgignore ) o hacer que cooperen (como git svn ), no veo por qué no deberías poder hacer eso. Ya lo hago a través de svn / Hg / git y CVS.

Answer 4

De una manera muy genérica, siempre puede confirmar el HEAD actual del '' extranjero '' (ClearCase en su caso) repo en una rama git, vuelva a armar su propia rama encima de eso y confirme el resultado en el "extranjero" repo. Espuma, enjuague, repita.

Answer 5

El problema con la interoperabilidad entre la administración de control de dos fuentes (SCM) es si un SCM tiene un modelo más rico que otro (por ejemplo, Subversion anterior a 1.5.0 no almacenó a todos los padres de una fusión si no usó svnmerge o SVK, mientras que la SCM más moderna recuerda fusiones; Mercurial no admite fusiones de pulpo, es decir, se fusiona con más de dos padres).

Hay al menos algunos tipos diferentes de soluciones que conozco:

• genérico solución de interoperabilidad SCM, como el estándar de intercambio importación rápida creado en Git pero compatible con Bazaar y creo que también con Mercurial, o herramientas como Sastre (pero Tailor tiene su limitación)
Herramientas
• específicas , que usan API SCM o scriptability SCM, como git-svn entre Git y Subversion (usa Subversion Perl API) o git-p4 entre Git y Perforce
• a mano , es decir, usando el área de trabajo común (directorio de trabajo) obteniendo cambios (desprotegiendo) de un SCM y agregando cambios (comit) a otro SCM. Esto requeriría configurar los archivos de ignorar apropiados, por lo que un SCM ignora otros archivos y directorios auxiliares específicos de SCM.
• emulación de servidor en el caso de interacción entre SCM centralizado (como CVS) y otro SCM (como Git) emulando el servidor para SCM centralizado, pero teniendo repositorio en otro SCM, como lo hace git-svnserver
• backend de datos donde un SCM (como Bazaar o Darcs) almacena los cambios (datos) en el repositorio en otro formato SCM. No sé un ejemplo para tal solución.

Answer 6

Estoy de acuerdo con BlueBird75 : mezclar dos referencias diferentes no es una buena idea, por la misma razón no es un Es una buena idea tener varias bases de datos con el mismo tipo de información. La sincronización y la duplicación no son fáciles de administrar en esos casos.

Hacemos " publicamos " algunos datos administrados en nuestros repositorios ClearCase (VOB) a otros VCS (Subversion, Perforce, ...) o repositorios (como Maven), para otros equipos que no usan ClearCase. Sin embargo, los datos exportados son solo entregas .

A " unidad de entrega " es un pequeño conjunto de archivos empaquetados ('pequeño' como en la menor cantidad de archivos posible): jar, war y ear son todos un ejemplo de dichos archivos empaquetados, pero también incluimos fuentes (comprimidas en un archivo zip), javadoc (también comprimido), script para ejecutar esta entrega, y así sucesivamente.

De esa forma, solo se exportan unos pocos archivos a los clientes, y solo cuando se genera una entrega y representa una versión estable significativa.