Udostępnij przez


Dodatkowe wytyczne dotyczące kontroli źródła dla projektów i edytorów

Istnieje wiele wytycznych, do których projekty i edytorzy powinni się stosować, aby wspierać kontrolę wersji.

Guidelines

Projekt lub edytor powinien również wykonać następujące czynności, aby obsługiwać kontrolę źródła:

Area Projekt Editor Szczegóły
Prywatne kopie plików X Środowisko obsługuje prywatne kopie plików. Oznacza to, że każda osoba wymieniona w projekcie ma własną prywatną kopię plików w tym projekcie.
Trwałość ANSI/Unicode X X Jeśli piszesz kod zarządzania trwałością, zapisuj pliki w formacie ANSI, ponieważ większość systemów kontroli wersji nie obsługuje obecnie formatu Unicode.
Wyliczanie plików X Projekt musi zawierać określoną listę wszystkich plików w nim i musi być w stanie wyliczyć listę plików przy użyciu elementu IVsSccProject2 lub GetProperty (VSH_PROPID_First_Child/Next_Sibling). Projekt powinien również uwidaczniać nazwy elementów za pośrednictwem implementacji GetMkDocument i wyszukiwania nazw pomocy technicznej (w tym plików specjalnych) za pomocą implementacji IsDocumentInProject .
Kontrolka Tekst X X Jeśli to możliwe, pliki powinny być w formacie tekstowym, aby obsługiwać scalanie różnych wersji. Plików, które nie mają formatu tekstowego, nie można później scalić z innymi wersjami pliku. Preferowany format tekstu to XML.
Oparte na odwołaniach X Projekty oparte na odwołaniach są łatwo obsługiwane w systemie kontroli wersji. Jednak projekty oparte na katalogach są również obsługiwane przez kontrolę źródła, o ile projekt może utworzyć listę swoich plików na żądanie, niezależnie od tego, czy te pliki istnieją na dysku. Podczas otwierania projektu z systemu kontroli wersji, plik projektu jest pobierany najpierw przed dowolnym z jego plików.
Utrwalanie obiektów i właściwości w przewidywalnej kolejności X X Utrwalanie plików w przewidywalnej kolejności, takiej jak kolejność alfabetyczna, w celu ułatwienia scalania.
Załaduj ponownie X X Gdy plik zmieni się na dysku, edytor musi mieć możliwość jego ponownego załadowania. Jeśli uczestniczysz w kontroli źródła, środowisko ponownie załaduje dane, wywołując implementację ReloadDocData . Najtrudniejszy przypadek ponownego ładowania to sytuacja, gdy żądanie edycji występuje po wywołaniu IVsQueryEditQuerySave::QueryEditFiles i przetwarzane są informacje. Jednak kod ponownego ładowania musi być w stanie się uruchomić w tej sytuacji.

Środowisko automatycznie ponownie ładuje pliki projektu. Jednak projekt musi zaimplementować IVsPersistHierarchyItem2, jeśli ma zagnieżdżone hierarchie w celu obsługi ponownego załadowania zagnieżdżonych plików projektu.