Actualmente estamos considerando la opción de migrar de svn a git para todos los beneficios que ofrece git. Actualmente estamos preocupados por perder historia y analizar el problema. Nos gustaría saber si alguien tuvo otros problemas cuando migraron de svn a git.trampas svn -> git migration
No debería haber ningún problema al convertir de svn a git en cuanto a la pérdida de historial. Ese es el objetivo principal del software de control de revisiones de todos modos, para realizar un seguimiento de la historia.
La regla número uno es, por supuesto, hacer siempre una copia de seguridad de sus repositorios antes de convertirlos y realizar varias ejecuciones de prueba hasta que se sienta lo suficientemente seguro como para hacerlo en un entorno de producción.
Una gran diferencia es la forma en que se comportan los externos en Subversion en comparación con los submódulos de git. Ver:
Además, le espera para pasar un rato en el apoyo a los usuarios. Git es una bestia diferente y algunos usuarios de svn acostumbrados pueden encontrar que es un poco intuitivo de usar.
Editar: Git ha incorporado soporte para importar y trabajar con repositorios svn, usando git-svn.
Git-SVN importar toda la historia de Subversion (y algunos de metadatos adicionales) en Git repo
git svn clone url://path/to/repo -s
-s si tiene "estándar" repo-diseño en Subversion
pero algunos autores recomiendan a utilizar
git svn init -s http://example.com/svn/my_proj
git svn fetch
Algunos lectura útil adicional:
también agrega 'git svn fetch' al bucle en un script, para clonar grandes repositorios con numerosas etiquetas e historias profundas (y la desconexión ocasional) – prusswan
Gracias por su útil respuesta. –
surgen más problemas cuando hay ramas o etiquetas no estándar en SVN. Esto es cuando alguien no copió la carpeta trunk/ en tags/ o branches/, sino solo subcarpetas de la misma. Estas carpetas aparecen como revisiones "robadas" sin un antecesor común con el tronco. Pero el yo de contenido es correcto.
que era capaz de migrar la historia SVN, con la historia rama, al repositorio git con el guión que escribí aquí:
https://github.com/onepremise/SGMS
Usted puede apoyar ambos formatos:
/trunk
/Project1
/Project2
/branches
/Project1
/Project2
/tags
/Project1
/Project2
Este esquema también es popular y compatible:
/Project1
/trunk
/branches
/tags
/Project2
/trunk
/branches
/tags
Subversion y Git difieren mucho en términos de cómo representan la historia, mantienen los metadatos y manejan los problemas específicos del sistema. Tales diferencias hacen que la mayoría de las trampas:
de combinación que falta se compromete en Git:
Subversion mantiene información sobre las fusiones realizadas como svn: mergeinfo en archivos y directorios. La conversión a información de Git sobre fusiones de subárboles y selecciones de cerezas se pierde ya que Git no tiene medios para representarlo.
Ver también After “git svn clone”, I still don't have fantastic branch-merging commit?
Externos y submódulos:
Además de @Sundae's answer: echar un vistazo a SmartGit - esta herramienta realmente puede importar svn: externos. Sin embargo, utiliza un archivo de un formato especial que no es compatible con otros clientes de Git.
directorios vacíos:
Subversion trata los directorios como ciudadanos de primera clase, Git no hace - hay que añadir algún archivo marcador de posición para mantener un directorio después de la conversión. git-svn intenta manejar esto con un "registro no controlado" de almacenamiento externo, pero eso solo funciona cuando sigues usando git-svn después de la conversión.
svn: ignore y .gitignore, svn: eol-style/tipo mime y .gitattributes:
git-svn no convierte propiedades de Subversion en .gitattributes correspondiente automáticamente. Uno tiene que ejecutar un comando específico después de la conversión para agregar atributos; de todos modos, esta información se pierde al realizar la conversión.
propiedades de Subversion arbitrarias: propiedades
Cualquier archivo personalizadas y revisión se pierden al depósito de la subversión se convierte en repositorio Git.
Eche un vistazo a SubGit. Se adapta bien a la mayoría de las trampas, otros están planeados para ser arreglados en versiones posteriores.
SubGit ha sido creado para ser una herramienta de migración para toda la empresa. Uno puede usarlo como una herramienta de conversión única, pero en general es una herramienta de sincronización continua de Subversion y Git. Puede encontrar más información en su documentation page.
La regla número uno es, por supuesto, usar git-svn para importar SVN en Git repo, ** no convertir ** –
Muy buen punto en verdad. Estoy editando mi respuesta para reflejar eso. – Sundae
@Lazy Badger, ¿cuál es su distinción entre "importar" y "convertir"? La forma estándar de "convertir" un repositorio svn a un repositorio git sí que usa git-svn. – ebneter