fbpx
devstyle.pl - Blog dla każdego programisty
devstyle.pl - Blog dla każdego programisty
4 minut

Linkowanie repozytoriów: svn externals


29.07.2009

Chyba każda firma ma zestaw własnych bibliotek czy konfiguracji pomagających tworzyć oprogramowanie w ten “jedyny właściwy”, wymyślony przez kogoś ważnego sposób. Narzędzia te wykorzystywane są przez wszystkie tworzone projekty oraz nieustannie rozwijane wraz z ewolucją wymagań czy zmianami na jakimś ważnym stanowisku :). Ale jak dopilnować, żeby nie mnożyły się identyczne (a z czasem oczywiście rozjeżdżające się) KOPIE takich wspólnych plików? Taka sytuacja – każdy projekt w osobnym repozytorium, z własną kopią owych “shared” – to jest prawdziwa sodoma i gomora.
Lekiem na takie zło jest funkcjonalność Subversion zwana Externals. Oficjalną dokumentację można przeczytać tam, poniżej natomiast zobaczmy jakiś przykład wykorzystania tego mechanizmu.

Na potrzeby prezentacji załóżmy, że nasza firma tworząca witryny internetowe trzyma swoje megawypasione biblioteki w katalogu Common. Aktualnie rozwijamy dwa projekty wykorzystujące zawarte tam funkcjonalności. Jeden z nich to stronka na zlecenie oszołomów protestujących przeciw koncertowi Madonny 15 sierpnia. Normalnie byśmy się z nimi nie zadawali z obawą przed zarażeniem jakąś dziwną chorobą, ale stojące za nimi siły niebieskie nieźle sypią groszem. Drugi projekt to portal powstający na cześć najlepszej księgi wszech czasów:

W najgorszej sytuacji mielibyśmy dwa repozytoria: po jednym dla każdego projektu, a w każdym lokalną kopię katalogu Common. Gdyby wysyłanie Madonny do piekła zaowocowało rozwinięciem tych bibliotek o jakieś ciekawe funkcjonalności (na przykład klasą nawiązującą bezpośrednie połączenie z komórką Ojca T.R.), to Trylogia nijak by z nich skorzystać nie mogła z tego prostego powodu, że jej kopia nie jest w żaden sposób zaktualizowana. Wystarczy jednak, że Common wrzucimy do osobnego, trzeciego repozytorium i odpowiednio skonfigurujemy dwa pozostałe, a będziemy mieli jedną centralną lokalizację zawierającą wspólne funkcjonalności.

Naszym celem jest to, aby użytkownik ściągający lokalnie kopię repozytorium (tworzący working copy) nie musiał sobie zawracać głowy takimi bzdurami. Jedyne co musimy zrobić to odpowiednio edytować właściwości głównego katalogu obu projektów, dodając właściwość svn:externals z wartością wskazującą na docelowy katalog oraz repozytorium, z którym ma być synchronizowana jego zawartość:

Gdy teraz puścimy nasze zmiany na serwer, każdy kolejny Update będzie skutkował pobraniem danych z dwóch miejsc: zarówno repozytorium projektu, jak i repozytorium Common. Co więcej, dodajmy teraz do naszej lokalnej kopii jakiś plik:

Teraz aktualizacja całej lokalnej kopii drugiego projektu, Trylogii, zaktualizuje nam również dane z podlinkowanego repozytorium (oczywiście pod warunkiem, że dodamy mu analogiczną właściwość)! I o to dokładnie chodziło:

I to tyle. Bardzo proste, bardzo przydatne, a zdarza się, że niewykorzystywane.

P.S. Podczas tworzenia lokalnej kopii można wyłączyć kontakt z zewnętrznymi repozytoriami, służy do tego poniższa opcja (która teraz nie powinna już dla nikogo być tajemnicą):

Nie przegap kolejnych postów!

Dołącz do ponad 9000 programistów w devstyle newsletter!

Tym samym wyrażasz zgodę na otrzymanie informacji marketingowych z devstyle.pl (doh...). Powered by ConvertKit
Notify of
norrec
norrec

Witam,

osobiscie wyrzkostuje svn:externals wszedzie tam, gdzie sie da i wg mnie ta funkcjonalnosc jest podstawa korzystania z svna.

Co myslicie o wykorzystywaniu svn:externals do wersjonowania wspolnych plikow klas podczas rownoleglego tworzenia bibliotek na desktopy i mobile (przynajmniej w poczatkowej fazie projektu)?

Pozdrawiam!

procent

@norrec:
Wg mnie do utrzymywania synchronizacji pomiedzy projektami desktop/mobile wystarczajaca powinna byc funkcjonalnosc Add As Link (http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx). Plik mamy dolaczony do obu projektow, ale fizycznie istnieje tylko w jednym miejscu.

Moja książka

Facebook

Zobacz również