Me he llevado día y pico quebrándome la cabeza intentando aclararme sobre como interactuar entre git y svn, sin tener dos repositorios independientes almacenados de forma local. Así que intenté entender el comportamiento de git-svn a fin de usar dicho comando para actualizar svn desde mi repo git.
Sé que eso trae muchos problemas con las ramas del proyecto, que es quizás el aspecto de arquitectura que más dificulta la tarea de su sincronización. Pero partía de una premisa: nunca habrá cambios "nuevos" en el repositorio svn que no haya sido subidos por mí, es decir, nunca voy a necesitar hacer el clásico pull desde svn (que en git-svn, es git svn rebase).
Pero eso no fue suficiente. Para empezar, no conseguí usar el repo de svn como un repo remoto sin más. Primero hay que bajarse el repo svn (con git svn clone), luego usar git de forma normal, sincronizándolo con tu repo git de la web también de forma normal, y todo de forma normal, y cuándo lo desees, con git svn dcommit subes tus cambios a svn. Ésto es aceptable, aunque desearía no verme obligado a hacer un svn clone cuando el repo svn está completamente vacío, estándo el de git con contenido incluido. Sencillamente no me gusta o no me fío del todo.
Pero además, los dcommit de git-svn modifican la información de los commits de git puro, para adaptarlo. No quiero que svn ensucie a git. Además, ésto provoca una "pega" adicional: si realizas un commit, creas una nueva rama, vuelves a la master y realizas un dcommit, cuando intentes mergear la nueva rama no encuentra su punto de anclaje al haber sido modificado por dcommit, lo que produce conflictos.
Ese es un detalle que no me gustaba nada, y que me hacía temer errores en un futuro. No quiero partirme la cabeza con una herramienta, porque las herramientas significan exáctamente lo contrario: ahorrarte trabajo, no producirtelo. Si no veo las cosas claras o no me convencen, las reniego. Y después de tanto, todavía no me llegó a quedar claro como se sincronizaban las ramas y los tags (en general, la jerarquía de directorios de svn) entre git y svn.
Así que, al final, tendré dos copias locales. Cuando quiera actualizar svn, copio los archivos y santas pascuas, cosa que ya me habían aconsejado en la lista de correo del CUSL5.
Sé que eso trae muchos problemas con las ramas del proyecto, que es quizás el aspecto de arquitectura que más dificulta la tarea de su sincronización. Pero partía de una premisa: nunca habrá cambios "nuevos" en el repositorio svn que no haya sido subidos por mí, es decir, nunca voy a necesitar hacer el clásico pull desde svn (que en git-svn, es git svn rebase).
Pero eso no fue suficiente. Para empezar, no conseguí usar el repo de svn como un repo remoto sin más. Primero hay que bajarse el repo svn (con git svn clone), luego usar git de forma normal, sincronizándolo con tu repo git de la web también de forma normal, y todo de forma normal, y cuándo lo desees, con git svn dcommit subes tus cambios a svn. Ésto es aceptable, aunque desearía no verme obligado a hacer un svn clone cuando el repo svn está completamente vacío, estándo el de git con contenido incluido. Sencillamente no me gusta o no me fío del todo.
Pero además, los dcommit de git-svn modifican la información de los commits de git puro, para adaptarlo. No quiero que svn ensucie a git. Además, ésto provoca una "pega" adicional: si realizas un commit, creas una nueva rama, vuelves a la master y realizas un dcommit, cuando intentes mergear la nueva rama no encuentra su punto de anclaje al haber sido modificado por dcommit, lo que produce conflictos.
Ese es un detalle que no me gustaba nada, y que me hacía temer errores en un futuro. No quiero partirme la cabeza con una herramienta, porque las herramientas significan exáctamente lo contrario: ahorrarte trabajo, no producirtelo. Si no veo las cosas claras o no me convencen, las reniego. Y después de tanto, todavía no me llegó a quedar claro como se sincronizaban las ramas y los tags (en general, la jerarquía de directorios de svn) entre git y svn.
Así que, al final, tendré dos copias locales. Cuando quiera actualizar svn, copio los archivos y santas pascuas, cosa que ya me habían aconsejado en la lista de correo del CUSL5.
Nas!
ResponderEliminarEn mi caso tenía un problema parecido, y era cómo utilizar un DVCS junto con SVN para gestionar mis ramas de una manera más potente (e indolora) que el SVN tradicional.
Al final he terminado usando bzr-svn, que me da la impresión que es bastante más sencillo que git-svn. No sé si bzr es tan potente como git, pero para lo que necesito de un DVCS es suficiente. Si tienes un rato echaría un vistazo a http://doc.bazaar.canonical.com/latest/en/user-guide/svn_plugin.html. En mi caso me resulta muy cómodo y transparente ;-)
HTH!!
Muchas gracias, aunque ya estoy en git y no creo que me cambie, pero si el año que viene vuelvo a participar en el concurso, no dudes que le hecharé un vistazo.
ResponderEliminarDonde, como para descargar este software. gracias
ResponderEliminar