2012-07-03 20 views
5

En mi compañía tenemos un servidor de subversión y todos usan subversión en sus máquinas. Sin embargo, me gustaría usar git, realizar cambios localmente y luego "presionarlos" cuando esté listo.¿Es git svn dcommit atomic?

Sin embargo, no puedo entender lo que sucede en la siguiente situación. Digamos que hice 3 commit de git localmente y ahora estoy listo para "empujar" todo en el servidor de subversión. Si entiendo correctamente, git svn dcommit básicamente debe hacer 3 commits secuencialmente en el servidor, ¿verdad? ¿Pero qué sucede si mientras tanto (digamos entre el segundo y el tercer compromiso) otro colega mío emite un compromiso? Los escenarios que se me ocurren son:

1) Git especie de "bloquea" (es que incluso es posible) el servidor de la subversión durante compromete para que mis cometa, está haciendo de forma atómica y uno de mi colega se realiza después de la mía

?

2) El historial de confirmaciones en el servidor se convierte en mine1-mine2-other-mine3 (incluso si 'other' falla, ya que mi colega no tiene una copia de trabajo actualizada en ese momento).

Creo que es el n. ° 2, pero tal vez la velocidad de compromiso es tan alta que rara vez se convierte en un problema. Entonces, ¿cuál es, # 1 o # 2?

+0

no si falla otro. Pero no sé (+1) –

Respuesta

5

No se admiten bloqueos en Git, no es una forma de Git (la forma de Git es bifurcación y merginig). Con git-svn obtendrás el historial de mine1-mine2-other-mine3. Si necesita atomicidad, eche un vistazo al proyecto SubGit (está instalado en el servidor SVN y crea una interfaz Git pura para el repositorio SVN).

Hubo una similar question recientemente que podría ser interesante para usted.

+0

+1 De todos modos, creo que el problema es que el servidor SVN no admite bloqueos. Incluso si fuera la manera de imbécil, no hay nada que bloquear, me temo. – Emiliano

+0

Solo tienes la historia de mine1-mine2-other-mine3 si tienes suerte. Si no es así, su compromiso se detiene y debe seguir el procedimiento enumerado anteriormente para obtener las confirmaciones que no fueron confirmadas. – Rutix

0

Si tiene suerte, entonces número 2 pero la mayoría de las veces no tiene tanta suerte. En mi experiencia, cuando realizo una gran cantidad de confirmaciones y alguien más se compromete mientras lo hace, generalmente ocurren dos cosas:

  1. Se detiene al realizar otros cambios.
  2. Pierdes las confirmaciones aún no confirmadas.

Número 2 es realmente muy molesto. El principal problema es que necesitas estar totalmente actualizado para usar git svn dcommit. Esto es porque git-svn no permite que el servidor combine revisiones sobre la marcha. (Porque requeriría que ambos committers tuvieran un árbol de trabajo con ambos cambios).

La única manera de resolver esto son los siguientes pasos que encontré here

  1. abierto .git/logs/HEAD
  2. Busque su más reciente confirmación (commit en cuenta que estos están ordenados por “ tiempo Unix”, aunque también se puede encontrar la más reciente mediante la lectura de la shortlog no
  3. Confirmar que el commit que has encontrado es la correcta: mostrar git
  4. git reset de hash --hard de registro
  5. svn git rebase
  6. svn git dcommit

Siguiendo este procedimiento le permite despegar desde donde falló. Espero que lo solucionen pronto, pero dijeron que aún no es una prioridad para ellos.

Por supuesto, si commite grupos pequeños y tiene una conexión rápida al servidor, no debería suceder tan a menudo. (Solo lo tengo 2-3 veces cuando trabajo activamente y me comprometo todos los días durante 6 meses).

+0

Otra opción es aplastar antes de presionar, de modo que solo tengo una confirmación por vez, aunque puede ser bastante grande – Emiliano

+0

Solo cometer una confirmación debería ocasionarle menos problemas. Aunque esto, por supuesto, va un poco en contra del principio de la totalidad compromete :). Agregué información sobre cuál es el problema principal en este caso. – Rutix

Cuestiones relacionadas