Múltiples sistemas simultáneos de control de versiones

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 types de VCS (git, mercurial, etc.), y estoy considerando probarlos; sin embargo, muchos de los arguments a favor o en contra de un VCS en particular parecen ser en gran parte una preference subjetiva, así que ' Probablemente termine dando una mirada a cada uno.

Al pensar en hacerlo, me preguntaba si incluso teóricamente era posible usar 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 lists de exclusión?

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

Ciertamente, esto es posible, incluso 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 repository de Subversion central henetworkingado por varias razones, pero en el que los desarrolladores desean usar Git para el aumento de productividad que proporciona.

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

Mercurial (con hgsubversión), git (con git-svn) y bzr (bzr-svn) tienen una opción para sincronizar con un repository de svn ascendente.

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

Por lo general, es difícil (pero no imposible) manejar múltiples VCS en una sola base de código. Sin embargo, es posible que tenga problemas con la eliminación de files … A veces, un VC no se dará count de que se ha eliminado un file.

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

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 repository local separado del repository 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 que contengan simultáneamente tu repository central, eso es técnicamente posible, pero una idea realmente mala. El objective de un VCS es que mantenga un historial de todos los cambios realizados en los files, que pueda ver qué cambios se realizaron cuando y, si los usuarios incluyen comentarios decentes a mitad de path, 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étera etcétera.

Pero si tienes dos repositorys … ¿Vas a hacer cada compromiso de manera idéntica a ambos repositorys? Al less 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 repositorys 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, get una idea de lo 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.

Sé que no está usando muchos 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 repository de Git (y no tendrán más conocimiento de que es Git). Creo que también hay otros frontales disponibles para él.

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

Si utiliza bazar para su repository local, lo más problemático es cuando el repository de bazar local está separado y desea comprometerse con su repository remoto. A veces tienes que hacer "sobrescribir" para resolverlo.

No experimento este "problema de repository divergente" cuando uso git-svn para actualizar mi repository de git local con los cambios desde el repository 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 time. Debido a que me he encontrado con esto una y otra vez, lo he documentado y ahora no me parece tan importante.