SubGit: migración gradual de Svn a Git
Abraham
SubGit es un software que se instale en el servidor y que mantiene sincronizados dos repositorios de Svn y Git, de tal modo que cuando se hace un cambio en alguno de estos dos repositorios, SubGit replica el cambio en el otro repositorio. Su propósito es proporcionar un camino de migración gradual de Svn a Git, ya que permitiría que gradualmente los desarrolladores vayan usando funcionalidad de Git cada uno a su ritmo, pudiendo algunos estar ya trabajando completamente sobre Git mientras que otros continúan trabajando contra el repositorio de Svn.
Se trata de un proyecto interesante que acaba de anunciar su primera Release Candidate de la versión 1.0. No es un proyecto opensource, sino comercial. Pero hasta tres usuarios del repositorio y hasta tres repositorios distintos, es gratuito. A partir de aquí tiene un precio de 850 euros al año por una licencia que permite hasta 10 desarrolladores y 10 repositorios, y de 1600 por hasta 25 desarrolladores y 25 repositorios. A partir de aquí hay que negociar los precios directamente con ellos.
¿Que os parece la idea detrás de SubGit? ¿Lo veis útil?
Reader Comments (5)
Desde mi ignorancia más absoluta pregunto:
¿Que me ofrece Git para convencerme de migrar de Svn a Git?
Un saludo
@Pedro: p.e. puedes echar un vistazo (para empezar) a los enlaces
GitSvnComparison y Why You Should Switch from Subversion to Git
@Pedro: si haces muchos branches y merges, hay una gran diferencia. Con SVN es un parto hacer merges, 2x3 hay sorpresas desagradables y complicaciones innecesarias. Git nació optimizado para ese manejo, entre otras cosas.
No conozco SubGit, pero no se hasta dónde pueda cumplir con su promesa. Suena demasiado bueno para ser cierto :D. Tal vez funcione muy bien con situaciones simples, pero dadas tantas limitaciones en el menejo de branches y merges de SVN, no puedo imaginarme cómo resolvería SubGit todos los casos donde SVN hace agua, y cada situación donde SVN pierde trazabilidad de los cambios. Hay situaciones imposibles de resolver en SVN sin una intervención manual, y no "creo" que SubGit pueda resolverlas automáticamente sin corromper nada. Debería probarlo muy bien, y así y todo creo que nunca me dejaría tranquilo.
Creo que lo mejor es pasarse a Git, y si hace falta, agregar una interfaz por SVN de solo lectura. Hacer cambios en ambos repositorios y confiar que se podrán syncronizar me parece muy arriesgado. Es solo una opinión, ojalá me equivoque.
Insisto, no conozco al producto y espero estar subestimándolo, está interesante, pero se me hace difícil creerlo (conocimiendo las sorpresas que siempre guarda SVN).
A mi me parece interesante, pero creo que es un poco caro para el beneficio obtenido
En mi opinión lo del control versiones distribuido está sobrevalorado, estoy seguro que la mayoría de la gente lo usa con un servidor central a lo SVN, pero solamente el poder deshacerte de los .svn, el poder hacer un cambio de nombre a un directorio o cambiarlo de sitio sin problemas (algo que hago continuamente en Java) es suficiente.
Por esas razones me ha dado siempre alergia usar SVN en mis proyectos personales opensource, un incordio, más trabajo para nada, fuente de problemas (por lo dicho antes), y total en mi caso prácticamente NUNCA vuelvo atrás, es decir lo acababa quitando. Pero ahora el impacto de Git es casi nulo y solamente utilizándolo como herramienta de copia de seguridad en el repositorio remoto vale la pena.
Por cierto ¿alguien se ha planteado que Git puede ser muy útil como herramienta de backup convencional?
Por lo demás me preocupa el crecimiento en tamaño del repositorio local, aunque he leído por ahí que se puede compactar, me gustaría saber si se puede eliminar el histórico de versiones más antiguo para ahorrar espacio ¿se puede?.