Trabajo en una tienda de SVN, pero para inyectar un poco de cordura en mi trabajo uso git-svn. Un número cada vez mayor de mis colegas también está viendo la luz, y ahora nos gustaría, en algunos casos, SVN completamente de lado. Actualmente, cada uno de nosotros tiene nuestro propio repository git-svn, pero debido a los valores hash muy diferentes no podemos compartir nada, excepto parches simples o vía SVN. ¿Cómo debemos organizar nuestros repos para permitir el intercambio directo (a través de git-remote)?
La única forma en que puedo pensar es en un repository git-svn único y compartido, que usamos como puerta de input a SVN, pero que probablemente sería un poco engorroso para trabajar, sería mucho mejor si todos lo hiciéramos. podría empujar a SVN directamente desde nuestros propios repositorys git-svn.
Editar: Desafortunadamente no tengo acceso de administrador al server SVN, por lo que las soluciones como subgit son de poca utilidad en este momento, aunque son de su interés.
Puedes mirar el subgit :
SubGit es una herramienta para una migration sin problemas de Svn a Git. Instálelo una vez en el lado del server y use Subversion y Git todo el time que desee.
SubGit le permite a uno configurar una Subversión bidireccional a la replicación de Git (mirror editable).
Y:
SubGit es una solución para una migration de Svn a Git en toda la compañía que es:
Much better than git-svn (see comparison); Requires no changes of the infrastructure that is already in place; Allows one to use all Git and all Subversion features; Provides genuine stress-free migration experience.
El gatewaying bidireccional entre dos sistemas de control de versiones diferentes es anterior a git por edades. Ya lo hice a mano entre CVS y Arch hace unos 10 años. Si no desea comprar un subgit, puede mantener el gateway manualmente o incluso intentar crear un script. El flujo de trabajo es simple:
trunk y master . trunk replica subversion, master es más los cambios desarrollados en git $ git svn fetch master$ git merge trunk trunk$ git merge master trunk$ git svn dcommit master$ git merge trunk Estamos exactamente en la misma situación. Lo que tenemos es (¡advertencia, algún pseudocódigo!):
un gancho de pre-recepción que verifica el nombre de usuario, luego por cada reference recibida y para todas las twigs mapeadas SVN: (git -> svn):
git checkout -f <branch> git reset HEAD --hard git clean -fdx git merge -n $newrev git svn dcommit si falló, revertir todo,
luego, después de todos los loops, actualice todas las twigs de SVN (usando la secuencia de commands, ver a continuación)
un cronjob que actualiza las twigs de git-svn con los últimos cambios de svn (svn -> git):
git checkout --orphan svn-update <random-branch-name> git svn fetch --all git branch -D <branch> && git branch --track <svn-branch> refs/remotes/<svn-branch> , ssh keys para authentication de git
De esta forma nadie usa SVN directamente y la única diferencia frente a git puro es que no puedes cambiar el historial de git-svn branches (ya que SVN no te permitirá comprometer eso).
sería mucho mejor si todos pudiéramos presionar a SVN directamente desde nuestros propios repositorys git-svn.
¿No es para qué git svn dcommit command git svn dcommit ?
Utilice git svn rebase para git svn rebase a establecer la base de su clon git en el svn repo central, luego git svn dcommit para enviar sus commits locales a svn.
Uso git svn todos los días con el espejo git GCC y funciona muy bien. Tal vez sea porque hay un espejo central de solo lectura, que se actualiza automáticamente desde svn commits, para que todos los que usen git-svn vean el mismo historial desde el espejo git y el mismo set de identificaciones de compromiso. Eso permite search y fusionar desde el espejo de solo lectura, luego solo con un git svn rebase y git svn dcommit para enviar cambios al svn repo. Esos cambios luego se sincronizan con el espejo de solo lectura y son recuperados por todos los demás, con los mismos ID.
Estoy en una configuration similar, y aquí hay un process que funcionó para mí y la gente con la que trabajo:
Una persona crea un repository de Git usando git svn clone y friends.
Todos los demás clonan ese primer repository de Git usando commands regulares de Git, luego copyn los bits de svn-remote.{name} del .git/config del primer repository. Hay instrucciones para hacer esto en los ejemplos en git help svn .
Ahora, todos tienen una configuration de git-svn que se puede usar para interactuar con el repository de Subversion.
Lo que es más importante, todos tienen una configuration de git-svn con las mismas twigs y el mismo historial de confirmaciones, lo que significa que las confirmaciones que git svn fetch y friends creen serán idénticas, incluidos los hashes . En ese punto, además de empujar y tirar al repository de Subversion, puede usar todas las características distribuidas más elegantes de Git entre ustedes.
A diferencia del Git normal, debe tener cuidado al compartir la configuration: si la estructura de su bifurcación diverge, sus hashes también divergirán. De vez en cuando, las cosas van a salir mal y hay que arreglarlas (una vez tuve dos git svn fetch estaban sucediendo a la vez, lo que hizo que los demás trabajaran de una manera sutil; tuve que rebobinar mi historial con git svn reset y relabelr para mantener mi hashes que coinciden con los de otras personas). Pero estas son las restricciones de mezclar las dos herramientas juntas.