version-control - usados - ¿qué es un sistema control de versiones centralizado?
Diferentes sistemas de control de versiones distribuidas trabajando juntos (4)
Bueno ... KernelTrap tiene algo de esto . Parece que puedes usar vss2svn para canalizar el repositorio de Source Safe en un repositorio de Subversion, y luego usar el muy buen git-svn para incorporarlo a un repositorio de git local.
Asumiría que los commits a VSS no serían un proceso suave y automático usando este método.
Mi oficina tiene una instalación central de Source Safe 2005 que usamos para control de 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 se pueda sincronizar con el servidor central (cuando esté disponible) independientemente del 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?
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.
La única pega es que necesitas que ambos se ignoren el uno al otro (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).
algún día trabajo en una compañía que usa VSS (y en otras compañías que usan otro SCM menos desconocido) pero prefiero usar SVN (algún día probaré GIT) para el desarrollo activo, para mí y mi grupo.
En primer lugar, esta situación es solo una buena idea, si el compromiso con VSS es poco durante el mes, porque trabajar con otro SCM (que VSS) le da más flexibilidad, pero el compromiso con VSS de SVN es costoso en el tiempo.
Mi solución fue:
VSS -> SVN: Tengo script de Linux (o script de ant, o script de XXX) que copia del actual trabajo de directorio de actualización de VSS al SVN actual, luego actualiza el cliente de SVN y actualiza / fusiona / confirma a SVN. Con esto, está actualizando los cambios del resto de la compañía que usa VSS.
SVN -> VSS: de esta forma, necesita una verificación de todos sus archivos de modificación en VSS, luego puede simplemente usar la secuencia de comandos inversa para copiar desde el directorio SVN de actualización actual (ignorar directorios .svn) y copiar al directorio VSS de actualización actual, actualizar y confirmar.
Pero recuerde, en algunos casos vale la pena su tiempo para hacer esto.
Este 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.