2009-09-29 36 views
5

Estoy modificando un proyecto de código abierto que está almacenado en un repositorio SVN. Dado que mis cambios probablemente demorarán un tiempo en completarse, he verificado el proyecto como un repositorio Git utilizando el puente git-svn. No tengo acceso al repositorio de Subversion del proyecto, así que no puedo volver a enviar los cambios, pero me gustaría publicar mi repositorio de Git (en GitHub) para que otros puedan seguir el desarrollo de mis modificaciones.Publicar un repositorio "git svn"

Para actualizar un acuerdo de recompra "git svn", se utiliza git svn rebase, que, como su nombre indica, rebases cualquier cambio en la parte superior de los nuevos cambios desde el repositorio de Subversion. Por supuesto, no es una buena idea para empujar las ramas que hayas rebasada en un repositorio git público, por lo que en lo que respecta a un acuerdo de recompra clonado a partir de un repositorio SVN, tengo un par de preguntas relacionadas:

  1. Es ¿es seguro publicar una rama rebasada (usando git-svn rebase) en un repositorio público?
  2. Entiendo que, suponiendo que su rama principal en Git es aquella en la que está modificando los cambios del repositorio SVN, no debería hacer ningún desarrollo real en ese repositorio; es decir, si fusiona los cambios en el maestro, debe insertarlos en el repositorio SVN (usando git svn dcommit). Si cumple con esta política, ¿está bien publicar la rama principal rebasada en un repositorio público?

Respuesta

1
  1. Es seguro para publicar una rama SVN, pero sólo si todos los envíos son empujados al repositorio SVN usando git-svn dcommit. Si no tiene cambios en la rama, entonces git-svn rebase simplemente hará un avance rápido.

    Si alguien se bifurca desde su sucursal publicada, es importante que sepa que es de un repositorio SVN. Esto se debe a que si alguna vez intentas aceptar sus cambios, la única forma de impulsarlos al repositorio de SVN es básicamente reajustar sus cambios. Después de publicar los cambios confirmados nuevamente, tendrán que lidiar con las confirmaciones conflictivas, ya que el hash no coincidirá.

  2. Es seguro trabajar en master, pero probablemente no sea práctico. Desde arriba, no puede publicar sus confirmaciones hasta que ejecute git-svn dcommit. Por lo tanto, si tiene algún trabajo que no desea realizar, deberá moverlo a una rama separada antes de intentar publicar los últimos commits de SVN (es decir, git-svn rebase; git push)

Cuestiones relacionadas