Ten typ zdarzenia jest obsługiwany wyłącznie dla projektu w pełni zarządzanego i przechowywanego w natywnym VCS Workspace (w jego repozytorium
Versioned Storage Git). Dla projektu lokalnego udostępnionego w Altium 365 Workspace, ale nieobjętego formalną kontrolą wersji — a więc korzystającego z metody Simple Sync — na osi czasu historii nie zobaczysz żadnych zdarzeń commit związanych z VCS. Aby uzyskać te informacje, możesz zmienić sposób udostępniania online, włączając opcję
Version Control na karcie
General w oknie dialogowym
Project Options. Spowoduje to objęcie projektu natywnym VCS Workspace.
Dla projektu udostępnionego w Altium 365 Workspace, ale już znajdującego się pod zewnętrzną kontrolą wersji, również nie zobaczysz na osi czasu historii żadnych zdarzeń commit związanych z VCS. Użyj klienta zewnętrznego systemu kontroli wersji, aby przeanalizować historię wersjonowania projektu. Alternatywnie możesz skutecznie przejść na natywny VCS Workspace. Możesz utworzyć migawkę projektu — najwydajniej i najczyściej wykonasz to za pomocą
Project Packager w Altium Designer. Odłącza to projekt od zewnętrznego VCS oraz od Workspace (jeśli był tam już udostępniony), po czym możesz ponownie udostępnić go w Workspace, ale już pod VCS Workspace — zaczynając niejako od nowa. Szczegółowe informacje na ten temat znajdziesz w
Moving from External VCS to Workspace Native VCS.
Za każdym razem, gdy wykonasz Commit projektu do Workspace (gdy projekt jest zarządzany w wewnętrznym repozytorium Versioned Storage Git Workspace), do osi czasu zostanie dodany kafelek zdarzenia Project Committed. Wyświetlane są imię i nazwisko (oraz zdjęcie) osoby, która wykonała commit (Save to Server), a także data i godzina. Jeśli w momencie commitu i wypchnięcia zmian dodano komentarz — w oknie dialogowym Commit to Version Control dialog — zostanie on również wyświetlony w kafelku.
Jeśli projekt był lokalnym, niezarządzanym projektem, który następnie udostępniono online, wówczas opis wprowadzony w oknie dialogowym
Make Available Online dialog zostanie użyty zarówno w kafelku zdarzenia
Project Created, jak i w początkowym kafelku zdarzenia
Project Committed, ponieważ commit projektu jest wykonywany w ramach udostępniania projektu online — oczywiście pod warunkiem, że włączono opcję
Version Control.
Przykładowy początkowy kafelek zdarzenia Project Committed.
Kafelek obsługuje również i prezentuje informacje o porównywaniu różnic w projekcie (design diffing), pokazując bardziej szczegółowe dane o tym, co zmieniło się między bieżącym a poprzednim commitem. Obsługiwane elementy obejmują pliki, komponenty, sieci, warianty oraz strukturę PCB. Sekcja różnic w kafelku podsumowuje różne elementy objęte zdarzeniem commitu, pogrupowane według następujących stanów:
– element dodany.
– element usunięty.
– element zmodyfikowany.
Kliknięcie elementu sterującego 
w kafelku rozwinie tę sekcję różnic, aby wyświetlić elementy objęte zmianą według nazwy.
Użyj dostępnych elementów sterujących
Show More i
Show Less, aby przeanalizować pełną listę dla każdego typu elementu. Kliknij element sterujący
w kafelku, aby wrócić do widoku podsumowania.
Kliknij element sterujący 
w prawym górnym rogu kafelka, aby uzyskać dostęp do menu z następującymi poleceniami:
-
Download Sources - uużyj, aby pobrać i otworzyć tę konkretną rewizję projektu PCB lub Harness w panelu Projects. Nazwa projektu będzie zawierać datę i godzinę, o której ta rewizja została zacommitowana. Zwróć uwagę, że ta rewizja jest tylko do odczytu; możesz ją przeglądać, ale nie edytować.
Możesz otworzyć (tylko do podglądu) dowolną konkretną rewizję projektu — bezpośrednio z odpowiadającego jej kafelka zdarzenia Project Committed dla tej rewizji.
-
Compare: Schematic to, PCB to, BOM to – umożliwia porównanie danych schematu, PCB lub BOM w tym commicie z danymi z innego commita lub zdarzenia wydania (release). Użyj podmenu, aby porównać z poprzednim commitem, albo wybierz spośród wszystkich dostępnych wydań i commitów. Po wybraniu danych do porównania wyniki są prezentowane w powiązanym widoku różnic, który otwiera się jako nowa karta w domyślnej przeglądarce. Więcej informacji: Design Data Comparisons (Altium 365 Workspace, Enterprise Server Workspace).
-
Create Tag – dodaj pojedynczy tag o niestandardowej nazwie do dowolnego commita projektu (i tylko wtedy, gdy projekt jest przechowywany w Workspace w ramach wewnętrznego systemu Git VCS). Tag można utworzyć wyłącznie dla commita, który jest już zapisany w Workspace. Po uruchomieniu polecenia otworzy się okno dialogowe Create Tag . Wprowadź żądany tag, a następnie kliknij Create.
Zostanie otwarte okno informacyjne, które ostrzeże, jeśli w nazwie tagu znajdują się niedozwolone znaki. Tag nie zostanie utworzony, dopóki niedozwolone znaki nie zostaną usunięte.
Jeśli projekt ma commity, które nie zostały jeszcze wypchnięte (push), otworzy się okno dialogowe Save To Server z pytaniem, czy chcesz wykonać push. Jeśli commit zostanie wypchnięty, otworzy się okno dialogowe Create Tag .
Gdy projekt jest wydawany (release) przy użyciu Project Releaser i jego najnowszy commit nie ma jeszcze tagu, tag zostanie automatycznie przypisany do tego najnowszego commita. Tag będzie miał postać RELEASE_<RevisionID>, gdzie <RevisionID> to numer rewizji wydanych źródeł projektu (A.1, A.2 itd.), na przykład RELEASE_A.3.
Aby zmienić nazwę lub usunąć tag, kliknij 
, a następnie najedź kursorem na wpis Tag . Otworzy się okno dialogowe, w którym możesz wprowadzić nową nazwę tagu. Jeśli zaznaczono Remove , tag zostanie natychmiast usunięty.
Polecenie
Create Tag jest również dostępne po kliknięciu prawym przyciskiem myszy nazwy projektu lub dokumentu w panelu
Projects , a następnie wybraniu
History & Version Control » Create Tag, aby utworzyć tag dla ostatniego/najnowszego commita.
Uwagi:
-
Brak obsługi tagów dla zewnętrznej kontroli wersji.
-
Na jeden commit można utworzyć tylko jeden (1) tag.
-
Utwórz kopię – użyj, aby utworzyć kopię z tej konkretnej rewizji projektu. Otworzy się okno dialogowe Create Project Copy , w którym wprowadzasz Project Name (domyślnie będzie to oryginalna nazwa projektu z sufiksem „ - Copy”), Description (nie jest wstępnie wypełniane), ścieżkę Folder (w obrębie Workspace) oraz ścieżkę Local Storage (do kopii roboczej). Projekt zostanie utworzony, a na osi czasu zostanie dodany kafelek zdarzenia Project Copied.
Domyślnie
Folder Workspace będzie tym samym folderem, w którym przechowywany jest oryginalny projekt. Kliknij
, aby otworzyć okno dialogowe
Choose Folder (okrojoną wersję panelu
Explorer) i w razie potrzeby zmienić folder. Domyślnie
Local Storage będzie ustawione na użycie lokalizacji zdefiniowanej na stronie
System - Default Locations w oknie dialogowym
Preferences. Kliknij
, aby otworzyć standardowe okno systemu Windows i w razie potrzeby zmienić tę lokalizację.
-
Revert to – użyj tego polecenia, aby przywrócić używanie danych z tej konkretnej rewizji projektu. Dane z dokumentów źródłowych projektu w tej rewizji nadpisują dane w lokalnej kopii roboczej projektu. W praktyce projekt jest na moment zamykany, a następnie ponownie otwierany z przywróconymi danymi. Jeśli chcesz dokończyć przywracanie i uczynić te dane rewizją Head (bieżącą wersją), musisz wykonać commit i push projektu z powrotem do Workspace.
Możesz przywrócić dowolną konkretną rewizję projektu bezpośrednio z odpowiadającego jej kafelka zdarzenia Project Committed dla tej rewizji.
Po przywróceniu konkretnej rewizji i przed wykonaniem commita możesz odtworzyć lokalną kopię roboczą do najnowszej rewizji, używając polecenia Revert to powiązanego z najnowszym kafelkiem zdarzenia Project Committed na osi czasu.
Kafelek zdarzenia
Project Committed jest fizycznie połączony z głównym „pniem” osi czasu ciągłą niebieską linią połączenia i węzłem:
. Najnowsza rewizja projektu (tj. ostatni commit) wyróżnia się białym wypełnieniem węzła:
.
Tłumaczenie SI