Resolviendo conflictos Git Svn

Question

Estoy usando Git-Svn para interactuar con un repositorio Svn en el trabajo y parece que no puedo encontrar una manera de resolver conflictos de manera efectiva por mi vida. He leído otras preguntas sobre este tema, pero evidentemente necesito algo aún más correctivo porque siempre parezco terminar en un ciclo sin fin. Rebase, use mergetool (meld) para resolver mis conflictos y, cuando llegue al final de todo eso, trato de hacer un dcommit y me sale un conflicto de combinación durante el error de confirmación.

Sé que esto se siente como un duplicado, pero la frustración me hace preguntar de nuevo, con algunos detalles muy específicos acerca de cómo voy sobre esto para que con suerte alguien pueda decirme exactamente dónde está arruinado mi proceso.

Mi configuración:

que tienen una sucursal remota (svn/trunk), una rama local (tronco) y la otra rama local que suelen trabajar en (tronco de trabajo). el tronco fue extraído de svn/trunk y el tronco de trabajo fue extraído del tronco.

Esto es lo que he estado haciendo:

1. En mi baúl, git svn rebase (devuelve conflictos)
2. git mergetool
3. [resolver los conflictos de ese archivo]
4. guardar el archivo resultante de la fusión de meld y close meld.
5. git add .
6. git rebase --continue
7. [enjuagar, repetir]
8. Si consigo un mensaje preguntando si he usado git add, me git rebase --skip

Cuando llegue al final de todos los cambios reportados, todo se detiene y creo que tal vez no estoy seguro de qué hacer en este momento. Git no muestra nada que confirmar y parece que estoy de vuelta en el maletero. Git luego me permite comprometerme, pero si pruebo una rebase inmediatamente después, termino resolviendo los conflictos que acabo de resolver.

Claramente hay una pieza crítica que me falta aquí, pero simplemente no la veo y está causando muchos problemas y frustración. Las fusiones pueden ser fáciles en Git, pero estoy seguro de que no es así.

Gracias.

ACTUALIZACIÓN: Solo quería lanzar una actualización rápida para describir mi flujo de trabajo en caso de que sea una parte (o la totalidad) del problema.

Para comenzar, después de clonar mi repositorio con un prefijo svn/, tengo mi rama remota svn/trunk. Dado que:

1. I git co -b trunk svn/trunk para ver mi control remoto en una sucursal local.
2. I git co -b working-trunk para crear una rama de trabajo que utilizo para crear un grado de separación más para que mi troncal local siempre pueda reflejar mi troncal remota.
3. Elimino la rama maestra predeterminada (cuando trabajo con svn, me resulta más fácil pensar en términos de "troncal" en lugar de "maestro").

Una vez que tengo todos mis ramas, mi flujo de trabajo típico se parece a esto:

1. En trabajo tronco, hago mis cambios y Commit.
2. I git co trunk y hacer un git svn rebase.
3. Suponiendo que se ha vuelto a establecer el código nuevo, I git rebase working-trunk.
4. git co working-trunk
5. git merge trunk
6. git rebase trunk
7. git co trunk
8. git merge working-trunk
9. git svn dcommit

Es un montón de pasos, lo sé, pero eso es lo que todo el mundo aquí y en otros lugares ha recomendado. ¿Podría mi falla fatal estar en algún lugar de ese proceso?

Gracias de nuevo.

Answer 1

Recomendaría usar git rebase en lugar de git merge. Svn mantiene una historia lineal y parece confundirse con fusiones de git a veces. El uso de git rebase asegura una historia lineal que svn entiende.

ver: http://learn.github.com/p/git-svn.html para obtener un poco más de información y pautas.

Answer 2

Intenté esto con un conflicto (n pequeñito) forzado, y después del git svn dcommit no tuve más conflictos. Una diferencia es que no recibí un mensaje sobre git add. ¿Es posible que su equipo envíe muchos compromisos que entren en conflicto con su trabajo? Parece poco probable, pero parece ser la explicación más simple.

Puede valer la pena recuperar el repo nuevamente en una ubicación diferente y probar si puede realizar cambios sin conflictos para asegurarse de que no haya ningún problema de comunicación durante la etapa dcommit que se oculta de alguna manera.

ACTUALIZACIÓN: Otro pensamiento que tuve: Hice un git add foo.bar cuando terminé de resolver el conflicto. ¿Es posible que git add . esté haciendo algo inesperado? Realmente no estiro las capacidades de git svn tanto, entonces estos son más o menos WAG.

Answer 3

Parece que algo no funciona de la manera que usted cree que es. Si no son las cosas poco probables que sugirió Hank Gay, entonces es otra cosa poco probable.

Mi improbable posibilidad es que la estructura de su bifurcación no sea lo que usted cree que es o que no esté reescribiendo en la sucursal que usted cree que es. Por lo tanto, sugerimos que:

1. git branch sólo para confirmar la estructura de las ramas es lo que esperas

2. Añadir
   export PS1='\e[0;31m\n\w$(__git_ps1 "(%s)") $ \e[m'
   a ~ /.bash_profile y conectarse de nuevo,
   mostrar la rama (y cualquier comando git en proceso) en su mensaje:

   /espacio de trabajo/wikka (featurebranch1 | REBASE-i) $

que le dará tienes más comentarios (y probablemente elimines este WAG como una posibilidad).

Answer 4

yo recomendaría usar git-svn sólo entre su local de tronco y el mando a distancia del tronco . Entre su troncal local y mytrunk local, adhiérase a las funciones estándar de solo git. Usted podría intentar un flujo de trabajo de la siguiente manera:

[SVN]---git-svn---[trunk]---branch---[mytrunk] 

Para fusionar, cambie a tronco y hacer un:

git svn rebase 

Esta tira en los cambios de la distancia y la fusiona con tronco . A continuación, cambiar a mytrunk y hacer un:

git rebase 

Esto empuja a los cambios de tronco y la fusiona con mytrunk. Creo que debería funcionar De lo contrario, simplemente clone git en el tronco local y trabaje en el clon.

Answer 5

Acabo de encontrar este problema al usar el flujo de trabajo recomendado, por lo que creo que no tenemos una respuesta aquí.

Así es cómo llegué a esta situación.

Tengo un git repo a través de git svn, usando la infraestructura de Apache.

Tengo una sucursal local.

trato de seguir este procedimiento:

1) rebase tronco. 2) fusionar troncal en una rama privada. 3) hacer el trabajo. 4) tronco rebase. 5) fusionar privado en el tronco. 6) dcommit.

Sin embargo, cometí un error y me olvidé de hacer un cambio de privado a maletero. Luego hice una serie de otros cambios en mi rama privada, y terminé en el ciclo de enjuague y repetición de un conflicto completamente espurio. El último cambio que había hecho era comentar una sola línea. Cuando borré esa línea en el cambio descuidado, produjo el conflicto que no se resolvería, sin importar qué. Finalmente utilicé - apostarlo.

Answer 6

Uno puede encontrar SubGit 's se acercan un poco más fácil:

1. Instalar SubGit en depósito de la subversión en el lado del servidor
2. Uso git no git-svn para enviar cambios al repositorio SVN *

La instalación de SubGit crea una contraparte Git del repositorio SVN. Clona este repositorio a tu local; crea cualquier rama y empújala al repositorio remoto de Git, SubGit convierte automáticamente estas ramas en SVN. Para obtener más información, consulte SubGit documentation y git-svn comparison.

* Funciona con cualquier cliente de Git.

Answer 7

Terminé teniendo el mismo problema (git svn rebase que devuelve conflictos). Descubrí el problema en mi flujo de trabajo. Aquí está el flujo de trabajo de E/usted debe seguir:

git svn rebase # put all the new commits on top 

git svn dcommit # push the new commits to svn (will rewrite each commit message to add the svn tag) 

git pull # merge the conflicts due to the commit messages 

git push # push the synchronized version to the remote git server 

Cada vez que se olvidó de combinar la historia después de dcommit, tengo nuevos conflictos (falsas) que aparecen si hago nuevas confirmaciones. Para resolverlos, puede seguir el enfoque que describió anteriormente o si se debe exactamente al mismo problema que yo, también puede hacerlo de manera automática usando:

git svn rebase --strategy ours