Dodatkowe wytyczne dotyczące kontroli źródła dla projektów i edytorów
Istnieje wiele wytycznych, które powinny być zgodne z projektami i edytorami w celu zapewnienia obsługi kontroli źródła.
Wytyczne
Projekt lub edytor powinien również wykonać następujące czynności, aby obsługiwać kontrolę źródła:
| Obszar | Projekt | Redaktor | Szczegóły |
|---|---|---|---|
| Prywatne kopie plików | X | Wsparcie środowiska 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 napiszesz kod trwałości, utrwali pliki w formularzu ANSI, ponieważ większość programów kontroli źródła 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 kontroli źródła. 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 kontroli źródła plik projektu jest najpierw wyłączany 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 polega na tym, że wyewidencjonowanie występuje po wywołaniu elementu IVsQueryEditQuerySave::QueryEditFiles i przetwarza informacje. Jednak kod ponownego ładowania musi być w stanie uruchomić w tej sytuacji. Środowisko automatycznie ponownie ładuje pliki projektu. Jednak projekt musi zostać zaimplementowany IVsPersistHierarchyItem2 , jeśli ma zagnieżdżone hierarchie w celu obsługi ponownego ładowania zagnieżdżonych plików projektu. |