Je travaille avec un autre développeur dans la même copie de travail (je sais que c'est une mauvaise idée), nous nous sommes habituellement mis à jour de fichiers individuels, et nous avons maintenant des fichiers dans une révision et d'autres personnes dans une autre. Comment puis-je voir une liste de fichiers avec leurs numéros de révision respectives? (La copie de travail est dans une boîte Linux et nous utilisons la ligne de commande SVN.
Merci d'avance pour toute aide
6 Réponses :
Essayez ceci dans votre copie de travail ou pour voir tous les fichiers et répertoires de récursivement Vous pouvez taper svn help info pour voir d'autres options
Oui, mais je cherche les versions de tous les sous-répertoires et fichiers récursives. Cela ne me montre que les versions des fichiers du répertoire parent.
Le La commande svnversion peut être Ce dont vous avez besoin, car il montrera la gamme de révisions de la copie de travail.
@Jonathonreinhart - Cet article indique une réponse. Bien qu'il contienne également un lien, le lien n'est pas nécessaire pour que la réponse soit valide. Le puzzle clé ici consiste à savoir quelle commande utiliser, et cela fournit cette information de manière autonome.
@Chrisstratton a accepté. J'étais un peu trop zélé sur la revue.
Enfin, j'ai utilisé une solution combinée à l'aide de la commande postée par Dmitry Yudakov et un script limitatif dans JS-Rhino. Maintenant, je peux trouver tous les fichiers avec un numéro de révision différent de faire quelque chose comme:
svn info -r>
TMP_Info Rhino Read-Svn.Js | grep -v 295
Même programme en PHP:
svn info -r> tmp_info && php versions.php
Qui signifie produit de sortie comme ceci: svn info -r. | Egrep "^ Path: | ^ Révision:" | Coller - -
svn -R list --verbose It will give output like this 109 authorname 3818 Nov 20 2012 JSON/xyz.json
Je suis désolé d'avoir fait cela, mais je ne peux pas m'empêcher de demander: Si vous savez que c'est une mauvaise idée, pourquoi faites-vous cela?
Le problème se produit dans une copie de travail qui est le dossier de production où Apache est exécutée. Parfois, lorsque nous devons résoudre rapidement un bug, nous utilisons directement cette copie de travail.
C'est une idée terrible. Vous êtes tout aussi susceptible de créer des problèmes rapidement car vous devez les réparer rapidement.