Visual Studio TFS wyświetla niezmienione pliki na liście oczekujących zmian

94

Widzę plik w oknie oczekujących zmian. Próbuję porównać go z najnowszą wersją i pojawia się komunikat „Pliki są identyczne” Jeśli pliki są identyczne, dlaczego ten plik pojawia się w oknie oczekujących zmian? Co się zmieniło w tym pliku? Czy mogę skonfigurować program TFS, aby nie wyświetlał plików, które są identyczne?

visual-studio-2010 tfs

— deweloper
źródło

Być może Twój program antywirusowy aktualizuje datę ostatniej modyfikacji plików? Albo pracujesz na zaszyfrowanym laptopie?

— DOK

ScottGu wyjaśnia, w jaki sposób program antywirusowy może zmienić te daty, można znaleźć w tym artykule (wyszukaj hasło „wirus”) weblogs.asp.net/scottgu/archive/2006/09/22/…

— DOK

58

To musi być jedna z najbardziej irytujących "funkcji" TFS

— Brad Thomas,

Też mam ten problem - TF działa, ale TFPT nie - myślę, że to dlatego, że używam "TFPT - Team Foundation Power Tools 2012" z obszarem roboczym Visual Studio 2010 ...: - /

— BrainSlugs83

Wygląda na to, że wszystko, co musiałem zrobić, to połączyć się z tą samą kolekcją w programie Visual Studio 2012. Więcej informacji można znaleźć w tym poście: stackoverflow.com/questions/1758606/ ...

— BrainSlugs83

49

Jest to normalne, jeśli plik zostanie automatycznie wypisany z powodu zmiany i jeśli ostatecznie zawartość pliku zostanie zmieniona z powrotem do pierwotnego stanu. W tym momencie po porównaniu zobaczysz komunikat o identycznej zawartości.

Ten wpis na blogu opisuje niezbyt intuicyjny sposób radzenia sobie z tym; aw komentarzach jest jeszcze lepsza sugestia, jak sobie z tym poradzić za pomocą wiersza poleceń za pośrednictwem narzędzi TFS.

Oczekujące zmiany TFS ignorujące identyczne pliki ...

— enablor
źródło

12

Zdecydowanie zalecam używanie tfpt uuelektronarzędzia, a nie hackerskiego rozwiązania „Nie dla wszystkich”. Ten monit jest wyświetlany tylko po dodaniu i zmodyfikowaniu zmian. Na przykład: zmiany nazw (które są tylko oczekującą zmianą nazwy, a nie zmianą nazwy i edycją) zostaną cofnięte przez interfejs użytkownika bez pytania.

— Edward Thomson

8

W przypadku, gdy oryginalny post na blogu kiedykolwiek zniknie, polecenie to tfpt uu /noget /r *, które musi zostać wykonane z katalogu głównego gałęzi. Mówiąc to, mimo że poprawnie wychwytuje zbędne zmiany, a następnie twierdzi, że je cofnął, nadal widzę je jako wyrejestrowane w VS i w oknie dialogowym Check In, więc wydaje mi się, że jest zepsuty: /

— Mike Chamberlain

2

Inną możliwością jest przełączenie bitu „tylko do odczytu” pliku bez faktycznej zmiany jego zawartości. TFS może być czasami denerwujące.

— arviman

1

Dla porównania, rozwiązanie „Nie dla wszystkich” jest kopiowane tutaj z linku: „Inną opcją jest„ Cofnij pobranie ”wszystkich zmian i kliknięcie„ Nie dla wszystkich ”po wyświetleniu monitu o potwierdzenie cofnięcia pobrania. W ten sposób program Visual Studio „Cofnij pobranie” wszystkie pliki, które nie zostały zmienione, a wszystkie zmienione pliki pozostaną wyewidencjonowane. Zawsze używam tej metody. ”

— PJSimon

Ta sztuczka „Nie dla wszystkich” jest fajna, ale ma kilka wad. Na przykład - używam mojego narzędzia do generowania klas DB EntityFramework. Generuję je w zewnętrznym katalogu, a następnie po prostu przeciągam je do mojego rozwiązania. Czasami, gdy nie ma żadnych zmian, nadal wyświetla zmiany. Ta sztuczka „Nie dla wszystkich” usuwa je. Ale jeśli są dodane nowe klasy, których wcześniej nie było, usuwa je z kontroli źródła - muszę dodać je z powrotem ręcznie.

— Wish

17

Niedawno właśnie zaktualizowałem VS2010 do VS 2013, a ten problem jest jeszcze gorszy. Podczas porównywania pliki, które są identyczne, w ogóle się nie pojawiają. Nienawidzę tego, ponieważ nie mogłeś dowiedzieć się, które pliki są naprawdę zmienione, dopóki nie sprawdzisz dokładnie plików porównawczych.

Wreszcie znalazłem obejście tego problemu:
Dodaj „Cofnij niezmienione wyrejestrowanie” w narzędziach zewnętrznych:

Komenda: tfpt.exe
Argumenty: uu . /noget /recursive
Katalog początkowy: $(SolutionDir)

Po uruchomieniu tego polecenia TFS automatycznie cofnie wszystkie nadmiarowe zmiany w plikach.
Ale te pliki nadal zachowują status wyewidencjonowania, w rzeczywistości są już cofnięte i takie same jak najnowsza wersja. Myślę, że to błąd w TFS. Wystarczy kliknąć ikonę Odśwież na pasku narzędzi pod eksploratorem rozwiązań, pliki te zostaną odświeżone i pokażą prawidłowy stan!

— zmaggie
źródło

2

Uruchomiłem "tfpt uu. / Noget / recursive" i twierdzi, że nie ma żadnych zbędnych oczekujących zmian w obszarze roboczym. VS2015, TFPT 2015. Wszystkie moje zmiany są puste [scal] zmiany.

— fastmultiplication

Próbowałem tego bez powodzenia. Usuwanie punktu argument wydaje się, aby to działało poprawnie: uu / noget / rekurencyjne

— dperez

10

Aby powyższe wyjaśnienie było jaśniejsze:

Zainstaluj narzędzia TFS Power Tools za pomocą menedżera pakietów NuGet w programie VS.
Otwórz wiersz polecenia programu Visual Studio (nazywany również wierszem polecenia dewelopera dla programu VS 2013/2015) z poziomu Start systemu Windows.
Przejdź do głównej lokalizacji lokalnego obszaru roboczego za pomocą wiersza polecenia.
Wykonaj to polecenie: tfpt uu. / recursive / noget
Wybierz odrzucenie zbędnych zmian, jeśli zostanie wyświetlony monit.

Pracował dla mnie.

Dalej:

Czasami stwierdzałem, że muszę uruchomić polecenie w wierszu otwierającym wiersza polecenia dewelopera (i pojawia się błąd nie znaleziono obszaru roboczego), przed przejściem do folderu obszaru roboczego i wykonaniem w nim. Jeśli przejdę bezpośrednio do właściwego folderu, polecenie nie zostanie znalezione. (Nie miałbym nic przeciwko samemu rozwiązaniu tego problemu).

— Phil
źródło

Dziękuję od 30 listopada 2015 r. Ciągle otrzymuję ten sam problem, a Twoja odpowiedź była doskonała. Próbowałem głosować wyżej, ale dostałem jakiś błąd „czasoprzestrzennego kontinuum”. Coś związanego z 30 listopada 1955 r. I „nie znaleziono wymaganego 1,21 gigawata”.

— Phil

Niestety nie działa dla mnie. Unable to determine the workspace. Próbowałem już zaktualizować pamięć podręczną obszaru roboczego, bez powodzenia. Po 2 godzinach po prostu się poddaję i sprawdzę niezmienione pliki, żeby się ich pozbyć.

— C4d

@ C4u Być może sam zacząłem go doświadczać od czasu przejścia na VS 2015. Jednak problem z wyewidencjonowanymi plikami zniknął. Zobaczę, czego się dowiem.

— Phil,

1

Nie udało mi się znaleźć narzędzi PowerTools przy użyciu NuGet, ale udało mi się znaleźć i zainstalować je za pomocą wyszukiwarki Google „Microsoft Visual Studio Team Foundation Server 2013 Power Tools”

— Colin

@Versatile Patrząc na Visual Studio 2017, należałoby przejść do „Narzędzia”> „Rozszerzenia i aktualizacje ...” Nie pamiętam struktury menu w 2013/15. Może moja odpowiedź wymaga korekty. Jeśli masz VS 2013/15 i możesz sprawdzić strukturę menu, zapraszam do edycji mojej odpowiedzi. :)

— Phil

1

Rozwiązałem to, klikając Stage Allprzycisk w Zmianach, a następnie usuwając je z etapu Unstage All.

Rozwiązało to niezmieniony plik, który miałem w mojej Changessekcji. Ładnie i prosto.

— Tom „Blue” Piddock
źródło

0

W programie Visual Studio 2012 wprowadzono nową koncepcję o nazwie Lokalny obszar roboczy .

Gdy lokalizacja obszaru roboczego jest skonfigurowana jako lokalna, umieszcza lokalną kopię oryginalnego pliku (podobnie jak SVN / CVS).

Następnie automatycznie ukryje niezmienione pliki przed oczekującymi zmianami.

Użyj Eksploratora kontroli źródła TFS, aby „edytować ...” obszar roboczy TFS i zmienić ustawienie „Zaawansowane ...” z lokalizacji Serwer na Lokalną.

— Rolf Kristensen
źródło

Mój obszar roboczy jest lokalny, ale nieuszkodzone pliki nadal pojawiają się w oczekujących zmianach ... To nie

— cofa

0

Dla mnie uzgodnienie obszaru roboczego rozwiązuje te nieprawidłowe oczekujące zmiany:

Team Explorer -> Builds
Kliknij prawym przyciskiem myszy najnowszą kompilację ze zmianami -> „Uzgodnij obszar roboczy ...”

— AnonyMouse
źródło