Korzystanie z zewnętrznej kontroli wersji

Jedną z największych zalet środowiska do tworzenia i edycji elektroniki jest łatwość, z jaką można tworzyć i modyfikować plik. Ta możliwość oznacza, że pomysły można szybko zapisywać, badać i rozwijać, ale oznacza też, że trudno jest śledzić zmiany wprowadzane w cennych plikach, takich jak kod źródłowy i dane projektu elektronicznego.

Potrzeba śledzenia zmian wprowadzanych w pliku, w połączeniu z potrzebą systematycznego rozwiązania do zarządzania źródłami zapisanymi w formie elektronicznej, doprowadziła do powstania systemów kontroli wersji (VCS). Systemy kontroli wersji to narzędzia programowe, które nie tylko potrafią utrzymywać historię różnych wersji pliku, ale także umożliwiają otwarcie dowolnej rewizji tego pliku oraz porównywanie zmian pomiędzy dowolnymi dwiema wersjami pliku. VCS zazwyczaj integruje się z lokalnym systemem operacyjnym (OS), udostępniając dodatkowe funkcje i operacje wersjonowania dla folderów i plików.

Systemy kontroli wersji mogą działać całkowicie niezależnie od środowiska tworzenia i edycji używanego do utworzenia pliku. Zwykle oferują interfejs, który pozwala dodać (Add), a następnie zatwierdzić (Commit) pliki do centralnego obszaru przechowywania zwanego repozytorium, funkcję Checkout do skopiowania pliku z repozytorium do folderu roboczego, funkcję Commit do odesłania zmian z powrotem do repozytorium, metodę rejestrowania informacji o zmianie i wiele więcej.

Funkcje te są dostępne w rozszerzeniach powłoki Windows, takich jak klient Tortoise , i są również wbudowane w Altium Designer. Operacje VCS można wykonywać w środowisku Altium Designer bez potrzeby uzyskiwania dostępu do systemu plików OS.

Pomocne jest zrozumienie terminologii używanej w systemach kontroli wersji. Mimo że dostępnych jest wiele systemów, zazwyczaj wszystkie używają podobnych terminów do opisu swojej funkcjonalności.

Podstawy kontroli wersji

Altium Designer obsługuje systemy kontroli wersji (VCS) Subversion (SVN) oraz Git. Ponieważ ma wbudowaną obsługę tych systemów, zapewnia dostęp do typowych poleceń obsługi plików SVN/Git, takich jak Commit, Update itp. w ramach Altium Designer, wraz z dodatkowymi możliwościami Subversion, takimi jak możliwość tworzenia repozytorium SVN. Integruje się to z funkcjami porównywania schematów i PCB, ułatwiając szybkie porównanie i identyfikację różnic między dwiema rewizjami dokumentu schematu lub PCB oraz — w przypadku projektów PCB — rozwiązywanie konfliktów wynikających z równoczesnych zmian rewizji.

Podstawowe podejście do pracy z systemem kontroli wersji (VCS) polega na pobraniu z repozytorium kopii plików projektu, nad którymi chcesz pracować, edycji plików w Altium Designer, a następnie „zatwierdzeniu” (commit) zmodyfikowanych plików z powrotem do repozytorium. Interakcja z repozytorium odbywa się przez interfejs systemu kontroli wersji, który Altium Designer ma wbudowany w panel Storage Manager  oraz panel Projects.

Kluczem do działania systemu kontroli wersji jest to, że monitoruje on status plików pobranych z repozytorium za pośrednictwem folderu roboczego, a tym samym śledzi, nad którą rewizją się pracuje i czy została ona zmodyfikowana. Chociaż efekt końcowy jest taki sam, układ repozytorium i plików roboczych różni się w zależności od typu systemu kontroli wersji — Git lub SVN.

Git VCS

Poniższy rysunek ilustruje koncepcję zdalnego udziału repozytorium Git, które przechowuje sekwencję rewizji plików projektu (do rewizji 5), gdzie jego zawartość została skopiowana do lokalnego roboczego repozytorium Git — zazwyczaj poprzez sklonowanie (Clone) zdalnego repozytorium lub pobranie (Pull) jego danych do repozytorium roboczego. Gdy pliki w repozytorium roboczym zostaną otwarte w środowisku Altium Designer, Altium Designer rozpoznaje, że plik projektu jest objęty kontrolą wersji Git, a jego bieżący status kontroli wersji jest wyświetlany zarówno w panelu Storage Manager, jak i Projects.

► Więcej informacji znajdziesz na stronie Git-based Version Control.

Subversion VCS

Poniższy rysunek ilustruje koncepcję repozytorium Subversion, które przechowuje sekwencję rewizji plików projektu (do rewizji 5), przy czym najnowsza kopia jest pobrana (checked out) (File » Check Out) do folderu roboczego. Gdy pliki w folderze roboczym zostaną otwarte w środowisku Altium Designer, Altium Designer rozpoznaje, że plik projektu jest objęty kontrolą wersji SVN, a jego bieżący status kontroli wersji jest wyświetlany zarówno w panelu Storage Manager, jak i Projects.

► Więcej informacji znajdziesz na stronie SVN-based Version Control.

W obu powyższych systemach VCS powiązanie między repozytorium źródłowym a lokalizacją roboczą jest zapisane w bazie danych VCS tej drugiej (w podfolderze systemowym .svn lub .git).

Gdy pliki robocze VCS są otwarte w Altium Designer, menu pod prawym przyciskiem myszy w panelu Storage Manager (oraz w panelu Projects) umożliwia wykonywanie standardowych działań VCS, takich jak zatwierdzenie (commit) zmienionego pliku do centralnego repozytorium (SVN) lub repozytorium roboczego (Git).

Dostęp do kontroli wersji

W Altium Designer działania związane z VCS można wykonywać za pomocą paneli Projects oraz Storage Manager, przy czym ten drugi zapewnia bezpośredni dostęp do dodatkowych poleceń i informacji VCS. Panele są wypełniane dokumentami projektu i powiązanym statusem VCS po ich otwarciu w Altium Designer.

Panele można otworzyć z menu przycisku w prawym dolnym rogu obszaru roboczego lub z głównego menu View » Panels.

Panel Projects

Panel Projects wyświetla wszystkie projekty aktualnie otwarte w Altium Designer, wraz z ich dokumentami składowymi oraz powiązanym statusem kontroli wersji dla każdego pliku.

Status pliku VCS w panelu jest wskazywany za pomocą serii ikon odnoszących się do konkretnych stanów pliku wykrytych przez system kontroli wersji. Stan dla każdego pliku jest, w ujęciu ogólnym, określany względem jego odpowiednika istniejącego pod kontrolą wersji w powiązanym repozytorium. Polecenia VCS w panelu Projects są dostępne z opcji Version Control w menu kontekstowym panelu (prawy przycisk myszy).

Ikony kontroli wersji, tak jak pojawiają się w panelu Projects

► Więcej informacji znajdziesz na stronie Projects panel.

Panel Storage Manager

Panel Storage Manager zapewnia rozbudowany widok aktywnego dokumentu z perspektywy przechowywania plików oraz udostępnia funkcję lokalnej historii dokumentu i status/polecenia kontroli wersji.

Status pliku VCS w panelu jest wskazywany za pomocą serii opisów i odpowiadających im ikon, które odnoszą się do konkretnych stanów pliku wykrytych przez system kontroli wersji. Stan dla każdego pliku jest, w ujęciu ogólnym, określany względem jego odpowiednika istniejącego pod kontrolą wersji w powiązanym repozytorium.

Panel Storage Manager

Polecenia VCS w panelu Storage Manager są dostępne z menu kontekstowego (prawy przycisk myszy). Aby wykonać działanie VCS na konkretnym pliku, kliknij prawym przyciskiem myszy jego wpis w panelu i wybierz żądane polecenie — na przykład Commit, Update, Resolve conflict itp.

Historię rewizji wybranego pliku oraz lokalną historię dokumentu można zobaczyć w dolnej części panelu albo jako ogólną oś czasu zdarzeń po przełączeniu na „classic view” — Switch to Classic View w opcjach pod prawym przyciskiem myszy. Wskazany numer rewizji będzie zwiększał się z każdym zatwierdzeniem (commit) w VCS, przy czym pierwsza rewizja (Revision 1) odpowiada utworzeniu folderów projektu VCS, zanim pliki zostaną dodane.

► Więcej informacji znajdziesz na stronie Storage Manager panel.

Status kontroli wersji

Zarówno w panelu Projects, jak i Storage Manager, bieżący status VCS każdego pliku objętego kontrolą wersji jest wyświetlany obok jego wpisu w panelu.

System kontroli wersji zasadniczo monitoruje i porównuje pliki w folderze roboczym z ich odpowiednikami w repozytorium projektu. Altium Designer zarówno żąda, jak i wymienia informacje z systemem kontroli wersji za pośrednictwem swojego interfejsu VCS, a następnie odpowiednio reaguje na warunki wynikające z porównania statusów plików. W praktyce przejawia się to w ikonach plików w panelach Projects i Storage Manager, poprzez szereg alertów VCS oraz poprzez odpowiednie zmiany w dostępnych poleceniach zarządzania plikami.

Ikony i ich znaczenie opisano w sekcji Version Control Status Icons na stronie Managing Project Documents .

Dostęp wielu użytkowników

W większości przypadków infrastruktura kontroli wersji w firmie będzie oparta na centralnych repozytoriach SVN lub Git, udostępnianych w sieci przy użyciu jednej z dostępnych metod protokołów – svn, svn+ssh, https itd. Zapewnia to dostęp wszystkim użytkownikom w sieci (zgodnie z uprawnieniami) oraz umożliwia zespołowe rozwijanie projektu z jednego źródła.

Z kolei możliwości wielodostępu pozwalają różnym członkom zespołu kontynuować pracę nad projektem niezależnie, bez konieczności czekania, aż ktoś inny zwróci plik (check-in), zanim będzie można na nim pracować. Rozproszony Git version control system idzie o krok dalej, umożliwiając zatwierdzanie (commit) plików do lokalnego repozytorium roboczego w trakcie pracy, a następnie „wypychanie” (push) tych zatwierdzonych zmian do centralnego repozytorium Git w dowolnym późniejszym momencie – i w związku z tym nie wymaga połączenia sieciowego aż do tego momentu.

Mimo to system kontroli wersji (VCS) przystosowany do pracy zespołowej wymaga dostępności narzędzi i technik do rozwiązywania nieuniknionej sytuacji, w której dwóch użytkowników zmodyfikowało ten sam plik. Gdy te możliwości są dostępne, powstaje fundament dla prawdziwej, wieloosobowej współpracy projektowej i związanych z nią korzyści.

Aby wesprzeć tę sytuację, Altium Designer zawiera funkcje porównywania schematów i PCB (czyli „diff”), dostępne przez panel Storage Manager panel.

Repozytoria VCS

Najlepszym sposobem pracy na znanym zestawie plików źródłowych jest przechowywanie projektu w kontrolowanym środowisku, takim jak repozytorium kontroli wersji. Jest to ważne, ponieważ jedynym sposobem zapewnienia, że wyniki (outputs) pochodzą z właściwych plików źródłowych, jest:

1. Potwierdzenie, że zestaw plików źródłowych jest aktualny.
2. Wykonanie ich migawki (snapshot).
3. Wygenerowanie wyników na podstawie tej migawki.

W Altium Designer takie repozytorium określa się jako Design Repository. Będące własnością zespołu projektowego, Design Repository zawiera szczegółowy wgląd w historię procesu projektowego i jest podstawowym narzędziem współpracy używanym przez zespół.

Design Repository staje się centralnym repozytorium, z którego wielu członków zespołu może pobierać i zwracać dane (check-out/check-in), przy jednoczesnym zachowaniu pełnej historii rewizji wszystkich zmian wprowadzonych w projekcie. Projekt jest więc przechowywany jako seria wersji składających się na niego dokumentów projektu i dokumentów źródłowych, budując z czasem progresywny obraz intencji projektanta. Korzystając z Design Repository objętego kontrolą wersji, masz wbudowaną pewność, że żadna rewizja projektu nigdy nie zostanie utracona, co umożliwia bezpieczną współpracę nad tym samym projektem między członkami zespołu, którzy mogą znajdować się w różnych lokalizacjach geograficznych. Sama natura systemu kontroli wersji zapewnia ścieżkę audytu dla projektu. Pełna rozliczalność wynika z przejrzystości: kto co zmienił, w którym dokumencie źródłowym i kiedy. System może obsługiwać wiele repozytoriów Design Repository objętych kontrolą wersji, a powiązanie z konkretnym repozytorium jest ustanawiane przez łącze kontroli wersji w folderze projektu.

Przed użyciem kontroli wersji pliki projektu muszą zostać rozpoznane zarówno przez VCS, jak i przez Altium Designer jako objęte kontrolą wersji. Proces ten może się różnić w zależności od metod i aplikacji VCS, ale zasadniczo polega na utworzeniu i/lub podłączeniu repozytorium projektu oraz dodaniu do niego plików projektu.

Repozytoria projektowe są oparte na strukturze bazy danych i wewnętrznie przechowują informacje w hierarchii plików i katalogów, nazywanej drzewem plików. Faktyczne repozytorium, z którym się łączysz, może być centralnym repozytorium SVN, roboczym repozytorium Git (powiązanym ze zdalnym repozytorium Git) albo repozytorium utworzonym w dostępnym miejscu, np. na lokalnym komputerze PC lub w udostępnionej lokalizacji sieciowej.

Aktualizowanie nowych zmian w kontroli wersji

Gdy projekt zostanie dodany do kontroli wersji, jego lokalny folder roboczy projektu zostaje powiązany z odpowiednikiem w repozytorium VCS, co wskazuje ikona łącza skojarzona z wpisami folderu projektu w panelu Storage Manager. Aby potwierdzić lokalizacje powiązanego folderu i repozytorium, kliknij prawym przyciskiem myszy dowolny wpis pliku w panelu i wybierz opcję VCS Properties (niedostępne przy użyciu Git). Następujące okno dialogowe Properties zawiera ścieżki powiązanych lokalizacji oraz informacje o najnowszej rewizji VCS.

Plik wskazany ikoną łącza oraz odpowiadający mu panel Properties , który zawiera informacje o najnowszej rewizji VCS

Okno dialogowe Properties udostępnia następujące informacje (są one wyłącznie do podglądu; edycja nie jest dozwolona): 

• Path - ścieżkę do lokalnego dokumentu w Twoim folderze roboczym).
• URL - adres URL lokalizacji dokumentu w repozytorium VCS.
• Repository Root - katalog główny repozytorium (repository root).
• Repository UUID - UUID repozytorium.
• Revision - bieżącą rewizję dokumentu w Twoim lokalnym folderze roboczym.
• Last Change Author - autora ostatniej zmiany.
• Last Change Revision - rewizję ostatniej zmiany
• Last Change Time - datę i godzinę ostatniej zmiany.
• Conflicted - informację, czy dokument jest w konflikcie.

W wyniku zarejestrowanego łącza VCS system kontroli wersji może monitorować i wykrywać wszelkie różnice między plikami w lokalnym folderze projektu a ich odpowiednikami w folderze repozytorium VCS. Gdy zostanie wykryta różnica, na przykład gdy plik projektu zostanie edytowany i zapisany w Altium Designer, system kontroli wersji zmieni status lokalnego pliku na Modified (), a Altium Designer udostępni odpowiedni zestaw poleceń VCS w menu pod prawym przyciskiem myszy w panelach.

Zatwierdzanie zmian (Commit)

Po edycji i zapisaniu pliku dokumentu projektu w Altium Designer jest on oznaczany jako Modified i wskazywany jako taki () zarówno w panelu Projects, jak i Storage Manager. Aby zatwierdzić te zmiany jako nową rewizję w VCS, kliknij prawym przyciskiem myszy wpis pliku w panelu i wybierz polecenie Commit z menu kontekstowego albo wybierz polecenie Project » History & Version Control » Commit z menu głównego.

Podczas zatwierdzania zmiany w pliku zostanie otwarte okno Edit Comment dialog. Użyj tego okna, aby dodać komentarz wyjaśniający powód zatwierdzenia, co może pomóc innym zobaczyć, jakie zmiany zostały wprowadzone. Jeśli dodałeś wcześniej komentarze, możesz szybko wybrać jeden z nich do użycia.

Polecenie Commit

Polecenie Commit Whole Project również może zostać użyte, co spowoduje zatwierdzenie wszystkich zmodyfikowanych plików w projekcie. Podczas zatwierdzania całego projektu zostanie otwarte okno dialogowe Commit to Version Control.

Okno dialogowe Commit to Version Control

• When using Subversion (SVN): Proces commit kopiuje zaktualizowany plik z folderu lokalnego do repozytorium, zwiększając numer rewizji wpisu w VCS i ustawiając status pliku z powrotem na No Modification ().
• When using Git:Proces commit aktualizuje lokalne repozytorium robocze VCS, jednocześnie zwiększając numer rewizji wpisu i ustawiając status pliku na Ahead of Server (). Możesz dalej edytować, zapisywać i wykonywać commit plików w repozytorium roboczym albo zatwierdzić nowe zmiany, używając polecenia Push, aby zaktualizować zdalne repozytorium Git – status pliku wróci wtedy do No Modification ().

Wyświetl panel Storage Manager, aby zobaczyć sekwencję działań w sekcji VCS Revisions, która będzie obejmować utworzenie nowej rewizji VCS (ze zwiększonym numerem rewizji) dla tego pliku – w tym przypadku Rewizja 3 oraz dodany komentarz. Ikona wskazuje najnowszą i bieżącą rewizję wybranego pliku, czyli w terminologii kontroli wersji rewizję Head.

Sekcja VCS Revisions w panelu Storage Manager

Aby uzyskać widok łączony wpisów rewizji i zdarzeń historii, przełącz na pojedynczy widok Timeline, wybierając Switch to Combined View z menu kontekstowego (prawy przycisk myszy).

Check out z kontroli wersji

Jak opisano powyżej, lokalny projekt dodany do kontroli wersji może być edytowany w Altium Designer z lokalnego folderu projektu, a zmiany są następnie aktualizowane w repozytorium VCS. Folder lokalny i folder repozytorium są powiązane i ostatecznie synchronizowane przez VCS.

Inny użytkownik, który nie będzie miał dostępu do projektu z jego folderu źródłowego (lokalnego na Twoim PC), może użyć procesu Clone (Git) lub Check Out (SVN), aby pobrać własną kopię plików z repozytorium VCS hostującego projekt. Wszyscy użytkownicy, którzy chcą współpracować nad projektem, muszą łączyć się z tym wspólnym repozytorium projektu, które zwykle jest udostępnione w sieci lokalnej lub na serwerze.

Wybrany folder projektu w repozytorium oraz zawarte w nim pliki zostaną pobrane (checked out) do wskazanego folderu lokalnego i otwarte w Altium Designer. Zwróć uwagę, że folder lokalny to ten zdefiniowany jako folder checkout dla wybranego repozytorium, a pobrany projekt zostaje następnie powiązany ze swoim odpowiednikiem w repozytorium VCS. To powiązanie VCS instruuje system kontroli wersji, aby monitorował i wykrywał wszelkie różnice między plikami w lokalnym folderze checkout a ich odpowiednikami w folderze repozytorium VCS.

Wykonaj commit zmian po zakończeniu edycji plików, co zsynchronizuje pliki w repozytorium projektu tak, aby odpowiadały tym w folderze checkout, tworząc nową rewizję VCS.

Checkout vs Open Project

Gdy projekt local został dodany do kontroli wersji, istnieją w praktyce dwa sposoby jego edycji i aktualizacji do VCS:

• Poprzez otwarcie lokalnego projektu (File » Open Project) w Altium Designer, a następnie wykonanie commit zapisanych zmian do repozytorium VCS. W tym przypadku lokalny folder projektu i jego odpowiednik w repozytorium są powiązane przez VCS.

  

• Poprzez pobranie projektu (check out) (File » Check Out) z repozytorium VCS, a następnie wykonanie commit zapisanych zmian wprowadzonych w Altium Designer z powrotem do repozytorium. W tym przypadku projekt w wskazanym folderze checkout i jego odpowiednik w repozytorium są powiązane przez VCS.

  

Lokalny projekt jest źródłem (origin) projektu VCS, który jest współdzielony z innymi użytkownikami. W zależności od tego, jak chcesz pracować, ta lokalna wersja źródłowa może zostać usunięta lub zablokowana jako zarchiwizowane źródło projektu, a następnie można użyć podejścia Check Out, aby wprowadzać dalsze edycje. Możesz też nadal otwierać i pracować na plikach projektu z lokalnego folderu „źródłowego” (Open Project).

Najlepszym podejściem jest trzymanie się jednej metody (zalecany jest check out), ponieważ te dwie opcje operują na folderze roboczym w różnych lokalizacjach – w lokalnym folderze źródłowym projektu albo w wskazanym folderze checkout VCS. Jeśli natomiast używa się obu metod, na lokalnym PC będą istniały wielokrotne, aktywne kopie tego samego projektu. Jeżeli jednak po każdej edycji te wersje są sumiennie commitowane do scentralizowanego repozytorium VCS, repozytorium będzie zawsze zawierało najnowszą rewizję projektu – zgodnie z założeniem.

Zwróć też uwagę, że po pierwszym pobraniu (check out) projektu z repozytorium VCS projekt istnieje już lokalnie i można go ponownie otworzyć bezpośrednio z folderu checkout (File » Open Project). W takim przypadku ponownie pojawia się wybór: pobrać projekt z VCS albo otworzyć wersję lokalną, jednak lokalnie zawsze istnieje tylko jedna kopia. W praktyce VCS obie metody są bardzo podobne, ale w pewnych okolicznościach zachowują się inaczej – na przykład gdy brakuje lokalnego pliku: proces check out go przywróci, natomiast polecenie Open Project usunie go z projektu.

Rewizje kontroli wersji

Podczas pracy z dokumentami projektowymi w Altium Designer, które są objęte kontrolą wersji, pliki projektu pobrane z centralnego (współdzielonego) repozytorium VCS będą reprezentować ich najnowszą rewizję. Gdy lokalne edycje zostaną zakończone i wykonany zostanie commit (lub w przypadku Git: push) z powrotem do współdzielonego repozytorium VCS, te wersje plików stają się najnowszymi rewizjami.

W związku z tym typowa sekwencja: check out, edycja, zapis i commit (oraz Push w Git) stopniowo dodaje nowe rewizje plików do centralnego VCS w miarę rozwoju projektu. Jednak gdy projekt jest rozwijany zespołowo przez kilku projektantów, nowe rewizje mogą być commitowane do centralnego (współdzielonego) repozytorium w dowolnym momencie – przez dowolnego projektanta.

Nieaktualna rewizja

Interakcja wielu projektantów z centralnym repozytorium może objawiać się na różne sposoby; jednym z nich jest sytuacja, w której lokalnie otwarty projekt nie jest już najnowszą rewizją – projekt pobrany z repozytorium lub otwarty z lokalnego folderu roboczego ma status Out of date () w panelu Projects.

Plik oznaczony jako Out of fate

W tym przypadku inny użytkownik edytował i wykonał commit tego samego projektu do repozytorium od czasu ostatniej lokalnej edycji. Na przykład lokalny użytkownik Barry pracuje nad projektem i wykonał commit, powiedzmy, Revision 14, ale inny użytkownik Harold wykonał commit Revision 15 później, co pokazano w panelu Storage Manager poniżej. Ponieważ VCS wykrywa różnicę między plikiem w lokalnym folderze roboczym a jego odpowiednikiem w repozytorium (który w tym przypadku jest nowszy), system uznaje najnowszą rewizję local (wskazaną ikoną ) za nieaktualną.

Różne stany rewizji w Storage Manager

Sytuację tę koryguje się przez zaktualizowanie lokalnych plików tak, aby odpowiadały tym w centralnym repozytorium VCS, używając polecenia Update z menu kontekstowego (prawy przycisk myszy) panelu Projects lub Storage Manager. Następnie obie wersje pliku są synchronizowane, a wersja lokalna (dla użytkownika Barry) zostaje zaktualizowana do najnowszej rewizji – w tym przykładzie Revision 15. Zwróć uwagę, że jeśli wykonasz Save dla pliku, gdy jest on oznaczony jako Out of date, spowoduje to sytuację VCS typu Conflict, w której VCS wykrywa, że w folderze roboczym zaktualizowano starszą rewizję pliku.

Centralne repozytorium i rewizja lokalna w Storage Manager

Możesz także wybrać polecenie Update Whole Project, aby otworzyć okno dialogowe Update from Version Control umożliwiające wybór plików do pobrania (check out) ze współdzielonego repozytorium. W oknie dialogowym wyświetlane są wszystkie dokumenty w projekcie, które są nieaktualne lub zawierają konflikty. Możesz wybrać konkretne dokumenty do aktualizacji albo zaktualizować wszystkie naraz. Wybrane dokumenty są aktualizowane z repozytorium, a wszystkie nieaktualne dokumenty są domyślnie zaznaczone. Wszystkie zaznaczone dokumenty zostaną zaktualizowane do najnowszej wersji w repozytorium.

Okno dialogowe Update from Version Control

Kolumna Path wyświetla katalog pliku. Kolumna Status wyświetla bieżący status pliku. Jeśli status pliku jest wyświetlany jako Conflict, kliknięcie OK w celu aktualizacji plików spowoduje wyświetlenie okna potwierdzenia. Kliknij OK, aby zaktualizować do najnowszej wersji w repozytorium, lub Cancel, aby wyjść i zapisać zmiany do wersji aktualnie znajdującej się w repozytorium.

Konflikt rewizji

Interakcja między wieloma projektantami a centralnym repozytorium może również doprowadzić do sytuacji, w której ten sam plik został lokalnie edytowany i zapisany przez dwóch użytkowników Altium Designer, a jeden z nich zatwierdził (commit) te zmiany.

Oznacza to, że sekwencje kroków dwóch projektantów (check out, edycja, zapis, commit) przeplatają się, więc plik, który użytkownik pobrał z repozytorium do edycji, może nie remain jako najnowsza rewizja w trakcie pracy – inny użytkownik w międzyczasie zaktualizował rewizję. Ten, kto jako pierwszy zatwierdzi edycje do repozytorium, „zdominuje” sytuację, tworząc nową rewizję, natomiast drugi użytkownik, który edytował i zapisał ten sam plik, napotka sytuację Conflict – wskazywaną ikoną .

Przykład konfliktu rewizji

Z perspektywy VCS, który porównuje pliki w folderze roboczym z plikami w repozytorium, Konflikt oznacza stan, w którym nieaktualna rewizja pliku w folderze roboczym została edytowana i zapisana.

Rewizje Git VCS w panelu Storage Manager

Istnieje kilka opcji poleceń dostępnych z menu kontekstowego (prawy przycisk myszy) panelu Projects, z menu głównego Project » History & Version Control oraz z panelu Storage Manager, których można użyć, gdy plik ma status Conflict:

• Commit – ta opcja spowoduje błąd Subversion, ponieważ zatwierdzenie lokalnie edytowanej rewizji (np. Revision 15) nadpisałoby nowszą rewizję (Revision 16) już zatwierdzoną przez innego użytkownika.
• Update – ta opcja zaktualizuje lokalną rewizję pliku do najnowszej wersji z centralnego repozytorium (Revision 16), powodując utratę wszelkich lokalnych zmian wprowadzonych w Revision 15.

• Resolve Conflict – ta opcja odrzuci zmiany zatwierdzone w repozytorium od czasu ostatniej aktualizacji. Po uruchomieniu polecenia pojawi się okno potwierdzenia – kliknij Yes , aby kontynuować. Plik projektu w Twoim folderze roboczym zostanie zaktualizowany do najnowszej rewizji zapisanej w repozytorium przez innego użytkownika, ale edytor zachowa zmiany, które wprowadziłeś w poprzedniej rewizji. W efekcie plik lokalny uzyskuje stan Modified, co pozwala zatwierdzić te zmiany jako nową rewizję w repozytorium – używając polecenia Commit  lub polecenia Commit Whole Project . Gdy zatwierdzisz plik projektu, drugi użytkownik zobaczy plik(i) jako Out of date, ponieważ utworzyłeś nowszą rewizję w repozytorium.

  Ta opcja jest zalecana wyłącznie wtedy, gdy plik text jest w konflikcie, ponieważ system Subversion spróbuje scalić (Merge) różnice do pliku lokalnego. Ten proces może potencjalnie uszkodzić inne typy plików, takie jak dokumenty projektowe, dlatego konflikt najlepiej rozwiązać przez aktualizację do najnowszej rewizji źródłowej albo przez cofnięcie (Revert) lokalnych zmian.

  W przypadku Git polecenie Resolve Conflict nadpisze stan konfliktu, zatwierdzając plik do lokalnego folderu repozytorium. Gdy plik zostanie następnie wypchnięty (Push) do zdalnego repozytorium, plik drugiego projektanta zostanie oznaczony jako Out of Date i będzie musiał zostać zaktualizowany. Podobnie jak w Subversion, najbezpieczniejszą ścieżką jest jednak Update plik w konflikcie do najnowszej rewizji źródłowej (w terminologii Git: Pull) albo Revert lokalne zmiany.
• Revert – ta opcja spowoduje utratę (cofnięcie) lokalnych zmian, przywracając plik lokalny do jego rewizji bazowej – tutaj Revision 15. Konflikt rewizji zostaje więc rozwiązany, ale plik zostanie następnie oznaczony jako Out of date, ponieważ w repozytorium istnieje nowsza rewizja (Revision 16).

Porównywanie rewizji

Cenną zaletą pracy z kontrolą wersji jest możliwość porównywania historycznych rewizji plików projektowych, co zapewnia wbudowany w Altium Designer Difference Comparator, dostępny z panelu Storage Manager. W połączeniu z panelem Differences można wykonać porównanie logiczne lub graficzne pomiędzy rewizjami VCS, jednocześnie interaktywnie przeglądając obiekty, których dotyczą zmiany. Można porównywać rewizje schematów i PCB.

Aby rozpocząć porównanie dwóch rewizji, zaznacz oba wpisy (standardową metodą Ctrl+click) na liście panelu Storage Manager VCS Revisions, a następnie wybierz polecenie Compare z menu kontekstowego panelu (prawy przycisk myszy).

Polecenie Compare w panelu Storage Manager

Obie rewizje pliku zostaną otwarte w trybie podzielonego ekranu, gdzie można je porównać wizualnie. Wyświetlane różnice zależą od opcji wybranych dla typów porównania fizycznego w zakładce Comparator tab okna dialogowego Options for Project – Project » Project Options.

Kluczem do lokalizowania i przeglądania różnic porównania jest panel Differences, który udostępnia wybieralną listę różnic logicznych lub graficznych między dokumentami. Wpisy na liście panelu dla każdej rewizji dokumentu współpracują z edytorem, umożliwiając graficzne podświetlenie wykrytej różnicy (np. przesuniętego obiektu) po jej zaznaczeniu.

Lokalizowanie i przeglądanie różnic porównania odbywa się w panelu Differences

Funkcja Compare dotyczy również rewizji dokumentów PCB, a także rewizji schematów i dokumentów tekstowych.

• Dla dokumentów schematów lub PCB (projektowych lub bibliotecznych) wykonywane jest porównanie graficzne, a wykryte różnice są wypisane w panelu Differences. Mając dwie wersje dokumentu otwarte obok siebie w oknie edytora projektu, możesz przeglądać różnice graficznie. Kliknięcie folderu najwyższego poziomu dla wykrytej różnicy podświetli tę różnicę jednocześnie w obu dokumentach.
• Dla tekstowych dokumentów ASCII pojawi się okno dialogowe CompareForm , pokazujące graficzny „diff” dwóch wersji dokumentu. Wybrane dokumenty są wyświetlane obok siebie. Okno służy wyłącznie do porównania – nie można w nim wprowadzać modyfikacji do załadowanego dokumentu. Dzięki kodowaniu kolorami okno podświetla różnice między dwiema wersjami dokumentu: linie dodane (różowe), linie zmodyfikowane (zielone) oraz linie usunięte (niebieskie). Podsumowanie zmian i legenda kolorów znajdują się w lewym dolnym rogu okna.

Funkcja Compare

Polecenie Compare można zastosować do dowolnej pary rewizji, w tym pomiędzy bieżącą rewizją lokalną (w folderze roboczym) a nowszą rewizją w repozytorium. W takiej sytuacji najnowsza rewizja lokalna jest wskazywana w panelu Storage Manager jako Out of date (), ale mimo to można ją porównać z nowszą rewizją dodaną do repozytorium przez innego użytkownika.

Rewizja lokalna jest wskazywana w panelu Storage Manager jako Out of date

Takie podejście pozwala graficznie podejrzeć zmiany, które zostaną wprowadzone po aktualizacji do nowej rewizji. W przykładzie na obrazie powyżej bieżąca rewizja lokalna (wskazywana ikoną ) jest Revision 19, ale inny użytkownik zatwierdził nową rewizję do repozytorium (Revision 22). Uruchomienie porównania wizualnego między Revision 19 a Revision 22 pozwala podjąć świadomą decyzję o zaakceptowaniu nowych zmian z repozytorium, a pośrednio – czy zastosujesz polecenie Update, czy też je przeważysz, wywołując stan konfliktu – poprzez ponowny zapis pliku lokalnego i rozwiązanie konfliktu na korzyść Twojej wersji lokalnej.

Terminologia kontroli wersji

Odnośniki

• SVN website: http://subversion.apache.org/
• SVN online manual: http://svnbook.red-bean.com/
• SharpSVN project home: https://sharpsvn.open.collab.net
• Git website: https://git-scm.com/
• Git online documentation: https://git-scm.com/doc
• The Tortoise Clients: http://tortoisesvn.net i https://tortoisegit.org/
• Source Control How-to, by Eric Sink: http://www.ericsink.com/scm/source_control.html