¿Es seguro interrumpir una llamada de compromiso que parece estar colgada?

Estoy usando el puente git-svn y he reorganizado una gran cantidad de files en mi repository para que esté un poco mejor organizado.

git svn dcommit para git svn dcommit los cambios al server SVN y el process parece estar colgado. No recibo uso de CPU ni uso de networking para la llamada de dcommit en los últimos 45 minutos. El resultado está atascado en:

 > git svn dcommit ...snip... R zlib/vs2005/zconf.h => tools/zlib/vs2005/zconf.h R zlib/vs2005/zlib.h => tools/zlib/vs2005/zlib.h R zlib/vs2005/zlib_ds.lib => tools/zlib/vs2005/zlib_ds.lib R zlib/vs2005/zlib_ds.pdb => tools/zlib/vs2005/zlib_ds.pdb R zlib/vs2005/zlib_s.lib => tools/zlib/vs2005/zlib_s.lib R zlib/vs2005/zlib_s.pdb => tools/zlib/vs2005/zlib_s.pdb 

Y ahí es donde ha estado durante unos 45 minutos ahora.

Editar: eventualmente terminó diciendo que se agotó el time de espera de la connection HTTPS. Esto tomó aproximadamente una hora y media para suceder.

Parece que no puedo encontrar ninguna información definitiva sobre lo que sucederá si interrumpo esta llamada de dcommit y lo que tendré que hacer antes de intentar volver a enviar los cambios nuevamente desde mi repository local al server SVN.

Puedo responder una parte de mi pregunta: ¿Qué debería hacer antes de volver a intentarlo?

Después de que se agotó el time de espera de la connection y mi post fue devuelto, tuve que hacer un git svn fetch antes de poder ejecutar git svn dcommit nuevamente. Todas mis operaciones de cambio de nombre se encontraron en el repository SVN, pero los directorys que se dejaron vacíos después de la reproducción aleatoria no se eliminaron. Tuve que usar mi cliente SVN para eliminarlos. No estoy seguro de si esto es una cosa de git-svn o debido al time de espera de HTTPS durante esa llamada de compromiso.

Todavía no sé la respuesta a: ¿Es seguro interrumpir una llamada de compromiso?

Si, es seguro.

dcommit básicamente hace esto para cada compromiso que estás presionando a SVN:

  1. Calcule la diferencia entre el compromiso y su padre. (Esencialmente, crear un parche para la confirmación).
  2. Envíe esta diferencia sobre el protocolo SVN como un set de cambios que se comprometerá. Una vez que esto se complete, la confirmación ahora vive en el server SVN.
  3. Obtenga la nueva confirmación, y cualquier otra confirmación nueva que otros usuarios hayan creado mientras tanto, y almacénela localmente conforme se compromete correctamente Git. La reference de twig git-svn se actualizará para apuntar a la última.
  4. Rebase todas las confirmaciones posteriores a la que se acaba de procesar en la reference de la twig git-svn. (Dado que la confirmación que se procesa ahora debe vivir en el server, esto provocará que la confirmación local que acaba de procesarse se descarte, como en cualquier otra database).

Si interrumpe durante el paso 2 (que es lo que suena), la confirmación actual se cancelará en el server svn. Deberías poder comprometerte nuevamente sin preocupaciones.

Pero, si eres paranoico (y deberías estarlo al interoperar entre VCS como este) es posible que quieras ejecutar git svn rebase primero. Esto desplegará todas las confirmaciones nuevas en SVN (incluida la confirmación que intentó presionar, si realmente tuvo éxito en el lado del server) y volverá a establecer la base de su sucursal local sobre la misma.