¿Cuál es la mejor práctica de Subversion para recolectar copys de trabajo no válidas luego de la restauración de una copy de respaldo del repository anterior?

Tengo algunas preguntas sobre cómo restaurar una copy de security de un repository antiguo de Subversion.

Supongamos que hay varias copys de trabajo (wc) basadas en una revisión en un determinado repository (repository). El repository podría estar en la revisión 100, por ejemplo, y las copys de trabajo BASEd en varias revisiones, digamos 80, 60, 40:

repo @100 wc-1 @80 wc-2 @60 wc-3 @40 

Supongamos ahora que hay un desastre, se pierde el repository y la copy de security válida más reciente está un poco vieja, por ejemplo, en la revisión 50. Esto se restablece, y la situación es ahora la siguiente:

 repo @50 wc-1 @80 X wc-2 @60 X wc-3 @40 ? 

Las copys de trabajo marcadas con 'X' ahora son obviamente inválidas. Su BASE no existe.

No es posible desactivar (es decir, actualizar hacia abajo) las copys de trabajo no válidas, ya que el delta requerido ya no existe en el repository. No sería deseable hacerlo en ningún caso, ya que tales copys de trabajo podrían ser la única fuente existente de las revisiones perdidas.

Además, supongamos que después de la restauración del repository, no hay ningún process implementado, y se permite que ocurra lo siguiente.

La copy de trabajo 3 aparentemente está bien. (Bueno, realmente está bien cuando se considera de forma aislada, pero tal vez no se debe tocar hasta que las cosas se hayan resuelto globalmente ).

Su propietario ahora se actualiza y comete varios sets de cambios, llevando la revisión HEAD del repository a 70. La situación es ahora la siguiente:

 repo @70 wc-1 @80 X wc-2 @60 X! wc-3 @70 ? 

La copy de trabajo 2 ahora está en un estado confuso. La revisión 60 de su BASE no es la misma que originalmente. Sin embargo, puede no ser obvio que no sea válido. Las aparentes diferencias entre esta copy de trabajo y el repository son una mezcla de cambios locales reales, de diferencias introducidas por la copy de trabajo 3 y diferencias que representan las revisiones perdidas. Es decir, es un desastre.

Entonces mis preguntas son las siguientes:

(1) ¿Qué tan bien se comporta SVN a este respecto? Específicamente, ¿cómo responderá SVN a los bashs de compromiso de wc-1? ¿Cómo responderá SVN a los bashs de compromiso de wc-2 (una vez que el repository HEAD esté más allá de la BASE de wc-2)? ¿Está esto documentado en algún lugar?

(2) ¿Existen procedimientos documentados de mejores prácticas para restaurar una copy de respaldo del repository SVN anterior, para identificar copys de trabajo no válidas, y para tratar de "cosechar" los cambios perdidos de las diversas copys de trabajo no válidas que existen?

(Presumiblemente, parte de la respuesta es que tan pronto como se haya recuperado un repository, todas las copys de trabajo no válidas se deben abandonar como copys de trabajo y sus cambios transferidos a nuevas cajas, y todas las copys de trabajo se deben dejar en espera hasta una recuperación plan está en su lugar.)

Gracias.

Tal vez me falta algo, pero no veo un problema aquí.

El usuario con copy de trabajo que está en la revisión 80 hace lo siguiente

  1. Deja intacta esta copy de trabajo (este es el wc "prístino")
  2. Comtesting una nueva copy de trabajo que está en una revisión inferior (por ejemplo, 50 o 70) (esto es clon wc)
  3. Copia manualmente todos los files desde el wc original hasta el clon wc
  4. Confirma todos los cambios desde el clon wc al repository "recuperado"

Todos los demás usuarios realizan el pago (una vez hecho esto) a un wc completamente nuevo. Todos los demás wc pueden descartarse (los anteriores al desastre).

Ahora todos están en la "revisión 80" (en realidad, 51 o 71), que es el mejor escenario posible, ya que esta fue la revisión más alta después del desastre.

El punto es que, independientemente de los numbers, todos obtienen la mejor / última versión de los files disponibles.

De esta forma, ni siquiera tiene que preocuparse de cómo "la subversión se comporta a este respecto"