¿Sistemas de control de versiones simultáneas múltiples?

Question

Soy relativamente nuevo en el control de versiones, y hasta ahora solo tengo experiencia trabajando con Subversion usando TortoiseSVN/VisualSVN. He estado leyendo acerca de otros tipos de VCS (git, mercurial, etc.), y estoy considerando probarlos; sin embargo, muchos de los argumentos a favor o en contra de un VCS en particular parecen ser en gran parte una preferencia subjetiva, así que ' Probablemente termine dando una mirada a cada uno.

Al pensar en hacerlo, me preguntaba si era incluso teóricamente posible utilizar múltiples VCS en una única base de código. ¿Qué combinaciones (si las hay) de VCS podría ser esta una posibilidad? Y si es posible, ¿cuánto de una pesadilla logística sería tratar de hacer malabarismos con las respectivas listas de exclusión?

Un posible argumento para hacerlo podría ser la redundancia de la copia de seguridad. Varios proveedores de VCS (Beanstalk, Github, Bitbucket) ofrecen un repositorio gratuito, por lo que puede tener el mismo repo respaldado de forma gratuita en varios lugares diferentes.

Answer 1

Ciertamente, esto es posible, incluso algo común en algunos casos. Por ejemplo, git y svn son un par natural para esto. El caso de uso estándar es una organización que debe tener un repositorio de Subversion central heredado por varias razones, pero en la que los desarrolladores desean usar Git para el aumento de productividad que proporciona.

Ingrese git-svn. Ahora los desarrolladores empujan y extraen de sus repositorios Git locales al repositorio central de Subversion, pero aún así obtienen todo el poder de Git. Este proceso es total y totalmente transparente para el repositorio de Subversion, que simplemente ve los cambios que se le aplican.

Answer 2

Generalmente es difícil (pero no imposible) manejar múltiples VCS en una base de código. Sin embargo, es posible que tenga problemas con la eliminación de archivos ... A veces, un VC no se dará cuenta de que se ha eliminado un archivo.

Sin embargo, no lo recomiendo. La mayoría de los VC usan archivos dentro de la base del código para rastrear los cambios. Tener varios sistemas de VC en su lugar contaminará su sistema de archivos con muchos archivos que potencialmente causarán problemas en los otros VC.

Answer 3

Sé que no es bastante utilizar múltiples VCS, pero es posible que algunos VCS tengan diferentes interfaces. Git, por ejemplo, puede tener una interfaz de SVN para que los clientes de SVN puedan usar el repositorio de Git (y no tendrán más conocimiento de que es Git). Creo que también hay otros frontales disponibles para él.

Answer 4

Mercurial (con hgsubversión), git (con git-svn) y bzr (bzr-svn) todos tienen una opción para sincronizar con un repositorio svn en sentido ascendente.

Así que ya es posible (suponiendo que las extensiones funcionen lo suficientemente bien) interactuar con un repositorio svn con diferentes SCM.

Answer 5

Es ciertamente posible hacer esto. Uso git-svn para actualizar mi repositorio de git local y comprometerme con el repositorio de svn corporativo. Con cualquier herramienta VCS que decida usar, el problema que probablemente encontrará es durante la actualización de su repositorio local con los cambios del repositorio remoto.

Si usa bazar para su repositorio local, the most problematic thing es cuando su repositorio de bazar local está divergente y desea comprometerse con su repositorio remoto. Algunas veces tiene que hacer "sobrescribir sobrescribir" para resolverlo.

No experimento este "problema de repositorio divergente" cuando uso git-svn para actualizar mi repositorio de git local con los cambios desde el repositorio de svn remoto.Pero a veces cuando hago "git svn rebase" tendrá conflictos y si no haces el procedimiento para resolverlo correctamente, puedes pasar mucho tiempo. Porque me he encontrado con esto una y otra vez, tengo documented it y no me parece tan importante ahora.

Answer 6

Mi primera respuesta cuando leí su pregunta fue: "Claro, técnicamente es posible, pero una muy mala idea".

Retrocederé un poco después de ver los otros comentarios. De acuerdo, cada usuario podría tener un repositorio local separado del repositorio central y usarlo para mantener básicamente los puntos de control mientras trabaja. En ese caso, podrían ser VCS completamente separados y no importaría.

Pero si estás pensando en dos VCS diferentes manteniendo simultáneamente tu repositorio central, eso es técnicamente posible, pero una muy mala idea. El objetivo de un VCS es que mantenga un historial de todos los cambios realizados en los archivos, que pueda ver qué cambios se realizaron cuando y, si los usuarios incluyen comentarios decentes a mitad de camino, por qué. Si un cliente que tiene la versión del 19 de junio de 2007 tiene un problema, puede recuperar el código exactamente como existía el 19 de junio de 2007, por lo que está depurando el código que el usuario está ejecutando realmente. Si descubres que el último cambio fue un gran error, puedes retroceder. Etc, etc.

Pero si tiene dos repositorios ... ¿Va a hacer cada compromiso de forma idéntica en ambos repositorios? Al menos eso es un montón de trabajo extra. En el peor de los casos, tarde o temprano alguien va a cometer un error, se olvidará de comprometerse con uno o no comprometerse hasta el día siguiente después de que alguien más haya hecho un commit intermedio, y los repositorios no serán realmente idénticos. ¿O vas a alternar, a veces saliendo de A y, a veces, saliendo de B? Pero entonces nadie sabrá lo que hay en ninguna de las dos.

Pude ver el uso de dos VCS diferentes durante unos días o unas pocas semanas solo para probarlos y ver cómo funcionan, obtener una sensación que te gusta más. Pero aun así, no haría eso como mi sistema de producción. Tendría el VCS de producción real, y luego el otro del lado con el que jugamos, pero nadie lo trata con autoridad.