svn - tortoise - Tenedor y sincronizar el repositorio de Google Code Subversion en GitHub
svn tortoise (7)
servicio svn2github
El sitio web http://svn2github.com/ proporciona un servicio para bifurcar cualquier repositorio SVN de acceso público en Github (en https://github.com/svn2github/projectname ). Lo intenté; al presionar "Hacer un espejo", aparentemente no hizo nada durante unos segundos y mostró el mensaje "error", pero realmente funcionó. El nuevo repositorio fue de hecho creado, conteniendo el código del repositorio SVN.
A continuación, bifurcaría el repositorio que crea y trabajaría en su propio tenedor. A continuación, envíe sus cambios al proyecto original utilizando su rastreador de errores.
Mirando los repositorios existentes bajo el usuario de Github del servicio (por ejemplo, "svn2github empujado a dominar en svn2github / haxe hace 5 horas"), parece que regularmente realiza cambios desde el repositorio SVN. No hay información sobre quién ejecuta el servicio en el sitio web, por lo que no apostaría a que continúe ejecutándose indefinidamente, pero funciona por ahora (y si alguna vez falla, puede actualizar manualmente su fork).
Plataforma de lanzamiento
Si no está configurado para usar Git y Github, otra alternativa es usar Launchpad.net. Launchpad puede importar automáticamente repositorios SVN (también CVS) en una rama bzr personal. Para ello, cree un proyecto Launchpad, luego vaya a la nueva página de importación , seleccione Subversion e ingrese la URL (por ejemplo, http://projectname.googlecode.com/svn/trunk/ ). Según el tamaño del proyecto, la importación inicial puede demorar algunas horas. Las importaciones posteriores se ejecutarán periódicamente.
Para obtener más documentación, consulte Importaciones de VCS en la Ayuda de Launchpad .
¿Cómo puedo bifurcarme y mantenerme sincronizado con un repositorio de Subversion de código de Google al que no tengo acceso de escritura en un repositorio de GitHub?
Quiero ser capaz de desarrollar mis propias características en mi repositorio de Git, pero también quiero sincronizar con el repositorio de Google Code Subversion. Para buscar soluciones desde el lado del proyecto de Google Code.
Sé acerca de git-svn y lo usé antes para subir y bajar a un repositorio de Subversion sobre el que tenía control total. Pero no sé cómo mantenerme sincronizado con un repositorio de Google Code Subversion.
Encontré estas instrucciones en el blog de Yu-Jie Lin :
Primero clona el repositorio de Subversion y presiona al Git:
git svn clone https://foo.googlecode.com/svn/ git-foo
cd git-foo
git remote add git-foo [email protected]:username/foo.git
git push git-foo master
Después de comprometerse en el repositorio de Subversion, ejecute
cd /path/to/git-foo
git svn fetch
git svn rebase
git push git-foo master
GitHub ahora admite la importación directa de proyectos de subversión (consulte http://help.github.com/import-from-subversion/ ). Simplemente cree un nuevo repositorio y luego haga clic en "Importar desde Subversión" en la pantalla "Pasos siguientes". Sin embargo, no admite más sincronización: /.
Hmm ... En mi compañía estaba haciendo casi lo mismo. Solo tengo ambos .svn y .git repo en el mismo directorio (se puede sacar svn repo y crear git repo en esta copia de trabajo).
Luego, usar svn up y git push hizo lo correcto. Por supuesto, si diverges mucho tendrás que fusionar cosas a mano.
La rama remota de git-svn es más o menos lo mismo que un control remoto regular de Git. Entonces en su repositorio local puede tener su clon git-svn y enviar cambios a GitHub. A Git no le importa Si crea su clon git-svn y envía exactamente los mismos cambios a GitHub, tendrá un espejo no oficial del repositorio de Google Code. El resto es Vanilla Git.
git svn clone http://example.googlecode.com/svn -s
git remote add origin [email protected]:example/example.git
git push origin master
Ahora que tiene esto, ocasionalmente tendrá que sincronizar el repositorio de Subversion con Git. Se verá algo así como:
git svn rebase
git push
En gitk o lo que sea, esto se vería así:
o [master][remotes/trunk][remotes/origin/master]
|
o
|
o
Y cuando ejecutas git svn rebase , tendrías esto:
o [master][remotes/trunk]
|
o
|
o [remotes/origin/master]
|
o
|
o
Así que ahora ejecutar git push empujaría esos commits a GitHub, la rama [remotes / origin / master] allí. Y volverás al escenario en el primer diagrama de arte ASCII.
El problema ahora es, ¿cómo trabajas tus cambios en la mezcla? La idea es que nunca te comprometas con la misma rama que eres git-svn-rebase-ing y git-pushing. Necesita una sucursal separada para sus cambios. De lo contrario, terminarías redefiniendo tus cambios sobre los de Subversion, lo que podría molestar a cualquiera que clone tu repositorio de Git. ¿Sígueme? De acuerdo, entonces crea una rama, llamémosla "características". Y haces una confirmación y la envías a GitHub a la rama de características. Tu gitk se vería así:
o [features][remotes/origin/features]
|
o
|
o [master][remotes/trunk][remotes/origin/master]
|
o
Aquí tienes tus funciones para ramificar un par de commits antes de la sucursal de Google Code, ¿verdad? Entonces, ¿qué sucede cuando quieres incorporar cosas nuevas de Google Code? git svn rebase primero git svn rebase y obtienes esto:
o [features][remotes/origin/features]
[master][remotes/trunk] o |
| o
o /
|/
o[remotes/origin/master]
|
o
Si git push maestro de git push , puedes imaginar que el [control remoto / origen / máster] está en el mismo punto que el maestro. Pero su rama de características no tiene los cambios. Sus opciones ahora son fusionar el maestro en características o funciones de rebase. Una fusión se vería así
git checkout features
git merge master
o [features]
/|
/ o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Luego, presiona las funciones a GitHub. He dejado los controles remotos para que el maestro ahorre espacio, estarían en el mismo punto que [maestro] .
El enfoque de rebase es un poco más malvado: tendrías que empujar con fuerza, ya que tu empujón no sería una fusión de avance rápido (sacarías la rama de funciones de debajo de alguien que la había clonado). Realmente no se considera correcto hacer esto, pero nadie puede impedirte si estás decidido. También facilita algunas cosas, como cuando los parches son aceptados en sentido ascendente en una forma ligeramente retrabajada. Ahorraría tener que lidiar con conflictos, simplemente puede rebase - omita los parches ascendentes. De todos modos, una rebase sería así:
git rebase master features
o [features]
|
o
| o [remotes/origin/features]
[master] o |
| o
o /
|/
o
|
o
Y luego tendrías que git push --force eso. Puedes ver por qué necesitas forzarlo, la historia tiene un gran cisma antiguo desde los [controles remotos / origen / características] a la nueva versión actual [funciones] posteriores.
Todo esto funciona, pero es un gran esfuerzo. Si vas a ser un colaborador habitual, la mejor opción sería trabajar así durante un tiempo, enviar algunos parches de subida y ver si puedes obtener acceso de confirmación a Subversion. De lo contrario, quizás no envíe sus cambios a GitHub. Manténgalos locales e intente que sean aceptados aguas arriba de todos modos.
No estoy muy seguro de qué es lo que quiere, pero, por supuesto, puede extraer de un repositorio de subversión y enviarlo a un repositorio de Git desde la misma copia de trabajo. Y también puede volver a git svn dcommit al repositorio de subversión. Sin embargo, no puedes hacer la sincronización del repositorio de GitHub contra el repositorio de subversión. Además, cuando tienes confirmaciones en tu copia de trabajo que todavía no están en el repositorio de subversión necesitarás volver a establecer una base si el repositorio de subversión se actualizó, forzándote a git push --force the "new" commits a GitHub.
Un recorrido para sincronizar desde Google Code a GitHub está disponible en fnokd.com . El autor utiliza un servidor remoto siempre activo y un trabajo cron para automatizar la sincronización y mantiene el tronco SVN en una rama de GitHub llamada "proveedor".