Diferentes sistemas de control de versiones distribuidas trabajando juntos

Question

Mi oficina tiene una instalación central de Source Safe 2005 que usamos para el control de código fuente. No puedo cambiar lo que la oficina usa en el servidor.

Desarrollo en una computadora portátil y me gustaría tener un repositorio de control de fuente local diferente que pueda sincronizar con el servidor central (cuando esté disponible) independientemente de lo que sea ese proveedor central. El motivo de la solicitud es que pueda mantener una sucursal/compilación estable local para las presentaciones de los clientes mientras continúo desarrollándome sin tener que pasar por los aros llameantes. Además, como consultor, mis clientes pueden solicitar que use su proveedor de control de código fuente y la flexibilidad aquí facilitaría la vida.

¿Puede alguno de los clientes de control de fuente distribuida manejar eso?

Answer 1

Bueno ... KernelTrap tiene something on this. Parece que puede usar vss2svn para canalizar el repositorio de Source Safe en un repositorio de Subversion, luego use el muy buen git-svn para incorporarlo a un repositorio de git local.

Supongo que los commits a VSS no serían un proceso suave y automático con este método.

Answer 2

Debería poder verificar la versión actual del código y luego crear un repositorio git a su alrededor. Actualizarlo y enviarlo a su repositorio git local debería ser sencillo. Como debería clonarlo.

El único inconveniente es que necesita que ambos se ignoren entre sí (he hecho algo similar con SVN) al jugar con los archivos de ignorar apropiados. Supongo que SourceSafe te permite ignorar las cosas. Y deberá realizar ciertas operaciones dos veces (como decirles a ambos que está eliminando un archivo).

Answer 3

algún día trabajo en una compañía que usa VSS (y en otras compañías que usan otras menos conocidas SCM) pero prefiero usar SVN (algún día probaré GIT) para desarrollo activo, para mí y mi grupo.

En primer lugar, esta es una buena idea, si se compromete con VSS son pocos durante el mes, porque trabajar con otro SCM (que VSS) le da más flexibilidad, pero el VSS de SVN es caro en el tiempo.

Mi solución fue:

VSS -> SVN: Tengo guión Linux (o script hormiga, o script XXX) que copien de currrent trabajo directorio de actualización de VSS a la corriente SVN, a continuación, actualice el cliente y actualización de SVN/fusionar/comprometerse a SVN. Con esto, usted es una actualización de los cambios del resto de la compañía que usa VSS.

SVN -> VSS: De esta manera, necesita una verificación de todos sus archivos de modificación a VSS, entonces simplemente puede usar la secuencia de comandos inversa para copiar desde el directorio SVN de actualización actual (ignorar directorios .svn) y copiar al actual actualizar el directorio de VSS, actualizar y confirmar.

Pero recuerde, en algunos casos vale la pena su tiempo para hacer esto.

Answer 4

This episodio de HanselMinutes cubre exactamente lo que esperaba escuchar. Aparentemente, Git puede usarse localmente y luego adjuntarse a repositorios externos de subversión/vss según sea necesario. Hablan de eso 14 ~ 15 minutos en.