¿Hay algún problema si utiliza un repository compartido entre SVN y Git, sin git-svn?

Fondo

En nuestros equipos de desarrollo distribuidos, tenemos un repository SVN centralizado ubicado de forma remota que se utiliza para múltiples equipos que se comprometen con el código fuente. Para mejorar el performance local, hemos decidido utilizar Gerrit (ciertamente Git en lugar de SVN) para nuestro process de revisión de código, por lo tanto estamos configurando un maestro de Git como un "HUB" interoperando con el repository SVN remoto.

Problema

Normalmente, la solución a este problema es gitsvn. Sin embargo, la twig clonada a través de git-svn tiene una estructura de carpetas diferente en lugar de la tradicional ".git", que NO puede ser reconocida por Gerrit.

Solución en el presente

Entonces adoptamos un medio que parece un poco ingenuo.

  1. Verifique el repository SVN remoto.
  2. Exactamente en el mismo directory que la copy de trabajo SVN, git clona el repository homólogo de git. Entonces en este directory también hay un ".git" además de ".svn".

    $ svn co http://remote.svn.repository/some_project

    $ cd some_project

    $ git clone --no-checkout git_reop ./tmp

    $ mv ./tmp/.git ./ # Move .git directory to SVN working copy.

    $ rm -rf ./tmp

    $ git reset --hard HEAD # This is tricky to tell git I want to use this directory as unstaged.

Pregunta

¿Hay algún problema si se usa un repository compartido entre SVN y Git, solo mediante la extracción del repository Git en el mismo directory que la copy de trabajo SVN sin git-svn?

No hay un "problema" real en el sentido de que ambos sistemas pueden ignorarse el uno al otro.
(Excepto que git necesita ignorar cualquier directory .svn/ , o la carpeta .svn/ única, si está utilizando el último SVN 1.8)

Pero tu git repo debe haber obtenido todos los últimos cambios de http://remote.svn.repository/some_project antes de ser clonado dentro de ese repository (para ser utilizado por gerrit).
Y no puede retener el autor y las dates con git-svn , tampoco creo que una synchronization manual pueda hacerlo, lo que significa que su sistema de revisión de código (gerrit) podría no ser tan eficiente en esas condiciones (es decir, revisar cambios sin conocer al autor) )

Este enfoque se vuelve engorroso rápidamente ya que el mapeo entre las revisiones de Subversion y sus contrapartes de Git es implícito; también es difícil mantener la correspondencia adecuada de los patrones de ignorar en los repositorys de Subversion y Git.

Una solución alternativa sería usar SubGit, que es un espejo Git-SVN bidireccional del lado del server. A continuación se muestra un ejemplo sobre el uso de SubGit 2.0 (actualmente en la etapa EAP):

 $ subgit configure --svn-url http://host.com/svn/repo GIT_REPO # Adjust GIT_REPO/subgit/authors.txt to add author names and emails # Specify at least one username/password at GIT_REPO/subgit/passwd $ subgit install GIT_REPO 

Después de eso, GIT_REPO se sincroniza con su repository de Subversion. Puede usar cualquier cliente de Git para trabajar con este repository de Git: todas las confirmaciones enviadas se envían inmediatamente a SVN.

Además, puede configurar el server de Gerrit y trabajar con él de la siguiente manera:

 $ git init . $ git remote add subgit SUBGIT_URL $ git fetch subgit $ git remote add gerrit GERRIT_URL $ git fetch gerrit $ git commit -m 'Work in progress' $ git push gerrit $ git push subgit 

Tan pronto como se emite el último command, SubGit traduce la confirmación de Git correspondiente a la revisión de SVN.

SubGit es un producto comercial, pero es gratuito siempre que esté en etapa de EAP. Soy uno de los desarrolladores de SubGit.