Si je supprime un fichier dans Subversion, comment puis-je consulter son historique et son contenu? Si j'essaye de faire svn catousvn log sur un fichier inexistant, il se plaint que le fichier n'existe pas.
De plus, si je voulais ressusciter le fichier, dois-je svn addle récupérer?
(J'ai posé une question spécifiquement sur Subversion, mais j'aimerais aussi savoir comment Bazaar, Mercurial et Git gèrent ce cas également.)
Réponses:
Pour obtenir le journal d'un fichier supprimé, utilisez
svn log -r lastrevisionthefileexisted
Si vous souhaitez ressusciter le fichier et conserver son historique des versions, utilisez
svn copy url/of/file@lastrevisionthefileexisted -r lastrevisionthefileexisted path/to/workingcopy/file
Si vous voulez simplement que le contenu du fichier ne soit pas versionné (par exemple, pour une inspection rapide), utilisez
svn cat url/of/file@lastrevisionthefileexisted -r latrevisionthefileexisted > file
Dans tous les cas, n'utilisez PAS 'svn up' pour récupérer un fichier supprimé!
Lorsque vous souhaitez consulter d'anciens fichiers, vous devez vraiment connaître la différence entre:
svn cat http://server/svn/project/file -r 1234
et
svn cat http://server/svn/project/file@1234
La première version examine le chemin qui est maintenant disponible en tant que http: // serveur / svn / project / file et récupère ce fichier tel qu'il était dans la révision 1234. (Cette syntaxe ne fonctionne donc pas après une suppression de fichier).
La seconde syntaxe obtient le fichier qui était disponible http: // serveur / svn / projet / fichier dans la révision 1234. Donc cette syntaxe DOES travail sur les fichiers supprimés.
Vous pouvez même combiner ces méthodes pour récupérer un fichier qui était disponible dans la révision 2345 en tant que http: // server / svn / project / file mais avec le contenu comme il l'avait en 1234 avec:
svn cat http://server/svn/project/file@2345 -r 1234
./local/filelorsque le ./localrépertoire n'existait pas. Cela peut ne pas être un problème pour les versions plus récentes de SVN.
^notation est pratique: elle fait référence à la racine du référentiel, donc vous pouvez dire svn cat ^/local/file@REV(en fonction de la distance entre la racine du référentiel et l'URL).
svn: E200009: Could not cat all targets because some targets are directories
Tout d'abord, recherchez le numéro de révision où le fichier a été supprimé:
svn log -v > log.txt
Ensuite, regardez dans log.txt (pas un gourou SVN, donc je ne connais pas de meilleur moyen) pour une ligne avec
D <deleted file>
et voyez quelle révision c'était. Puis, comme dans les autres réponses, ressuscitez le fichier en utilisant la révision précédente.
Ce n'est rien de particulièrement spécial dans git. Si vous connaissez le nom du fichier, vous pouvez découvrir le changement qui l'a supprimé avec le journal:
git log -n 1 -- filename
Ensuite, vous pouvez utiliser cette validation pour obtenir le fichier tel qu'il existait avant la suppression.
git checkout [last_revision]^ filename
dhcp-120:/tmp/slosh 587% ls -l slosh.tac
ls: slosh.tac: No such file or directory
dhcp-120:/tmp/slosh 588% git log -n 1 -- slosh.tac
commit 8d4a1f1a94e4aa37c1cb9d329a140d08eec1b587
Author: Dustin Sallings <dustin@spy.net>
Date: Mon Dec 15 11:25:00 2008 -0800
Get rid of a .conf and replace it with .tac.
dhcp-120:/tmp/slosh 589% git checkout 8d4a1f^ slosh.tac
dhcp-120:/tmp/slosh 590% ll slosh.tac
-rw------- 1 dustin wheel 822 Dec 30 12:52 slosh.tac
Notez que cela ne remet pas réellement le fichier dans le contrôle de révision. Il dépose simplement le fichier tel qu'il existait dans son état final dans l'emplacement actuel. Vous pouvez ensuite l'ajouter ou simplement l'inspecter ou quoi que ce soit à partir de ce point.
Une solution utilisant uniquement l'interface graphique:
Si vous connaissez le nom du fichier, mais que vous ne connaissez pas son dernier numéro de révision ni même son chemin:
Cela affichera alors uniquement les révisions où le fichier a été ajouté / modifié / supprimé. Ceci est votre historique du fichier.
Notez que si le fichier a été supprimé en supprimant l'un de ses dossiers parents, il n'aura pas d'entrée «supprimé» dans le journal (et donc la solution de mjy ne fonctionnera pas). Dans ce cas, son entrée la plus récente dans le journal filtré correspondra à son contenu lors de la suppression.
svn log -v | grep -B50 YourDeletedFileName
Vous obtiendrez le chemin et la révision. Dans git (vérifie également les renommés):
git log --diff-filter=DR --name-only | grep -B50 YourDeletedFileName
En plus de la réponse de Dustin, si vous voulez juste examiner le contenu, et non le vérifier, dans son exemple, vous pouvez faire:
$ git show 8d4a1f^:slosh.tac
the: sépare une révision et un chemin dans cette révision, demandant effectivement un chemin spécifique à une révision spécifique.
Utilisez cette commande:
svn log -v | awk '/^r[0-9]+/ { rev = $1; }; / D .*filename_escaped_for_regex/ { print rev" "$2; };'
Cela listera toutes les révisions qui ont supprimé tous les fichiers correspondant au modèle. C'est, si vous êtes à la recherche de fichier README, puis tous /src/README, /src/README.firstet /some/deeply/hidden/directory/READMENOTseront trouvés et répertoriés.
Si votre nom de fichier contient des barres obliques (chemin), des points ou d'autres caractères spéciaux de regex, n'oubliez pas de les échapper pour éviter les incohérences ou les erreurs.
Si vous ne connaissez pas le chemin d'accès au fichier supprimé, il s'avère que vous pouvez le rechercher dans la commande autrement trop lourde svn log:
svn log --search <deleted_file_or_pattern> -v
La commande martèle probablement le serveur autant qu'elle le ferait sans l'option de recherche, mais au moins le reste des ressources impliquées (y compris vos globes oculaires) serait un peu soulagé, car cela vous dira dans quelle révision ce fichier a été supprimé. Ensuite, vous pouvez suivre les autres astuces (principalement en utilisant la même svn logcommande, mais déjà sur un chemin défini).
svn log --search _test2.php -v... svn: option invalide: --search ... :(
L'affiche a en fait posé 3 questions ici:
Toutes les réponses que je vois ici concernent les questions 2 et 3.
La réponse à la question 1 est:
svn log http://server/svn/project/file@1234
Vous devez toujours obtenir le numéro de révision de la date à laquelle le fichier a existé pour la dernière fois, qui est clairement répondu par d'autres ici.
Ah, depuis que j'apprends à utiliser Bazaar, c'est quelque chose que j'ai essayé. Sans succès, il semble que vous ne pouvez pas enregistrer et annoter les fichiers supprimés actuellement ... :-(
A essayé:
> bzr log -r 3 Stuff/ErrorParser.hta
bzr: ERROR: Path does not have any revision history: Stuff/ErrorParser.hta
mais curieusement (et heureusement) je peux faire:
> bzr cat -r 3 Stuff/ErrorParser.hta
et:
> bzr diff -r 2..3 Stuff/ErrorParser.hta
et comme suggéré dans le bogue ci-dessus:
> bzr log -v | grep -B 1 ErrorParser
(ajustez le paramètre -B( --before-context) si nécessaire).
Vous devrez spécifier une révision.
svn log -r <revision> <deleted file>
Si vous souhaitez consulter l'historique d'un fichier avant qu'il ne soit renommé, comme mentionné dans un commentaire ici, vous pouvez utiliser
git log --follow -- current_file_name
Je voulais une réponse, moi-même. Essayez ce qui suit pour ne sortir que les suppressions de svn log.
svn log --stop-on-copy --verbose [--limit <limit>] <repo Url> | \
awk '{ if ($0 ~ /^r[0-9]+/) rev = $0 }
{ if ($0 ~ /^ D /) { if (rev != "") { print rev; rev = "" }; print $0 } }'
Cela filtre la sortie du journal via awk . awk met en mémoire tampon chaque ligne de révision qu'il trouve, ne la sortant que lorsqu'un enregistrement de suppression est trouvé. Chaque révision n'est sortie qu'une seule fois, donc plusieurs suppressions dans une révision sont regroupées (comme dans la normesvn log sortie ).
Vous pouvez spécifier a --limitpour réduire le nombre d'enregistrements renvoyés. Vous pouvez également supprimer le--stop-on-copy , si nécessaire.
Je sais qu'il y a des plaintes concernant l'efficacité de l'analyse de l'ensemble du journal. Je pense que c'est une meilleure solution que grep et son -Boption "cast a wide net" . Je ne sais pas si c'est plus efficace, mais je ne peux pas penser à une alternative svn log. C'est similaire à la réponse de @Alexander Amelkin, mais n'a pas besoin d'un nom spécifique. C'est aussi mon premier script awk , donc ce n'est peut-être pas conventionnel.
Supposons que votre fichier a été nommé comme ~ / src / a / b / c / supprimé.fichier
cd ~/src/a/b/c # to the directory where you do the svn rm or svn mv command
#cd ~/src # if you forget the correct directory, just to the root of repository
svn log -v | grep -w -B 9 deleted.file | head # head show first 10 lines
exemple de sortie, trouvé à r90440
...
r90440 | user | 2017-02-03 11:55:09 +0800 (Fri, 03 Feb 2017) | 4 lines
Changed paths:
M /src/a/b/c/foo
M /src/a/b/c/bar
D /src/a/b/c/deleted.file
recopiez-le vers la version précédente (90439 = 90440-1)
svn cp URL_of_deleted.file@90439 .
Vous pouvez trouver la dernière révision qui fournit le fichier en utilisant la recherche binaire. J'ai créé un /bin/bashscript simple pour cela:
function svnFindLast(){
# The URL of the file to be found
local URL="$1"
# The SVN revision number which the file appears in (any rev where the file DOES exist)
local r="$2"
local R
for i in $(seq 1 "${#URL}")
do
echo "checkingURL:'${URL:0:$i}'" >&2
R="$(svn info --show-item revision "${URL:0:$i}" 2>/dev/null)"
echo "R=$R" >&2
[ -z "$R" ] || break
done
[ "$R" ] || {
echo "It seems '$URL' is not in a valid SVN repository!" >&2
return -1
}
while [ "$r" -ne "$R" -a "$(($r + 1))" -ne "$R" ]
do
T="$(($(($R + $r)) / 2))"
if svn log "${URL}@${T}" >/dev/null 2>&1
then
r="$T"
echo "r=$r" >&2
else
R="$T"
echo "R=$R" >&2
fi
done
echo "$r"
}
J'ai écrit un script php qui copie le journal svn de tous mes référentiels dans une base de données mysql. Je peux maintenant faire des recherches en texte intégral sur mes commentaires ou noms de fichiers.