Pl/FGAddon
Oficjalny hangar statków powietrznych FGAddon jest repozytorium kontroli wersji, hostowanym na infrastrukturze SourceForge projektu FlightGear i wykorzystywanym do codziennego rozwoju statków powietrznych dla FlightGear. FGAddon używa repozytorium kontroli wersji Apache Subversion. Są to statki powietrzne, które nie są częścią pakietu podstawowego (statki powietrzne zawarte w pakiecie podstawowym — Cessna 172P i UFO — są przechowywane w repozytorium FGData), ale są oznaczane jako gotowe do pobrania przy każdym stabilnym wydaniu.
Repozytorium rozwojowe statków powietrznych FGAddon należy traktować jako niestabilne. W przypadku korzystania ze stabilnego wydania FlightGear najlepiej jest pobrać statki powietrzne bezpośrednio w Launcherze, albo ze strony pobierania. Jednakże, ponieważ stabilne wydania od wersji 3.4 FlightGear są oznaczone i obecne w repozytorium FGAddon, narzędzia Subversion mogą być wygodnym sposobem na uzyskanie pojedynczych samolotów lub całego oficjalnego hangaru około 500 statków powietrznych. Ponadto, jeśli korzystasz z najnowszych nocnych wydań lub samodzielnie skompilowanej wersji FlightGear z repozytorium kontroli wersji Git, użycie FGAddon umożliwia aktualizację statku powietrznego do najnowszych wersji rozwojowych.
Historia
FlightGear został zapoczątkowany 8 kwietnia 1996 roku przez Davida Murra, który zaproponował stworzenie nowego symulatora lotu przez wolontariuszy[1][2][3][4]. Częścią początkowych celów było opracowanie procedur graficznych 2D i 3D dla symulatora. Było to jednak ogromne zadanie, które zostało przerwane na początku 1997 roku, gdy główny programista, Eric Korpela, kończył swoją pracę magisterską. Jednak, począwszy od 16 maja 1997 roku, Curtis Olson wznowił prace nad nowym projektem opartym na bibliotece OpenGL, umożliwiając stworzenie funkcjonalnego symulatora lotu w krótkim czasie[5]. Pierwsze zatwierdzenia dotyczyły oryginalnych repozytoriów kontroli wersji CVS flightgear i simgear.
Wraz z rozwojem projektu rosła wielkość, ilość i jakość zasobów FlightGeara. Zasoby te nie były uporządkowane i były rozproszone w różnych częściach Internetu. Dlatego też zdecydowano, że większość zawartości FlightGeara zostanie zebrana i przechowywana razem w nowym scentralizowanym repozytorium CVS o nazwie fgdata, które zostało utworzone 22 października 2000 roku. Aby umożliwić legalną redystrybucję tych zasobów w ramach dystrybucji FlightGear, przyjęto licencję wyłącznie GPLv2.
W maju 2010 roku rozwój został przerwany przez niesławny "incydent kawowy", który spowodował utratę domowego serwera Curtisa, na którym znajdowały się wszystkie repozytoria FlightGeara[6]. Wydarzenia te spowodowały masową migrację wszystkich repozytoriów CVS do repozytoriów Git. Ze względu na problemy z przepustowością zdecydowano, że nowe repozytoria będą hostowane w infrastrukturze open source Gitorious 
.
Z czasem, w miarę rozwoju projektu, rozmiar i zakres repozytorium fgdata rosły, głównie z powodu rosnącej liczby statków powietrznych przechowywanych w $FG_ROOT/Aircraft, więc podział był nieunikniony. Pierwsza próba podziału została zorganizowana przez Gijsa de Rooya i ogłoszona 18 października 2011 roku[7]. Każdy osobny statek powietrzny został umieszczony we własnym repozytorium Git, a wszystkie zostały połączone z powrotem z fgdata przy użyciu podejścia podmodułów Git. Jednak ta próba nie powiodła się i została porzucona. Od tego dnia do końca 2014 roku projekt podziału fgdata był omawiany na liście dyskusyjnej deweloperów i podsumowany w artykule wiki FlightGear Git: podział FGData. W fazie planowania, repozytoria były znane jako fgdata-old podzielone na FGData (znany również jako fgdata-new) i FGAddon (znany również jako flightgear-aircraft i fgaircraft). Po pół dekadzie planowania zdecydowano, że najlepszym rozwiązaniem dla rozwoju statków powietrznych FlightGear będzie jedno scentralizowane repozytorium Subversion. Ułatwiłoby to zarządzanie i utrzymanie statków powietrznych przez społeczność, zapewniając jednocześnie modułowość i mniejsze pliki do pobrania oraz mniejsze rozmiary lokalnego repozytorium.
Pod koniec 2014 roku Gitorious, dostawca infrastruktury open source dla repozytoriów kodu źródłowego i danych FlightGeara, ogłosił, że zamknie swoje usługi do maja 2015 roku z powodu przejęcia przez GitLab. Spowodowało to podział fgdata-old i przejście na infrastrukturę open source SourceForge do hostowania repozytoriów kontroli wersji. Inne części infrastruktury FlightGeara były już hostowane przez SourceForge, co czyniło ten ruch naturalnym. Przypieczętowując umowę, SourceForge zgodziło się na piśmie hostować ogromną kolekcję statków powietrznych FlightGeara, której rozmiar nie ma sobie równych w kręgach open source. Obecnie repozytorium FGAddon SVN, wraz z większością infrastruktury projektu FlightGear, jest hostowane na SourceForge.
W sierpniu 2015 roku został utworzony nowy dokument dla projektu FlightGear, w którym spisano wcześniej ustalone zasady[8]. Wraz z tym dokumentem polityka licencyjna dla statków powietrznych FlightGeara hostowanych na FGAddon została zaktualizowana z "wyłącznie GPLv2" na GPLv2+. W celu zwalczania mnożenia się licencji, uniknięcia komplikacji związanych z wykorzystaniem pracy z jednego statku powietrznego w innym, a także dla integralności i dobra projektu FlightGear, zdecydowanie zaleca się, aby cała oryginalna zawartość (niezależnie od tego, czy jest hostowana w FGAddon, czy gdzie indziej) była licencjonowana na licencji GPLv2+.
Pozyskiwanie statków powietrznych
| Wskazówka Jeśli jesteś zainteresowany uzyskaniem statków powietrznych dla stabilnych wydań FlightGear i nie wiesz, czym jest kontrola wersji, powinieneś odwiedzić Hangary FlightGeara w celu pobrania statków powietrznych. |
| Uwaga Jeśli wersja FlightGeara i statków powietrznych FGAddon nie pasuje do siebie, należy spodziewać się dziwnych błędów, a kombinacja niedopasowanej wersji nie będzie obsługiwana przez społeczność FlightGear. |
Dzięki dostępowi do narzędzi Subversion (SVN), repozytorium kontroli wersji FGAddon może być wygodnym sposobem na uzyskanie statków powietrznych do wykorzystania w określonej wersji FlightGear bezpośrednio z oficjalnego źródła. Podczas korzystania z nocnych kompilacji lub z samodzielnie zbudowanego FlightGeara, należy używać najbardziej aktualnych wersji rozwojowych statków powietrznych, aby wersje były zgodne. Poniżej opisano sposób korzystania z oficjalnego repozytorium w celu uzyskania statków powietrznych z perspektywy użytkownika FlightGeara.
Przygotowanie
Aby korzystać z repozytorium FGAddon, należy zainstalować narzędzia Subversion:
- MS Windows: Zainstaluj jeden z wielu klientów Subversion. Na przykład SlikSVN jest jednym z najlepszych klientów dla wiersza poleceń i najlepszą do tworzenia statków powietrznych, a TortoiseSVN zapewnia przyjazny dla użytkownika graficzny interfejs (GUI) poprzez integrację z Eksploratorem Windows.
- Mac OS X: Zainstaluj oficjalnego klienta Subversion.
- GNU/Linux: Zainstaluj klienta Subversion za pomocą menedżera pakietów. Zazwyczaj będzie to pakiet o nazwie
subversion-*.{rpm,deb}.- Następujące polecenie powinno działać na platformie Raspberry Pi:
sudo apt-get install subversion. Zawiera ono również klienta.
- Następujące polecenie powinno działać na platformie Raspberry Pi:
Układ katalogu FGAddon
Aby wiedzieć, jak korzystać z repozytorium FGAddon, niezbędne jest zrozumienie układu katalogu repozytorium.
/trunk- w tym katalogu bazowym znajdują się rozwijane wersje statków powietrznych./branches/release-x.y.z/- katalogi te odpowiadają konkretnym stabilnym wydaniom FlightGeara.
Interfejs sieciowy repozytorium FGAddon umożliwia przeglądanie wszystkich statków powietrznych.
Pobieranie
Po pierwsze, wybierz statek powietrzny do pobrania. W tym przykładzie będzie to Bell Boeing V-22 Osprey.
Wiersz poleceń
Aby pobrać statek powietrzny dla FlightGeara w wersji 2020.3, wystarczy wpisać:
svn co https://svn.code.sf.net/p/flightgear/fgaddon/branches/release-2020.3/Aircraft/V22-Osprey
Aby pobrać statek powietrzny dla FlightGeara w wersji rozwojowej, wystarczy wpisać:
svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/V22-Osprey
Jeśli chcesz pobrać wszystkie 500+ statków powietrznych z repozytorium - pamiętaj, że będzie to ponad 6 GB - użyj następującego polecenia:
svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk flightgear-fgaddon
W przypadku korzystania ze stabilnej wersji FlightGeara, na przykład 2020.3, aby uzyskać wszystkie statki powietrzne FGAddon dla tej wersji, należy użyć opcji:
svn co https://svn.code.sf.net/p/flightgear/fgaddon/branches/release-2020.3 flightgear-fgaddon
Użycie GUI i TortoiseSVN
W przypadku korzystania z Subversion z graficznym interfejsem użytkownika (GUI), wystarczy skopiować jeden z powyższych adresów URL https:// i użyć go w GUI (każde GUI jest inne, ale pomoc można znaleźć w odpowiedniej dokumentacji). Dla unikalnego narzędzia TortoiseSVN, po prostu:
- W Eksploratorze Windows utwórz nowy, pusty folder dla statku powietrznego (lub kolekcji statków powietrznych).
- W nowym folderze kliknij prawym przyciskiem myszy i wybierz
SVN Checkout.... - Skopiuj i wklej adres URL, na przykład https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/V22-Osprey, Pozostaw wszystkie inne ustawienia bez zmian i potwierdź, klikając
OK.
Aby uzyskać więcej informacji, zobacz Dokumentację TortoiseSVN. Należy pamiętać, że podczas instalacji TortoiseSVN, istnieje także opcja instalacji narzędzia wiersza poleceń.
Latanie
Aby użyć nowo pobranego statku powietrznego, zapoznaj się z artykułem Instalowanie samolotów, pomijając instrukcje pobierania i rozpakowywania statku powietrznego.
Aktualizowanie
Mając pobraną kopię wersji rozwojowej /trunk statku powietrznego, można go zaktualizować do najnowszej wersji za pomocą polecenia:
svn up
Rozwój statków powietrznych
| Wskazówka Społeczność FlightGear zachęca do rozwijania statków powietrznych bezpośrednio w FGAddon. |
Skontaktuj się z autorami oryginalnego statku powietrznego
Pierwszym krokiem do rozwijania i udoskonalania statków powietrznych z oficjalnego hangaru FlightGear lub z jednego z prywatnych hangarów jest nawiązanie kontaktu z autorem (autorami) oryginalnego statku powietrznego. Ich imiona można znaleźć w pliku *-set.xml, w tagu XML <authors>. Często kontaktowy adres e-mail będzie wymieniony w pliku README lub innym pliku tekstowym w katalogu bazowym statku powietrznego. Jeśli tak nie jest, kontakt można czasem nawiązać za pośrednictwem listy mailingowej. Kontakt z oryginalnymi autorami jest ważny, aby sprawdzić, czy statek powietrzny jest obecnie aktywnie rozwijany i czy można dołączyć do zespołu programistów.
Konto na SourceForge
Aby pracować nad oficjalną kolekcją statków powietrznych, należy najpierw założyć konto na SourceForge. Umożliwi to bezpośrednie zatwierdzanie w repozytorium FGAddon, jeśli przyznano Ci dostęp do zatwierdzania, albo pracę w ramach zespołu programistów. Proces rejestracji jest błyskawiczny, a infrastruktura deweloperska SourceForge i usługi deweloperskie będą dostępne w mniej niż minutę.
Dostęp do zatwierdzania zmian
Przed uzyskaniem dostępu do zatwierdzania zmian, należy podjąć wszelkie starania, aby skontaktować się z oryginalnym autorem (autorami) w celu ustalenia, czy statek powietrzny jest aktywnie rozwijany. Jeśli to się nie powiedzie, zapisz się na listę mailingową programistów i poproś tam o pomoc. Jeśli statek powietrzny ma aktualnego opiekuna, zostaniesz poinstruowany, jak kontynuować jego rozwój. W przeciwnym razie zapytaj, czy ktoś może zgłosić się na ochotnika, by poprowadzić Cię przez proces zostania deweloperem statku powietrznego z pełnym dostępem do wykonywania zatwierdzeń.
Aby uzyskać dostęp do zatwierdzania zmian, musisz najpierw:
- Zademonstrować swoje możliwości i umiejętności deweloperskie.
- Wykazać, że rozumiesz Dokument dotyczący zasad FlightGear.
- Wykazać zrozumienie kwestii związanych z licencjami GPL i udowodnić, że można Ci zaufać, że nie używasz materiałów chronionych prawem autorskim, które nie są objęte licencją GPL.
- Zdobyć zaufanie społeczności FlightGear.
Te łatwe do przeskoczenia przeszkody mają po prostu na celu ochronę przed uszkodzeniem repozytorium lub zanieczyszczeniem go nielegalną zawartością.
Aby zmiany zostały zatwierdzone w repozytorium FGAddon, powinieneś omówić i skoordynować z autorem oryginalnego statku powietrznego lub swoim mentorem najlepszy sposób postępowania. W zależności od scenariusza dewelopmentu, może to być prośba o scalenie, transfer plików, prymitywny system łatek lub inny dogodny sposób. Gdy uznasz, że udowodniłeś swoje umiejętności i posiadasz wiedzę na temat licencji GPL, powinieneś napisać wiadomość na listę dyskusyjną deweloperów z pytaniem, czy możesz uzyskać dostęp do zatwierdzania, podając swoją nazwę użytkownika SourceForge.
Lista mailingowa commitlog
Aby śledzić wszystkie zmiany zachodzące w repozytorium FGAddon, zapisz się na dedykowaną listę mailingową commitlog. Na każde zatwierdzenie wysyłana jest jedna wiadomość e-mail.
Narzędzia kontroli wersji
Aby uzyskać dostęp do FGAddon i używać go do rozwoju statków powietrznych, potrzebne są narzędzia kontroli wersji Subversion lub SVN. Alternatywnie git-svn zapewnia interfejs dla tych, którzy wolą narzędzia kontroli wersji git.
Subversion
Konfiguracja
Hangar samolotów FGAddon jest przechowywany w zdalnym repozytorium Subversion znajdującym się w infrastrukturze SourceForge, dlatego najprościej jest użyć narzędzi SVN do rozwoju statków powietrznych, co spowoduje najmniej problemów. Zobacz sekcję Instalacji Subversion, aby skonfigurować łańcuch narzędzi.
Pobranie repozytorium
Pierwszym krokiem jest pobranie ('checkout') kopii z głównej gałęzi repozytorium ('trunk') lub jednego ze statków powietrznych z głównej gałęzi ('trunk'):
svn co <url> <dir>
Aby użyć odpowiedniego adresu URL, należy wybrać jeden ze scenariuszy dewelopmentu i znaleźć adres URL w tej sekcji. To polecenie utworzy lokalną kopię repozytorium subversion w podanym katalogu <dir>. Należy pamiętać, że będzie ona zawierać tylko część repozytorium FGAddon określoną w adresie URL. Oznacza to, że Subversion pozwala na pobranie całego zdalnego repozytorium labo tylko pojedynczego pliku.
Informacje i historia
W dowolnym momencie, aby wyświetlić informacje o lokalnym repozytorium, wpisz:
svn info
Aby zobaczyć historię pobranej kopii repozytorium, wpisz jedną z poniższych opcji:
svn log
svn log | less
svn log -v | less
Codzienne użytkowanie
Głównym poleceniem Subversion, którego będziesz używać, jest:
svn add <path>
Spowoduje to zarejestrowanie pliku lub katalogu <path> w lokalnym repozytorium, aby umożliwić jego późniejsze zatwierdzenie i wysłanie do zdalnego repozytorium.
Aby przenieść lub zmienić nazwę pliku lub katalogu, użyj:
svn mv <path1> <path2>
Powinno to być używane zamiast normalnego przenoszenia plików/zmiany nazwy, aby zmiana była śledzona w lokalnym repozytorium.
Aby usunąć plik z lokalnego repozytorium, wpisz:
svn rm <path>
Aby sprawdzić aktualny stan lokalnego repozytorium, wpisz:
svn st
Aby zaktualizować lokalne repozytorium o zmiany w repozytorium zdalnym, wpisz:
svn up
Zatwierdzanie zmian
Wszystkie powyższe operacje mają miejsce tylko na lokalnej kopii repozytorium - zdalne repozytorium FGAddon na SourceForge nie będzie wiedziało nic o tych zmianach. Aby wysłać wszystkie zmiany do FGAddon, należy je zatwierdzić:
svn ci
Spowoduje to otwarcie edytora umożliwiającego napisanie informacyjnego komunikatu dziennika zatwierdzeń. Podczas zatwierdzania najlepiej jest wykonywać małe modułowe zatwierdzenia, tak aby każde zatwierdzenie odpowiadało pojedynczemu celowi. Zauważ, że możesz zatwierdzać zmiany do FGAddon tylko jeśli masz dostęp do zatwierdzania zmian.
Rozgałęzienie
Koncepcja rozgałęzień Subversion jest obecnie używana tylko w projekcie FlightGear do przechowywania stabilnych wydań. Jeśli jednak jesteś ciekawy rozgałęzień, zobacz rozdział Rozgałęzianie i scalanie w podręczniku Subversion oraz skrypt svnmerge.py, który może znacznie uprościć ten proces.
Git-svn
Narzędzie git-svn jest przydatne dla tych, którzy są już zaznajomieni z korzystaniem z repozytoriów git, lub tych, którzy chcą mieć swój prywatny plac zabaw dla rozwoju statków powietrznych. Git-svn zapewnia pomost między zdalnym repozytorium FGAddon Subversion a lokalnym repozytorium git. Dla osób niezaznajomionych z git, most git-svn wraz z repozytorium git jest znacznie bardziej skomplikowany w użyciu niż natywne narzędzia Subversion. Aby uzyskać więcej informacji na temat korzystania z git, zobacz Jak używać gita. Poniżej założymy, że tylko jeden statek powietrzny będzie przechowywany w lokalnym repozytorium git.
Konfiguracja
Rozproszony system kontroli wersji git musi być najpierw zainstalowany.
Klonowanie pojedynczego statku powietrznego
Pierwszym krokiem jest "sklonowanie" kopii jednego ze statków powietrznych z głównego katalogu Subversion:
git svn clone <aircraft_url>
Aby użyć odpowiedniego adresu URL statku powietrznego, należy wybrać jeden ze scenariuszy dewelopmentu i znaleźć adres URL w tej sekcji. Adres URL zależy od statusu dostępu do zatwierdzenia FGAddon. Polecenie clone utworzy lokalne repozytorium git zawierające wyłącznie interesujący nas statek powietrzny i zainicjuje most git-svn.
Informacje i historia
W dowolnym momencie, aby wyświetlić informacje o lokalnym repozytorium, wpisz:
git svn info
git branch -vva
git remote -v
Aby zobaczyć historię pobranej kopii repozytorium, wpisz:
git log
Codzienne użytkowanie
Główne polecenie git, które będzie używane to:
git add <path>
Spowoduje to zarejestrowanie pliku lub katalogu <path> w lokalnym repozytorium, aby umożliwić jego późniejsze zatwierdzenie w lokalnym repozytorium git.
Aby przenieść lub zmienić nazwę pliku lub katalogu, użyj:
git mv <path1> <path2>
Należy jednak pamiętać, że historia git nie jest tak solidna jak historia svn. Zobacz sekcję przenoszenie plików/zmiana nazw w git-svn by dowiedzieć się jak lepiej wykonać tę operację.
Aby usunąć plik z lokalnego repozytorium, wpisz:
git rm <path>
Aby zobaczyć aktualny stan lokalnego repozytorium, wpisz:
git status
Zatwierdzanie zmian
Ponieważ git jest rozproszonym systemem kontroli wersji, zmiany są zatwierdzane w lokalnym repozytorium git.
git commit
Spowoduje to otwarcie edytora umożliwiającego napisanie informacyjnego komunikatu dziennika zatwierdzeń. Zatwierdzenie jest lokalne i nie zostanie wysłane do FGAddon.
Dedykowana gałąź FGAddon
W powyższych przykładach założono tylko jedną gałąź w repozytorium. Jeśli pożądana jest interakcja ze zdalnym repozytorium git lub rozgałęzienie w lokalnym repozytorium git, wymagana jest inna strategia. Powodem jest to, że gałąź, która synchronizuje się z FGAddon musi zachować liniową historię. Oznacza to, że dozwolone jest tylko wybieranie pożądanych zmian do takiej gałęzi.
W tym przykładzie w lokalnym repozytorium git zostaną utworzone dwie gałęzie:
fgaddon- ta gałąź będzie przeznaczona do synchronizacji FGAddon i zachowa liniową historię.master- główna gałąź do rozwoju statków powietrznych, pozwalająca na scalanie i inne nieliniowe operacje historyczne.
Zakładając nowo sklonowane repozytorium, utwórz gałąź fgaddon z:
git branch fgaddon
I przełącz się na tę gałąź:
git checkout fgaddon
Synchronizacja FGAddon może być następnie wykonana na tej gałęzi. Aby pobrać zmiany z gałęzi głównej, użyj cherry-pick, aby zastosować sekwencyjnie uporządkowaną listę skrótów zatwierdzeń:
git cherry-pick <commit hash 1>
git cherry-pick <commit hash 2>
git cherry-pick <commit hash 3>
...
Aby wyświetlić listę zatwierdzeń, które zostaną wysłane do FGAddon, wpisz:
git log git-svn..HEAD
I aby zobaczyć zmiany jako pojedynczy diff:
git diff git-svn..HEAD
Synchronizacja
Aby wysłać zmiany do zdalnego repozytorium FGAddon, należy najpierw przejść do dedykowanej gałęzi fgaddon:
git checkout fgaddon
Upewnij się, że lokalne repozytorium git-svn jest aktualne ze wszystkimi zmianami, które zaszły w FGAddon:
git svn rebase
Następnie wypchnij lub dcommituj zmiany do FGAddon za pomocą:
git svn dcommit
Braki git-svn
Ostrzeżenie Wykonanie git-svn clone z /trunk/ lub całego repozytorium nie jest zalecane, ponieważ zostanie pobrana cała historia repozytorium, co spowoduje powstanie ogromnego lokalnego repozytorium, a także znacznie obciąży infrastrukturę open source FlightGear.
|
Ważne jest, aby zrozumieć, że istnieje wiele operacji, w których git-svn jest niewystarczający. W wielu przypadkach należy użyć narzędzi SVN.
Kopiowanie plików między statkami powietrznymi
| Uwaga Git-svn nie zachowuje historii kopiowania plików normalnie obecnej w repozytorium Subversion. |
Najważniejszym problemem jest kopiowanie zawartości z innych statków powietrznych FGAddon. W tym przypadku potrzebny będzie dostęp do zatwierdzania FGAddon i lokalna kopia svn repozytorium. Najpierw zsynchronizuj repozytoria, zatwierdzając wszystkie zmiany z powrotem do FGAddon:
git svn dcommit
Następnie w lokalnym repozytorium svn skopiuj plik:
svn cp Aircraft/<aircraft1>/<file_path1> Aircraft/<aircraft2>/<file_path2>
I zatwierdzić zmianę:
svn ci
Wróć do lokalnego repozytorium git-svn i pobierz nowe pliki:
git svn rebase
Korzystanie z narzędzi Subversion pozwala uniknąć znacznego wzrostu rozmiaru zaplecza repozytorium FGAddon, ponieważ kopie SVN są tanie.
Przenoszenie lub zmiana nazwy plików
| Uwaga Git-svn nie zawsze zachowuje historię przenoszenia lub zmiany nazwy plików, która jest zwykle obecna w repozytorium Subversion. |
Problem ten wynika z faktu, że historia SVN jest bardziej solidna niż historia git. Polecenia svn mv i git mv nie są równoważne. Polecenie Subversion przechowuje historię przeniesień bezpośrednio w repozytorium, podczas gdy git tego nie robi (git zamiast tego używa metod heurystycznych, aby spróbować wykryć historię po zatwierdzeniu). Rezultatem używania git-svn jest to, że często przeniesienie nie zostanie wykryte, a historia FGAddon pokaże, że jeden plik lub katalog został usunięty, a inny dodany. Powoduje to również wzrost rozmiaru zaplecza repozytorium, podczas gdy svn mv nie spowoduje znaczącego wzrostu rozmiaru. Jeśli chcesz mieć lepszy zapis historyczny w repozytorium FGAddon i dbać o zaplecze repozytorium, zaleca się tymczasowe przejście na narzędzia Subversion. Po pierwsze, należy zsynchronizować repozytoria:
git svn dcommit
Następnie w lokalnym repozytorium SVN przenieś lub zmień nazwę pliku:
svn mv Aircraft/<aircraft>/<file_path1> Aircraft/<aircraft>/<file_path2>
I zatwierdzić zmianę:
svn ci
Z powrotem w lokalnym repozytorium git-svn, pobierz zmiany za pomocą:
git svn rebase
Kopiowanie plików w obrębie jednego statku powietrznego
Tak jak polecenie svn mv przechowuje informacje o przeniesieniu bezpośrednio w repozytorium, tak samo svn cp przechowuje informacje o kopiowaniu. Dlatego jeśli chcesz powielić plik tekstowy i zmodyfikować go, użycie natywnych narzędzi Subversion zamiast git-svn do tej operacji pozwala na trwałe zachowanie historii pliku w repozytorium FGAddon.
Właściwości Subversion
Uwaga Git-svn obsługuje obecnie tylko właściwość svn:executable, wszystkie inne właściwości są ignorowane i nie mogą być dodawane, zmieniane ani usuwane w klonie git-svn statku powietrznego.
|
Wewnętrznie Subversion identyfikuje pliki binarne za pomocą właściwości repozytorium svn:mime-type. Ponieważ jednak git-svn nie może ustawić tej właściwości podczas korzystania z polecenia git add, w rezultacie pliki binarne będą traktowane jako tekst. Różnice binarne będą widoczne podczas korzystania z svn diff lub git diff, a różnica binarna zostanie pokazana w komunikatach listy mailingowej commitlog. Ponieważ problem ten nie jest unikalny dla git-svn, aby obejść ten problem należy zapoznać się z sekcją Binarny diff.
Protokoły inne niż svn+ssh
Polecenie git svn init replikuje całą historię statku powietrznego do lokalnego repozytorium. Jako część tego procesu, generuje git commit ID lub hash dla każdej rewizji Subversion. Problem polega na tym, że git commit ID zależy od protokołu używanego do odczytu z repozytorium Subversion (prawdopodobnie jest to błąd gita). Stąd:
git svn init svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aircraft>
i
git svn init https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aircraft>
spowoduje powstanie dwóch różnych i niekompatybilnych repozytoriów git, mimo że zawierają one te same dane. Niekompatybilność nie jest od razu widoczna, ale będzie problemem później. Załóżmy, że ktoś z dostępem tylko do odczytu do FGAddon używa metody https, a następnie prosi opiekuna FGAddon o zatwierdzenie swoich zmian. Opiekun naturalnie używa svn+ssh, ponieważ jest to jedyny protokół przyznający uprawnienia do zapisu. Gdy opiekun spróbuje scalić klon https z własnym klonem svn+ssh, git będzie narzekał, że oba repozytoria nie mają wspólnej historii i oznaczy każdą zmianę jako konflikt.
Dlatego jeśli planujesz wprowadzić jakiekolwiek zmiany w statku powietrznym, upewnij się, że używasz svn+ssh, nawet jeśli nie masz jeszcze uprawnień do zatwierdzania w FGAddon. svn+ssh nie wymaga uprawnień do zapisu, wymaga jedynie identyfikatora użytkownika SourceForge.
Koncepcje rozwoju FGAddon
Nowy statek powietrzny
Aby dodać nowy statek powietrzny do repozytorium FGAddon, wymagane są narzędzia SVN. Jeśli napotkasz problemy z właściwością svn:mime-type podczas dodawania nowego statku powietrznego, zobacz sekcję problemy z mime-type, aby dowiedzieć się, jak rozwiązać ten problem. Lub jeśli masz problem z właściwością svn:executable, zobacz sekcję opisującą problem z flagą wykonywalności.
svn import
Ostrzeżenie Polecenie svn import opisane w niniejszym rozdziale, wyśle całą zawartość określonego katalogu bezpośrednio do FGAddon bez ostrzeżenia i bez możliwości anulowania operacji. Dlatego należy zachować szczególną ostrożność podczas określania katalogu do przesłania do FGAddon, a także docelowego katalogu FGAddon. Zobacz sekcję svn add poniżej dla bezpieczniejszego sposobu dodawania nowego statku powietrznego.
|
Polecenie svn import jest najłatwiejszą w użyciu metodą i nie wymaga pobrania lokalnej kopii repozytorium. Aby rozpocząć:
- Utwórz pusty lokalny katalog dla statku powietrznego.
- Skopiuj pliki statku powietrznego do tego katalogu.
- Dokładnie sprawdź wszystkie pliki, aby upewnić się, że nie ma żadnych ukrytych lub tymczasowych plików, które nie powinny zostać przesłane do FGAddon.
Zakładając jako przykład statek powietrzny Dead Simple Human Powered Airplane (DaSH PA lub "DaSH"), znajdujący się w katalogu DaSH/, w wierszu poleceń uruchom:
svn import DaSH/ svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DaSH/ -m \
"Initial import of the DaSH human powered aircraft.\n\nFor details see the forum thread at http://forum.flightgear.org/viewtopic.php?f=4&t=24495 ."
Gdzie <username> to nazwa użytkownika SourceForge. Spowoduje to dodanie wszystkich plików do FGAddon z komunikatem dziennika zatwierdzeń z wierszem podsumowania Initial import of the DaSH human powered aircraft., po którym następuje pusta linia, a następnie szczegółowy opis wskazujący pierwotną lokalizację lub dyskusja na temat samolotu.
Aby sprawdzić, czy statek powietrzny został pomyślnie dodany do repozytorium, użyj komendy:
svn list svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DaSH/
lub odwiedź repozytorium FGAddon.
Statek powietrzny można następnie pobrać w sposób opisany w sekcji Scenariusze dewelopmentu.
svn add
Jeśli dostępna jest lokalna kopia katalogu głównego FGAddon ('trunk'), można użyć polecenia svn add. Jest to o wiele bezpieczniejsze niż polecenie svn import, ponieważ zmianę można dwukrotnie sprawdzić przed zatwierdzeniem. W katalogu Aircraft/ lokalnego repozytorium utwórz katalog DaSH/. Może być pusty lub zawierać wszystkie pliki początkowego statku powietrznego. Następnie w wierszu poleceń dodaj statek powietrzny do lokalnego repozytorium:
svn add DaSH/
Następnie sprawdzić dwukrotnie zmiany przed ich zatwierdzeniem:
svn st
I wyślij zmiany do FGAddon:
svn ci
Otworzy się edytor tekstowy, często vi[9], w którym można napisać komunikat zatwierdzenia. Alternatywnie, komunikat dziennika zatwierdzenia może być określony w wierszu poleceń za pomocą:
svn ci -m "<subject_line>\n\n<detailed_description>"
Blokowanie zatwierdzeń przez pre-commit hook
Czasami podczas zatwierdzania w FGAddon, zatwierdzenie zostanie zablokowane i zostanie wypisana następująca informacja:
svn: E165001: Commit failed (details follow): svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:
Wynika to z obecności dwóch skryptów pre-commit hook repozytorium, które sprawdzają jakość zatwierdzenia, blokując je, jeśli plik tekstowy jest ustawiony na typ mime pliku binarnego lub jeśli ustawiona jest flaga wykonywalna. Skrypty te mają po prostu chronić repozytorium i utrzymywać je w czystości.
Problemy z mime-type
Czasami podczas próby zatwierdzenia plików do FGAddon przy użyciu narzędzi SVN, zatwierdzenie zostanie zablokowane z następującym komunikatem:
Sending dash-set.xml svn: E165001: Commit failed (details follow): svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output: Aborting the commit, the svn:mime-type property is labelling the following text files as binary: dash-set.xml: svn:mime-type=application/xml Before committing, please remove this property by typing 'svn propdel svn:mime- type file_name' for all affected files. This will allow the text files to be treated as text within the FGAddon repository. To avoid the svn:mime-type property being incorrectly set by your subversion client, the subversion configuration file at $HOME/.subversion/config or %appdata%\roaming\subversion\config should be edited and a new entry added to [auto-props] for each affected file type. In most cases, the problem is with XML files being labelled as "application/xml" by a library called libmagic. To override this, add the following to the svn config file: *.xml = svn:mime-type=text/xml svn: E165001: Your commit message was left in a temporary file: svn: E165001: '/flightgear/repo_testing/svn-commit.tmp'
Pomimo komunikatów o dodaniu lub wysłaniu plików, w repozytorium FGAddon nie zajdą żadne zmiany. Ta wiadomość jest tworzona przez skrypt pre-commit hook repozytorium, który sprawdza, czy właściwość Subversion svn:mime-type jest ustawiona na liście znanych plików tekstowych. Jeśli typ MIME jest ustawiony na format binarny, to zatwierdzenie jest blokowane. Powodem tego bloku jest ochrona repozytorium. Nowsi klienci SVN korzystają z biblioteki trzeciej znanej jako libmagic, która wykrywa pliki XML samolotu jako pliki typu MIME binarnego application/xml. W rezultacie pliki XML są traktowane w repozytorium jako pliki binarne. Takie zachowanie jest całkowicie niepożądane, ponieważ zmian nie można śledzić na liście mailingowej commitlogs ani w historii repozytorium, a rozmiar zatwierdzeń staje się o rząd wielkości większy. Dlatego to błędne zachowanie zostało zablokowane w celu ochrony projektu FlightGear. Aby usunąć problem, postępuj zgodnie z instrukcjami zawartymi w komunikacie i korzystając z narzędzi wiersza poleceń wpisz:
svn propdel svn:mime-type <file_name>
Powtórz tę czynność dla każdego pliku tekstowego wymienionego w komunikacie o błędzie. Następnie zatwierdź ponownie, korzystając z komunikatu zatwierdzenia zapisanego w pliku svn-commit.tmp. Nazwa pliku komunikatu zostanie wyświetlona w komunikacie o niepowodzeniu zatwierdzenia, ale najpierw sprawdź jego zawartość:
cat svn-commit.tmp
I ponownie wykonaj zatwierdzenie:
svn ci -F svn-commit.tmp
Plik konfiguracyjny Subversion
Automatyczne ustawienie właściwości svn:mime-type może być kontrolowane poprzez modyfikację pliku config Subversion. Najpierw w sekcji [miscellany] upewnij się, że właściwości automatyczne są włączone:
enable-auto-props = yesNastępnie w sekcji [auto-props] dodaj:
*.ac = svn:mime-type=text/plain
*.eff = svn:mime-type=text/xml
*.frag = svn:mime-type=text/plain
*.nas = svn:mime-type=text/plain
*.osgx = svn:mime-type=text/xml
*.svg = svn:mime-type=text/svg+xml
*.txt = svn:mime-type=text/plain
*.vert = svn:mime-type=text/plain
*.xhtml = svn:mime-type=text/xml
*.xml = svn:mime-type=text/xml
*.xsl = svn:mime-type=text/xmlTe wszystkie pliki tekstowe, skrypt przechwytujący sprawdzi, czy typ MIME jest ustawiony na format tekstowy, chociaż w przyszłości prawdopodobnie zostaną dodane nowe pliki tekstowe. Te zmiany można zapisać w pliku konfiguracyjnym użytkownika znajdującym się w ~/.subversion/config (lub %USERPROFILE%\AppData\Roaming\Subversion\config w systemie Windows) lub jeśli plik konfiguracyjny użytkownika nie jest ustawiony, to można użyć globalnego pliku konfiguracyjnego w katalogu /etc/subversion/config (lub %APPDATA%\Subversion\config w systemie Windows).
Flaga wykonywalności
Kolejnym komunikatem blokującym podczas próby zatwierdzenia plików do FGAddon przy użyciu narzędzi SVN jest:
Adding dash-set.xml Transmitting file data .svn: E165001: Commit failed (details follow): svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output: The svn:executable property is set on the files ['dash-set.xml'], aborting the commit. The current policy is that no executable files are allowed in FGAddon. Before committing, please remove this property by typing 'svn propdel svn:executable file_name' for all affected files. Or to remove it recursively from all files to be committed, in your aircraft directory type 'svn propdel svn:executable -R'. To avoid the svn:executable property being set by your subversion client, on GNU/Linux and Mac OS X systems simply make sure that the file's execute bit is not set before adding the file to be committed. svn: E165001: Your commit message was left in a temporary file: svn: E165001: '/flightgear/repo_testing/svn-commit.tmp'
Prawdopodobnie będzie to widoczne tylko w systemach macOS i GNU/Linux. Ta wiadomość jest wyświetlana przez skrypt pre-commit przed zatwierdzeniem, który sprawdza, czy właściwość Subversion svn:executable jest ustawiona, jeśli tak, zatwierdzenie jest blokowane. Jest to środek bezpieczeństwa, ponieważ żadne pliki statku powietrznego nie powinny być wykonywalne. Aby usunąć problem, postępuj zgodnie z instrukcjami zawartymi w komunikacie i korzystając z narzędzi wiersza poleceń wpisz:
svn propdel svn:executable -R
Następnie zatwierdź ponownie, używając komunikatu zatwierdzenia zapisanego w pliku svn-commit.tmp. Nazwa pliku komunikatu zostanie zgłoszona w komunikacie o niepowodzeniu zatwierdzenia, ale najpierw sprawdź jego zawartość:
cat svn-commit.tmp
I ponownie wykonaj zatwierdzenie:
svn ci -F svn-commit.tmp
Binarny diff
| Ostrzeżenie Nieprawidłowe ustawienie lub brak właściwości mime-type w pliku binarnym spowoduje diff binarny. |
Patrząc na wyjście svn diff (lub git diff, jeśli używasz git-svn), a także podczas czytania wiadomości z listy mailingowej commitlog, możesz zobaczyć dużą liczbę nierozpoznawalnych znaków. Jest to wynik tak zwanej różnicy binarnej, która pokazuje różnice w plikach binarnych tak, jakby były tekstem. Chociaż nie stanowi to problemu dla działania repozytorium, jest to problem estetyczny, który utrudnia przegląd zmian.
Aby rozwiązać problem, należy najpierw zidentyfikować pliki binarne z brakującą właściwością svn:mime-type. Możesz użyć następującego polecenia subversion:
svn propget svn:mime-type <file_name>
Ponieważ sprawdzanie każdego pliku z osobna może być żmudne, poniższy skrypt Pythona upraszcza i automatyzuje proces identyfikacji wszystkich plików binarnych z błędem typu MIME:
svn:mime-type.Naprawianie problemu
Ponieważ git-svn nie może ustawić ani zmienić właściwości svn:mime-type, wymagane jest pobranie kopii statku powietrznego za pomocą SVN. Właściwość można następnie ustawić na domyślny binarny typ MIME za pomocą:
svn propset svn:mime-type "application/octet-stream" <file_name>
Alternatywnie, poniższy zestaw poleceń powłoki może być użyty do zautomatyzowania procesu:
svn:mime-type dla zestawu znanych plików binarnych.Usługi deweloperskie SourceForge
Projekt FlightGear jest hostowany w infrastrukturze open source SourceForge. Ten rozdział przedstawia niektóre z przydatnych narzędzi, z których można skorzystać. SourceForge składa się z dwóch kategorii usług:
- Infrastruktura projektu
- Projekt FlightGear korzysta z usług projektowych SourceForge. Usługi te są przeznaczone dla samodzielnych projektów oprogramowania.
- Infrastruktura deweloperska
- Są to usługi dostępne dla każdego, kto posiada konto SourceForge, dostępne za pośrednictwem strony głównej SourceForge i dostępne dla wszystkich. Obejmuje to możliwość tworzenia wielu repozytoriów kontroli wersji (svn, git, hg), wiki, forów, zespołów programistycznych, blogów i modułów śledzenia zgłoszeń (dla błędów, pomocy technicznej, zadań itp.)
Zamiast tworzyć nowy projekt, każdy rozwój projektu FlightGear powinien opierać się na infrastrukturze deweloperskiej.
Repozytorium git dla deweloperów
Aby skonfigurować własne zdalne repozytorium git, tutaj w celu opracowania samolotu fkdr1:
- Na stronie Twojego profilu pod adresem https://sourceforge.net/u/<username>/profile/, przejdź do
Admin->Add New->Git. - Ustaw etykietę na
fkdr1 FGAddon git-svn repository. - Ustaw ścieżkę kodu na
code-fkdr1. Prefikscode-*ma na celu odróżnienie tego odforum-*,wiki-*i innych katalogów.
Repozytorium będzie znajdować się pod adresem https://sourceforge.net/u/<username>/code-fkdr1/ci/master/tree/.
Zespoły deweloperskie
Jeśli ty i grupa przyjaciół chcielibyście prywatnie rozwijać jeden ze statków powietrznych FGAddon jako zespół, zakładając, że skontaktowaliście się z autorami oryginalnego statku powietrznego, a ten nie jest aktywnie rozwijany, powinniście utworzyć zespół deweloperski SourceForge. Lider zespołu powinien zostać wyznaczony do skonfigurowania go na swoim koncie SourceForge. Zakładając, że chcesz rozwijać statek powietrzny "ornithopter", kroki są następujące:
- Idź go
Personal tools->Admin. - Kliknij na
User Permissions. - Kliknij na
Add a new groupna dole. - Ustaw nazwę jako
ornithopter, i zapisz. - Kliknij na
Addw grupieornithopteri dodaj nazwy wszystkich członków zespołu (muszą to być nazwy ich kont w SourceForge).
Po skonfigurowaniu prywatnego repozytorium na koncie lidera zespołu, należy skonfigurować zespół deweloperski dla repozytorium:
- Przejdź do repozytorium na swoim koncie SourceForge.
- Kliknij
Admin - <repository name>, i wybierzPermissions. - W sekcji
Write, usuńDeveloperi dodajornithopter. - Kliknij
Save.
Zespół deweloperów będzie miał wtedy dostęp do prywatnego repozytorium.
Komunikacja w zespole
To help with team development, the SourceForge infrastructure allows for multiple dedicated discussion forums to be created. This can either be within a SourceForge project or under a SourceForge users homepage. This allows the team leader to create a forum dedicated solely to the development of the aircraft of interest. Continuing with the ornithopter example, the steps for the team leader are simple:
Aby pomóc zespołowi, infrastruktura SourceForge umożliwia utworzenie wielu dedykowanych forów dyskusyjnych. Może ono znajdować się w projekcie SourceForge lub na stronie głównej użytkowników SourceForge. Dzięki temu lider zespołu może stworzyć forum poświęcone wyłącznie rozwojowi interesującego go statku powietrznego. Kontynuując przykład ornithopter, kroki lidera zespołu są proste:
- Na stronie Twojego profilu pod adresem https://sourceforge.net/u/<username>/profile/, idź do
Personal tools->Admin. - Kliknij opcję
Toolsw menu po lewej stronie. - Kliknij
Discussionw sekcjiClick to install. - Zmień etykietę na
Ornithopter forum, i ścieżkę na, np.forum-ornithopter. Prefiksforum-*ma na celu odróżnienie tego odcode-*,wiki-*i innych katalogów. - Kliknij
Save.
Więcej szczegółów podano w Dokumentacji Discussion na SourceForge.
Scenariusze dewelopmentu
Indywidualny deweloper
| Uwaga Scenariusz: Jesteś indywidualnym deweloperem i będziesz korzystać z natywnych narzędzi Subversion. |
Jest to zdecydowanie najprostszy scenariusz rozwoju i powinien być używany w większości przypadków. Jeśli korzystasz z klienta Subversion wspierającego wiersz poleceń, możesz pobrać pojedynczy statek powietrzny za pomocą:
svn co svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/wrightFlyer1903
Gdzie <username> to nazwa użytkownika SourceForge. Alternatywnie możesz pobrać wszystkie statki powietrzne za pomocą:
svn co svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk flightgear-fgaddon
Jeśli nie masz dostępu do zatwierdzania, wpisz jedną z poniższych opcji:
svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/wrightFlyer1903
svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk flightgear-fgaddon
Aby użyć nowego lokalnego repozytorium SVN, zobacz instrukcji subversion.
Indywidualny deweloper (git-svn)
| Uwaga Scenariusz: Jesteś indywidualnym deweloperem i będziesz korzystać z narzędzi git-svn. |
Jest to bardziej skomplikowane niż korzystanie z natywnych narzędzi SVN, ale może być przydatne bez dostępu do zatwierdzania FGAddon, ponieważ można wykonać wiele lokalnych zatwierdzeń, które zostaną wysłane do autorów oryginalnego statku powietrznego lub na listę mailingową/forum deweloperskie. Aby sklonować wybrany statek powietrzny do nowego repozytorium git, wpisz:
git svn clone svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aircraft>
Gdzie <username> to nazwa użytkownika infrastruktury, a <aircraft> to nazwa katalogu w repozytorium FGAddon. Obowiązuje to bez względu na to, czy masz uprawnienia do zatwierdzania.
Aby użyć nowego lokalnego repozytorium git, zobacz instrukcje git-svn i jego braki.
Przesyłanie do SourceForge
Aby udostępnić lokalne zmiany, można je przesłać do zdalnego repozytorium git w infrastrukturze SourceForge. W tym celu należy najpierw skonfigurować repozytorium git w swoim profilu SourceForge. Następnie dodać je jako zdalne:
git remote add origin ssh://<username>@git.code.sf.net/u/<username>/code-<aircraft>/
Następnie wyślij gałąź główną, w której znajdują się zmiany:
git push --set-upstream origin master
Zmiany w nowym repozytorium będą widoczne za pośrednictwem interfejsu internetowego pod adresem https://sourceforge.net/u/<username>/code-<aircraft>/ci/master/tree/.
Wysyłanie zmian z zewnętrznego repozytorium git do FGAddon
| Uwaga Scenariusz: Jesteś indywidualnym programistą z dostępem do zatwierdzeń FGAddon i chcesz przenieść zatwierdzenia wykonane w zdalnym repozytorium git do FGAddon przy użyciu tymczasowego lokalnego repozytorium git. |
Najpierw sklonuj statek powietrzny FGAddon do lokalnego repozytorium git-svn za pomocą:
git svn clone svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aircraft>
Spowoduje to utworzenie nowego lokalnego repozytorium git połączonego z FGAddon przez git-svn. Jeśli statek powietrzny jest nowy i nie ma go w FGAddon, zobacz instrukcje dodawania nowego statku powietrznego do FGAddon. Następnie skonfiguruj zdalne repozytorium git jako zdalne i pobierz je:
git remote add <name> <url>
git fetch
Gdzie <url> to adres URL zdalnego repozytorium git. Na koniec utwórz uporządkowaną listę wszystkich skrótów zatwierdzeń, które mają zostać wysłane do FGAddon, od najwcześniejszego do najpóźniejszego, i wybierz je ("cherry-picknij" je) do głównej gałęzi git-svn:
git cherry-pick <commit hash 1>
git cherry-pick <commit hash 2>
git cherry-pick <commit hash 3>
...
Należy pamiętać, że lokalne repozytorium git-svn powinno mieć tylko jedną gałąź master i składać się tylko z cherry-picking. Aby zobaczyć zmiany w kolejce do wysłania do FGAddon:
git log git-svn..HEAD
git diff git-svn..HEAD
Następnie, aby wysłać zmiany do FGAddon, należy najpierw pobrać wszelkie zdalne zmiany i wysłać zatwierdzenia:
git svn rebase
git svn dcommit
Następnie można usunąć tymczasowe repozytorium lokalne.
Połączenie istniejącego repozytorium git do FGAddon
| Uwaga Scenariusz: Jesteś indywidualnym programistą lub liderem zespołu z dostępem do zatwierdzania FGAddon i chcesz połączyć istniejące wcześniej zdalne repozytorium git z FGAddon, aby wysłać wszystkie zmiany z powrotem do FGAddon. |
Jeśli istnieje już zdalne repozytorium git zawierające opracowany statek powietrzny, możliwe jest połączenie go ze zdalnym repozytorium FGAddon za pomocą narzędzi git-svn. Poniższy sposób wykorzystuje technikę dedykowanej gałęzi FGAddon. Po pierwsze, należy skonfigurować most do FGAddon za pomocą git-svn w repozytorium per-statku powietrznego:
git svn init svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/<aircraft>
Gdzie <aircraft> jest nazwą katalogu statku powietrznego w FGAddon. Należy pamiętać, że ten krok można wykonać bez dostępu do zatwierdzania do FGAddon, używając zamiast tego adresu URL SVN tylko do odczytu, ale wtedy zmiany nie mogą zostać wypchnięte z powrotem do FGAddon (dcommitowane, jak to jest znane w terminologii git-svn). Pozwala to jednak na zintegrowanie zmian FGAddon ze zdalnym repozytorium git, ułatwiając w ten sposób przygotowanie zmian do przesłania w celu włączenia FGAddon za pomocą łatek wysłanych na listę mailingową lub wysłanych innymi kanałami.
Teraz pobierz bieżący stan ze zdalnego repozytorium FGAddon:
git svn fetch
Pobrana historia SVN znajduje się w zdalnej gałęzi remotes/git-svn. Aby zatwierdzić zmiany w SVN, potrzebujesz lokalnej gałęzi, która śledzi tę zdalną gałąź. Utwórz lokalną gałąź fgaddon, której będziesz używać do zatwierdzania aktualizacji:
git branch fgaddon remotes/git-svn
Po zatwierdzeniu nowych rzeczy w gałęzi master, aby przekazać je do FGAddon, przełącz się na gałąź fgaddon i zaktualizuj ją z SVN na wypadek, gdyby ktoś inny dokonał zmian statku powietrznego w zdalnym repozytorium FGAddon:
git checkout fgaddon
git svn rebase
Wybierz nowe zatwierdzenia z master do fgaddon, aby zachować liniową historię:
git cherry-pick <commit hash 1>
git cherry-pick <commit hash 2>
git cherry-pick <commit hash 3>
...
Aby zobaczyć zmiany ustawione w kolejce do wysłania do FGAddon jako zatwierdzenia lub diff, wpisz:
git log git-svn..HEAD
git diff git-svn..HEAD
Jeśli wszystko wygląda w porządku, dcommituj lokalne zatwierdzenia w gałęzi fgaddon, aby wysłać je do zdalnego repozytorium FGAddon SVN:
git svn dcommit
Przełącz się z powrotem do gałęzi głównej dla dewelopmentu lokalnego:
git checkout master
Aby pobrać zmiany z upstreamu, można po prostu pobrać je za pomocą:
git svn fetch
lub pobrać je i wyrównać (rebase) Twoją gałąź fgaddon do nich:
git checkout fgaddon
git svn rebase
Zespół deweloperów
| Uwaga Scenariusz: Wszyscy członkowie zespołu działają jako opiekunowie, a wszystkie zatwierdzenia są dokonywane bezpośrednio w FGAddon, przy użyciu svn lub git-svn. |
Najprostszym sposobem na pracę zespołową jest posiadanie przez każdego dewelopera kopi svn FGAddon lub kopi git-svn FGAddon, a każdy zatwierdza bezpośrednio do FGAddon. Komunikacja i koordynacja między członkami zespołu może odbywać się za pomocą forum SourceForge zorganizowanego przez lidera lub za pomocą FlightGear forum. W tym scenariuszu zespół musi przejąć inicjatywę i wszyscy ubiegają się o dostęp do zatwierdzeń FGAddon.
Prywatny zespół deweloperów (git-svn)
| Uwaga Scenariusz: Jeden z liderów zespołu działa jako opiekun prywatnego repozytorium git hostowanego w wewnętrznej infrastrukturze SourceForge, używając git-svn do wypchnięcia gałęzi fgaddon do FGAddon, a członkowie zespołu zatwierdzają bezpośrednio do prywatnego repozytorium git lub wysyłają żądania scalenia ze swojego rozwidlenia prywatnego repozytorium. |
Aby zachować wszystko we własnym zakresie, cała operacja będzie oparta na oficjalnej infrastrukturze i zdalnych repozytoriach w ramach profilu każdego użytkownika SourceForge (SF). Uwaga dla lidera zespołu — musisz utrzymywać liniową historię git-svn (co oznacza, że należy utworzyć dedykowaną gałąź FGAddon i ręcznie wybrać (cherry-pick) zmiany w tej gałęzi). W dalszej części jako przykład zostanie użyty statek powietrzny ornithopter.
Zespół
Po pierwsze, cały zespół powinien zalogować się na swoje konto SourceForge.
Lider zespołu
Konfiguracja prywatnego repozytorium
Te kroki musi podjąć lider zespołu. W swoim profilu użytkownika SourceForge skonfiguruj repozytorium git z etykietą Ornithopter FGAddon repozytorium git-svn i ścieżką kodu code-ornithopter. Następnie utwórz puste, lokalne repozytorium git:
$ mkdir ornithopter
$ cd ornithopter
$ git init
Połącz puste repozytorium z katalogiem ornithopter statku powietrznego w zdalnym repozytorium FGAddon i pobierz je za pomocą:
$ git svn init svn+ssh://<username>@svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/ornithopter
$ git svn fetch
Zastąp <username> swoją nazwą użytkownika SF. Skonfiguruj specjalną gałąź git-svn dla opiekuna FGAddon i dcommituj zmiany z powrotem do repozytorium:
$ git branch fgaddon remotes/git-svn
$ git checkout fgaddon
Następnie pobierz ornithopter z FGAddon:
$ git svn rebase
Aby zobaczyć bieżącą konfigurację lokalnego repozytorium git-svn, wpisz:
$ git branch -vva
$ git remote -v
$ git svn info
Następnie powróć do gałęzi głównej:
$ git checkout master
Na koniec skonfiguruj zdalne repozytorium git jako zdalne:
$ git remote add origin ssh://<username>@git.code.sf.net/u/<username>/code-ornithopter/
I wyślij gałąź master do zdalnego repozytorium git:
$ git push -u origin master
Aby zobaczyć nową konfigurację, wpisz:
$ git branch -vva
$ git remote -v
Repozytorium będzie znajdować się pod adresem https://sourceforge.net/u/<username>/code-ornithopter/ci/master/tree/. Należy pamiętać, że informacje git-svn przechowywane w katalogu .git/svn nie zostaną przesłane do zdalnego repozytorium SoureForge, dlatego link powrotny do FGAddon będzie obecny tylko w lokalnej kopii lidera zespołu . W razie potrzeby łącze git-svn można ponownie ustanowić później.
Konfiguracja zespołu
Skonfiguruj dedykowany zespół programistów i przyznaj im dostęp do repozytorium git-svn.
Wypychanie do FGAddon
Zatwierdzanie do FGAddon dotyczy lokalnego repozytorium git lidera zespołu. Historia w gałęzi fgaddon musi być liniowa, więc najlepszym rozwiązaniem jest wybieranie (cherry-picking). To pochodzi z sekcji Indywidualny deweloper (git-svn). W lokalnym repozytorium git przejdź do gałęzi fgaddon:
git checkout fgaddon
Pobierz wszelkie zmiany, które zaszły w FGAddon:
git svn rebase
Aby zobaczyć zatwierdzenia w gałęzi master, których nie ma w gałęzi fgaddon, wpisz jedno z:
git log HEAD..master
git log HEAD..master --pretty=oneline
Ręcznie wybierz zatwierdzenia, które mają zostać wysłane do FGAddon:
git cherry-pick <commit hash 1>
git cherry-pick <commit hash 2>
git cherry-pick <commit hash 3>
...
lub wykonaj cherry-pick z zakresem zatwierdzeń:
git cherry-pick <commit hash 1>^..<commit hash 8>
Następnie sprawdź, co ma zostać wysłane:
git log git-svn..HEAD
git diff git-svn..HEAD
Wyślij zmiany do FGAddon, wyślij zmiany gałęzi git fgaddon do zdalnego repozytorium git i przełącz się z powrotem do gałęzi głównej:
git svn dcommit
git push
git checkout master
Na koniec scal zatwierdzenia git svn z ich nowymi hashami z gałęzi fgaddon i wyślij je do zdalnego repozytorium git:
git merge fgaddon
git push
Członkowie zespołu
Praca z repozytorium
Każdy członek zespołu powinien sklonować prywatne repozytorium git:
$ git clone ssh://<username>@git.code.sf.net/u/<username_leader>/code-ornithopter/ ornithopter
Zastąp <username> swoją nazwą użytkownika SourceForge, a <username_leader> nazwą użytkownika SourceForge lidera zespołu.
Rozwidlanie i prośby o scalenie
Alternatywnie, każdy członek zespołu może rozwidlić repozytorium git na swoim koncie SourceForge:
- Idź do https://sourceforge.net/u/<username>/code-ornithopter/ci/master/tree/, gdzie
<username>to nazwa użytkownika SourceForge lidera zespołu. - Kliknij
Fork. - Ustaw punkt montowania na
code-ornithopteri zmień etykietę według własnego uznania.
Zatwierdzaj i wysyłaj zmiany do swojego forka, a następnie wysyłaj żądania scalenia, klikając przycisk Request Merge.
Odnośniki
- ↑ David Murr (9 kwi, 1996). Propozycja FlightGear 1.0: "A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@". Opublikowana na grupie dyskusyjnej rec.aviation.simulators.
- ↑ David Murr (1996). Propozycja FlightGear 2.0: FLIGHT GEAR "This truly is as real as it gets!" - propozycja nowego symulatora lotu - WERSJA 2.0.
- ↑ David Murr (29 paź, 1996). Propozycja FlightGear 3.0: FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0 - Wednesday, 10.30.96, "The future of flight simulation is here". Opublikowana na flight-gear@infoplane.com liście mailingowej.
- ↑ David Murr (11 wrz, 1998). Propozycja FlightGear 3.0.1: FLIGHT GEAR FLIGHT SIMULATOR, revision 3.0.1 - Friday, Sep.11.98, "The future of flight simulation is here".
- ↑ Curtis Olson (28 wrz, 2015). Re: A PROPOSAL FOR A NEW FLIGHT SIMULATOR - home built!@. Opublikowane na forum FlightGear.
- ↑ James Turner (20 maj, 2010). [Flightgear-devel] Re: Flightgear git repositories (was Re: GIT or CVS - Confusion) Opublikowane na liście mailingowej flightgear-devel.
- ↑ Cedric Sodhi (Oct 18, 2011) [Flightgear-devel] FGData Split Completed - a.k.a Life after the Split Opublikowane na liście mailingowej flightgear-devel.
- ↑ Dokument dotyczący polityki i mapy drogowej FlightGear, szkic dokumentu.
- ↑ Dokumentacja Vima