Pobierz bieżący identyfikator zestawu zmian w obszarze roboczym dla TFS

Question 1

Jak dowiedzieć się, jaki zestaw zmian mam obecnie w moim lokalnym obszarze roboczym?

Jasne, mogę wybrać jeden plik i wyświetlić jego historię. Jeśli jednak ten plik nie był ostatnio aktualizowany, jego zestaw zmian jest prawdopodobnie starszy niż nowsze pliki w tym samym rozwiązaniu.

Jednym z możliwych błędów, które możemy popełnić, jest to, że przeglądamy historię w pliku rozwiązania, jednak plik rozwiązania rzadko się zmienia, chyba że dodajesz nowy projekt / wprowadzasz zmiany na poziomie rozwiązania.

Na koniec, aby rozgryźć zestaw zmian, muszę zapamiętać, jakie były ostatnie zmiany plików i przejrzeć ich historię.

Czy jest lepszy sposób na zrobienie tego?

Question 2

Twoja odpowiedź znajduje się na blogu MSDN autorstwa Bucka Hodgesa: Jak określić najnowszy zestaw zmian w obszarze roboczym

od katalogu głównego (u góry) obszaru roboczego, w cmd wykonaj:

tf history . /r /noprompt /stopafter:1 /version:W

Question 3

Typowa odpowiedź do tf.exe history . /rbezpośredniego użycia działa, ale może być strasznie powolna. W naszym przypadku zajmuje to 10-15 sekund. Teraz używam sprawdzania dwuetapowego, najpierw sprawdzam wersję niektórych dowolnych plików (używam plików w folderze głównym).

Z PowerShell:

$tfexepath = "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\tf.exe"
$localpath = "C:\some\tfs\directory"

$result = & $tfexepath history $localpath /noprompt /stopafter:1 /version:W 
"$result" -match "\d+" | out-null
$id = $matches[0]

Następnie wyszukaj od katalogu głównego, używając flagi / r, ale ogranicz wyszukiwanie do wersji znalezionej powyżej:

$result2 = & $tfexepath history $localpath /r /noprompt /stopafter:1 /version:$id~W        
"$result2" -match "\d+" | out-null
$id2 =  $matches[0]

#result:
Write-Host $id2

W przypadku naszego kodu skraca to całkowity czas z 10-15 do 1,4-1,5 sekundy.

O ile rozumiem, nie ma żadnych wad ani ograniczeń, ale przypuszczam, że w małym repozytorium mogłoby to działać wolniej. - Z przyjemnością się dowiem.

Question 4

Uruchom Visual Studio CMD (w moim przypadku VS2015 nazywa się: „Developer Command Promp for VS2015”), a następnie przejdź do folderu projektu i wykonaj następujące polecenie:

tf history . /r /noprompt /stopafter:1 /version:W

Question 5

Jeśli chcesz używać PowerShell ( zobacz także ; odpowiednik odpowiedzi @kroonwijk ):

włącz snapin tfs (raz, jeśli jeszcze nie)

add-pssnapin Microsoft.TeamFoundation.PowerShell
użyj polecenia cmdlet tfs, aby uzyskać bieżący identyfikator zestawu zmian

Get-TfsItemHistory <PATH_TO_PROJECT> -Recurse -Stopafter 1 -Version W

Question 6

Jeśli naprawdę nie masz pojęcia, jaką masz wersję, powinieneś użyć jednej z pozostałych sugerowanych metod. Jeśli po prostu nie jesteś pewien, czy masz określoną wersję lub nie masz pewności co do kilku zestawów zmian i wolisz pracować z interfejsem graficznym VS TFS, możesz wykonać następujące kroki:

Wybierz zbiór zmian, którego chcesz się upewnić i porównaj:
Jeśli nie masz różnicy:

lub, jeśli jedynymi różnymi plikami są pliki, w których masz oczekujące zmiany:

Oznacza to, że jesteś na bieżąco z daną wersją.

** Jeśli nie masz pewności, czy plik, który ma oczekującą zmianę, jest faktycznie nieaktualny, możesz sprawdzić tę wersję pliku za pomocą właściwości:

Answer 1

80

Jak dowiedzieć się, jaki zestaw zmian mam obecnie w moim lokalnym obszarze roboczym?

Jasne, mogę wybrać jeden plik i wyświetlić jego historię. Jeśli jednak ten plik nie był ostatnio aktualizowany, jego zestaw zmian jest prawdopodobnie starszy niż nowsze pliki w tym samym rozwiązaniu.

Jednym z możliwych błędów, które możemy popełnić, jest to, że przeglądamy historię w pliku rozwiązania, jednak plik rozwiązania rzadko się zmienia, chyba że dodajesz nowy projekt / wprowadzasz zmiany na poziomie rozwiązania.

Na koniec, aby rozgryźć zestaw zmian, muszę zapamiętać, jakie były ostatnie zmiany plików i przejrzeć ich historię.

Czy jest lepszy sposób na zrobienie tego?

tfs Boyan
źródło

Dlaczego chcesz poznać swój obecny zestaw zmian?

Ewald Hofman

Co się dzieje, gdy Twój obszar roboczy nie jest reprezentatywny dla zestawu zmian? Weź pod uwagę, że $/Azmapowałeś i pobrałeś zestaw zmian A, $/Bzmapowałeś i pobrałeś zestaw zmian B. W jakim zestawie zmian znajduje się twój obszar roboczy?

Edward Thomson

8

@Ewald Rozważ cofnięcie się w czasie, aby dowiedzieć się, kiedy zaczął się pojawiać błąd. Może to wymagać wielokrotnego wykonywania operacji „Pobierz określoną wersję” w obszarze roboczym, aby dostać się do poprzednich zestawów zmian, co może być bardzo żmudne, długie i podatne na błędy. Możliwość określenia, który dokładny zestaw zmian znajduje się obecnie w obszarze roboczym, jest niezwykle przydatna w celu uniknięcia błędów rozpraszających i potwierdzenia sprawcy. Cieszę się, że dziś znalazłem to polecenie.

Louis

1

Pochwalam to pytanie!

Fernando Espinosa

Witamy za 5+ lat. Aby odpowiedzieć na pytanie @ EwaldHofman, w moim scenariuszu dokonałem kilku zmian w moim obszarze roboczym i chcę zobaczyć, co zmieniło się na serwerze od czasu ostatniego „get”. W moim przypadku nie wiem, jaką ostatnio „dostałem” wersję.

JMD

Answer 2

Dlaczego chcesz poznać swój obecny zestaw zmian?

Ewald Hofman

Answer 3

Co się dzieje, gdy Twój obszar roboczy nie jest reprezentatywny dla zestawu zmian? Weź pod uwagę, że $/Azmapowałeś i pobrałeś zestaw zmian A, $/Bzmapowałeś i pobrałeś zestaw zmian B. W jakim zestawie zmian znajduje się twój obszar roboczy?

Edward Thomson

Answer 4

8

@Ewald Rozważ cofnięcie się w czasie, aby dowiedzieć się, kiedy zaczął się pojawiać błąd. Może to wymagać wielokrotnego wykonywania operacji „Pobierz określoną wersję” w obszarze roboczym, aby dostać się do poprzednich zestawów zmian, co może być bardzo żmudne, długie i podatne na błędy. Możliwość określenia, który dokładny zestaw zmian znajduje się obecnie w obszarze roboczym, jest niezwykle przydatna w celu uniknięcia błędów rozpraszających i potwierdzenia sprawcy. Cieszę się, że dziś znalazłem to polecenie.

Louis

Answer 5

1

Pochwalam to pytanie!

Fernando Espinosa

Answer 6

Witamy za 5+ lat. Aby odpowiedzieć na pytanie @ EwaldHofman, w moim scenariuszu dokonałem kilku zmian w moim obszarze roboczym i chcę zobaczyć, co zmieniło się na serwerze od czasu ostatniego „get”. W moim przypadku nie wiem, jaką ostatnio „dostałem” wersję.

JMD

Answer 7

Twoja odpowiedź znajduje się na blogu MSDN autorstwa Bucka Hodgesa: Jak określić najnowszy zestaw zmian w obszarze roboczym

od katalogu głównego (u góry) obszaru roboczego, w cmd wykonaj:

tf history . /r /noprompt /stopafter:1 /version:W

Answer 8

Typowa odpowiedź do tf.exe history . /rbezpośredniego użycia działa, ale może być strasznie powolna. W naszym przypadku zajmuje to 10-15 sekund. Teraz używam sprawdzania dwuetapowego, najpierw sprawdzam wersję niektórych dowolnych plików (używam plików w folderze głównym).

Z PowerShell:

$tfexepath = "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\tf.exe"
$localpath = "C:\some\tfs\directory"

$result = & $tfexepath history $localpath /noprompt /stopafter:1 /version:W 
"$result" -match "\d+" | out-null
$id = $matches[0]

Następnie wyszukaj od katalogu głównego, używając flagi / r, ale ogranicz wyszukiwanie do wersji znalezionej powyżej:

$result2 = & $tfexepath history $localpath /r /noprompt /stopafter:1 /version:$id~W        
"$result2" -match "\d+" | out-null
$id2 =  $matches[0]

#result:
Write-Host $id2

W przypadku naszego kodu skraca to całkowity czas z 10-15 do 1,4-1,5 sekundy.

O ile rozumiem, nie ma żadnych wad ani ograniczeń, ale przypuszczam, że w małym repozytorium mogłoby to działać wolniej. - Z przyjemnością się dowiem.

Answer 9

1

Doskonała alternatywa. Skróciłem mój czas działania z 55 do 1,5 sekundy. Dzięki!

bobroxsox

Answer 10

1

.... z perspektywy czasu - zdumiony, że mogę żyć z msvc i cieszę się, że to rzecz, z którą miałem do czynienia tylko w przeszłości.

Johan Lundberg

Answer 11

3

Uruchom Visual Studio CMD (w moim przypadku VS2015 nazywa się: „Developer Command Promp for VS2015”), a następnie przejdź do folderu projektu i wykonaj następujące polecenie:

tf history . /r /noprompt /stopafter:1 /version:W

xero399
źródło

2

Dziękuję Ci! Bez tej odpowiedzi nadal zastanawiałbym się, dlaczego polecenie nie działa w panelu „okno poleceń” w programie Visual Studio.

ojdo

Answer 12

2

Dziękuję Ci! Bez tej odpowiedzi nadal zastanawiałbym się, dlaczego polecenie nie działa w panelu „okno poleceń” w programie Visual Studio.

ojdo

Answer 13

Jeśli chcesz używać PowerShell ( zobacz także ; odpowiednik odpowiedzi @kroonwijk ):

włącz snapin tfs (raz, jeśli jeszcze nie)

add-pssnapin Microsoft.TeamFoundation.PowerShell
użyj polecenia cmdlet tfs, aby uzyskać bieżący identyfikator zestawu zmian

Get-TfsItemHistory <PATH_TO_PROJECT> -Recurse -Stopafter 1 -Version W

Answer 14

Jeśli naprawdę nie masz pojęcia, jaką masz wersję, powinieneś użyć jednej z pozostałych sugerowanych metod. Jeśli po prostu nie jesteś pewien, czy masz określoną wersję lub nie masz pewności co do kilku zestawów zmian i wolisz pracować z interfejsem graficznym VS TFS, możesz wykonać następujące kroki:

Wybierz zbiór zmian, którego chcesz się upewnić i porównaj:
Jeśli nie masz różnicy:

lub, jeśli jedynymi różnymi plikami są pliki, w których masz oczekujące zmiany:

Oznacza to, że jesteś na bieżąco z daną wersją.

** Jeśli nie masz pewności, czy plik, który ma oczekującą zmianę, jest faktycznie nieaktualny, możesz sprawdzić tę wersję pliku za pomocą właściwości:

Pobierz bieżący identyfikator zestawu zmian w obszarze roboczym dla TFS

Odpowiedzi: