obtenir un ensemble de fichiers qui ont été modifiés après une certaine date

Question

Quelqu'un at-il un script powershell pratique que obtient un ensemble de fichiers de TFS basé sur une date de modification? Je voudrais dire "donnez-moi tous les fichiers dans ce dossier (ou sous-dossier) qui ont été modifiés après X/Y/ZZZZ" et vider ces fichiers dans un dossier autre que celui dans lequel ils iraient normalement. Je connais suffisamment de pouvoirs pour pirater et finir, finalement, mais j'espère éviter cela.

Answer 1

Assurez-vous que le Team Foundation 2015 Power Tools est installé. Il est livré avec un snapin PowerShell. Vous pouvez exécuter le fichier de la console PowerShell directement à partir de son groupe de démarrage ou vous pouvez exécuter Add-PSSnapin Microsoft.TeamFoundation.PowerShell. Puis cd à votre espace de travail et exécuter:

Get-TfsItemProperty . -r | Where {$_.CheckinDate -gt (Get-Date).AddDays(-30)} | 
    Format-Table CheckinDate,TargetServerItem -auto 

CheckinDate   TargetServerItem 
-----------   ---------------- 
9/14/2009 1:29:23 PM $/Foo/Trunk/Bar.sln        
9/29/2009 5:08:26 PM $/Foo/Trunk/Baz.sln  

Pour Dump informations à un répertoire:

Get-TfsItemProperty . -r | Where {$_.CheckinDate -gt (Get-Date).AddDays(-30)} | 
    Select TargetServerItem > c:\recentlyChangedFiles.txt 

Pour copier ces fichiers vers un autre répertoire (ceci suppose que les tiré vers le bas localement dans un workfolder) :

Get-TfsItemProperty . -r | Where {$_.CheckinDate -gt (Get-Date).AddDays(-30)} | 
    CopyItem -Path $_.LocalItem -Destination C:\SomeDir -Whatif 

Notez que cela copie les fichiers dans une structure de dossiers plats. Si vous voulez maintenir la structure dir, c'est un peu plus compliqué.

Answer 2

L'utilisation de Get-TfsItemProperty comme Keith ne nécessite pas seulement un espace de travail pour les copies de fichiers. C'est l'encapsuleur de GetExtendedItems(), la requête du serveur pour les informations locales les plus souvent vues dans Source Control Explorer. En s'appuyant sur les informations de version qu'il rapporte, vous supposez que les fichiers eux-mêmes ont été téléchargés (plus généralement: synchronisé, dans le cas de renames & supprimés) au cours des 30 derniers jours. Si l'espace de travail n'est pas à jour, certains fichiers vous manqueront/leur donneront des noms périmés/etc. Il est également assez cher en tant que commandes d'information.

Quelques autres exemples:

# 1 
Get-TfsChildItem $/FilesYouWant -R | 
    ? { $_.CheckinDate -gt (Get-Date).AddDays(-30) } | 
    % { $_.DownloadFile(join-path C:\SomeDir (split-path $_.ServerItem -leaf)) } 

# 2 
Get-TfsItemHistory $/FilesYouWant -R -All -Version "D$((Get-Date).AddDays(-30).ToString('d'))~" | 
    Select-TfsItem | 
    Select -Unique -Expand Path | 
    Sort | 
    Out-File c:\RecentlyChanged.txt 

La première est une adaptation directe du code de Keith, en utilisant une requête moins cher et en éliminant la dépendance de l'espace de travail. C'est la meilleure option si vous savez qu'un pourcentage élevé des éléments de ce répertoire ont été modifiés récemment.

La deuxième option interroge directement l'historique des modifications. En laissant la clause Where être calculée en SQL plutôt que sur le client, cela peut être d'un ordre de grandeur plus efficace si un faible pourcentage d'éléments a été modifié récemment (comme c'est souvent le cas). Cependant, il retardera les requêtes basées sur les éléments s'il y a beaucoup de grands changesets retournés, ce qui rend le JOIN du serveur pour récupérer les propriétés de l'objet et forcer notre suppression des doublons côté client à faire beaucoup de travail.

[Oui, je sais que -Version nécessite une chaîne n'est pas très Powershell-esque; mea culpa. Vous pouvez créer un DateVersionSpec avec new-object et appelez son ToString(), mais c'est encore plus de travail.]

Je n'ai pas montré toutes les combinaisons d'appel API + tâche souhaitée. Va sans dire que vous pouvez utiliser # 1 pour générer la liste des fichiers et # 2 pour (re) télécharger en modifiant la dernière moitié du pipeline. Vous pouvez même combiner cette technique de copie avec l'efficacité de Get-TfsItemHistory:

# 2b, with local-to-local copying 
Get-TfsItemHistory $/FilesYouWant -R -All -Version "D$((Get-Date).AddDays(-30).ToString('d'))~" | 
    Select-TfsItem | 
    Select -Unique -Expand Path | 
    Get-TfsItemProperty | 
    Copy $_.LocalItem -Dest C:\SomeDir 

Il est vrai cela fait un 2ème aller-retour au serveur, mais grâce à la requête initiale l'appel GetExtendedItems() sera portée définie à la précision ensemble d'articles qui nous intéressent.Et bien sûr, nous supprimons toute chance que le temps de téléchargement devienne le goulot d'étranglement. C'est probablement la meilleure solution lorsque le nombre de changesets est petit et que les préoccupations que j'ai soulevées à propos de la synchronisation de l'espace de travail de Keith ne sont pas pertinentes pour une raison quelconque. Est-ce que je peux juste dire qu'ayant à user PowerShell pour faire ceci semble absurde. FWIW, J'ai été impliqué avec TFS à l'intérieur de & en dehors de MS pour 4.5yr et jamais vu cette fonctionnalité demandée. Si vous pouviez vous étendre sur l'objectif que vous essayez d'atteindre, je suppose que nous pourrions vous suggérer un meilleur moyen. Ne vous méprenez pas, j'ai écrit les extensions Powershell précisément pour gérer des scénarios bizarres comme celui-ci. Mais souvent, c'est un travail pour un autre outil entièrement, par exemple: Annoter, MSBuild, comparer le schéma DB ...