2008-12-12 8 views
1

Cet après-midi, en notant une compilation cassée et le fait que certains fichiers ressemblaient à des versions très anciennes (environ 2 semaines), j'ai vérifié le journal svn. Apparemment, juste cet après-midi, 1 des développeurs a fait une "copie svn" d'un répertoire d'une ancienne révision vers le même répertoire. Ainsi, il semble que la dernière version "i.e. head" de tous les fichiers de ce répertoire est vraiment ancienne, et tout l'historique "i.e. log" est encore plus ancien. Cependant, je pense que je peux récupérer en utilisant un autre "svn copy" (c'est-à-dire que la maladie est la guérison). Ce que j'envisage de faire est de trouver la révision où la mauvaise « copie svn » a été fait (par exemple rev 1234), en soustrayant 1 (1233) et de faire:Récupérer à partir d'un malheureux "svn copy"

svn copy -r 1233 file://path/to/messed/up/dir file://path/to/messed/up/dir 

Ce devrait restaurer la dernière version, ainsi comme récupérer toute mon histoire. Ai-je raison à ce sujet?

Répondre

7

Selon the SVN book,

svn merge -c -1234 

devrait faire l'affaire.

Il ya un ensemble section à ce sujet dans le livre.

L'explication prolixe: -c -1234 se traduit -r 1234:1233, qui reprend le changement de la révision 1234.

-2

Probablement, mais faites d'abord une sauvegarde.

En fait, je me demande pourquoi vous n'avez pas une sauvegarde quotidienne que vous pouvez restaurer depuis ... Votre dépôt SVN est certainement assez important pour cela?

+0

En théorie, le dépôt SVN lui-même est la sauvegarde des choses comme ça. La sauvegarde de votre référentiel lui-même ne doit être due qu'à des désastres «externes» (matériel, rm -rf *, inondations, etc.). –

+0

Je dirais qu'une explosion de l'arborescence source actuelle (plus d'autres bêtises ignorées qui ont été commises en même temps) est au même niveau qu'un désastre de type rm -rf. Le référentiel est actuellement dans un état inconnu. Le but d'une sauvegarde est de renvoyer un système à un état de travail connu. – TheSmurf

+1

Je sais qu'il s'agit d'un thread fossile, mais voici quelques raisons pour lesquelles vous ne voulez pas restaurer le référentiel à partir d'une sauvegarde dans un cas comme celui-ci. 1) le repo n'est pas corrompu, l'utilisateur lui a simplement demandé de faire quelque chose qu'il n'avait pas l'intention de faire 2) d'autres développeurs dans d'autres parties du repo pourraient avoir commis de bonnes choses, et vous ne voulez pas jeter leur travail 3) le code désiré peut être avancé sans problème, parce que vous pouvez toujours le faire avec subversion 4) il crée une ambiguïté avec mauvais [1234] et post-restauration bon [1234]. Je suis avec Brian. –

1

Cette commande de copie ne fonctionne pas pour deux raisons:

  1. que le répertoire cible existe déjà, svn traite la demande de copie de copie dans le répertoire cible; vous ne pouvez pas écraser avec cp. Donc, cela créerait/dir/dir. Lorsque la version HEAD de dir a été créée, il doit y avoir eu une opération de suppression en premier.
  2. il s'agit d'une demande de copie de la version 1233 de l'objet HEAD sous/dir.Cependant, l'objet dir dans HEAD n'a pas de révision 1233; l'objet avec le même chemin qui a eu une telle révision a été supprimé.

Pour résoudre ce problème, vous devez

  1. supprimer l'objet courant dir:

    svn rm file:///path/to/messed/up/dir 
    
  2. Copie à l'aide "révisions peg"

    svn cp file:///path/to/messed/up/[email protected] file:///path/to/messed/up 
    
Questions connexes