9.2 Git in ostali sistemi - Migracija na Git

Če ste prebrali prejšnji razdelek o uporabi git svn, lahko enostavno uporabite ta navodila za git svn clone repozitorija; nato prenehajte uporabljati strežnik Subversion, potisnite na novi strežnik Git in ga začnite uporabljati. Če želite zgodovino, lahko to dosežete, kakor hitro lahko povlečete podatke iz strežnika Subversion (kar lahko vzame nekaj časa).

Vendar uvažanje ni popolno; in ker bo vzelo nekaj časa, lahko tudi naredite, kakor je prav. Prvi problem so informacije avtorja. V Subversionu ima vsaka oseba, ki potrjuje, uporabnika na sistemu, ki je posnet v informacijah potrditve. Primeri v prejšnjem razdelku prikazujejo na nekaterih mestih schacon, kot je izpis blame in git svn log. Če želite preslikati to na boljše podatke avtorja v Gitu, morate preslikati uporabnike iz Subversiona na avtorje Git. Ustvarite datoteko imenovano users.txt, ki ima to preslikavo v naslednji obliki:

Da dobite seznam imen avtorjev, ki jih uporablja SVN, lahko poženete to:

To generira izpis dnevnika v formatu XML, nato obdrži samo vrstice z informacijami avtorja, opusti duplikate in izpusti značke XML. Očitno to deluje samo na napravi z nameščenimi grep, sort in perl. Nato preusmerite ta izpis v vašo datoteko users.txt, da lahko dodate enakovredne podatke uporabnika Git zraven vsakega vnosa.

To datoteko lahko ponudite git svn, da bolj točno pomaga preslikati podatke avtorja. Poveste lahko tudi, naj git svn ne vključuje metapodatkov, ki jih Subvestion običajno uvaža s podajanjem --no-metadata k ukazoma clone ali init. Ti metapodatki vključujejo git-svn-id znotraj vsakega sporočila potrditve, ki jih bo Git generiral med vnosom. To lahko napihne vaš dnevnik Git in ga naredi nekoliko nejasnega.

To naredi, da je vaš ukaz import videti naslednje:

Sedaj morate imeti lepši uvoz Subversiona v vašem direktoriju my_project. Namesto potrditev, ki so videti takole:

so videti takole:

Ne samo, da je polje Author videti veliko boljše, ampak tudi git-svn-id ni več tam.

Sedaj bi morali narediti tudi nekaj čiščenja po uvozu. Za eno stvar, bi morali počistiti čudne reference, ki jih je nastavil git svn. Najprej boste premaknili oznake, da so dejansko oznake namesto čudnih oddaljenih vej in nato boste premaknili preostanek vej, da so lokalne.

Da premaknete oznake, da so ustrezne oznake Git, poženite:

To vzame reference, ki so oddaljene veje in se začnejo z refs/remotes/tags/, ter jih naredi realne (enostavne) oznake.

Naslednje, premaknite preostanek referenc pod refs/remotes, da so lokalne veje:

Lahko se zgodi, da boste videli nekatere dodatne veje, ki nimajo pripone @xxx (kjer je xxx število), medtem ko boste v Subversion videli samo eno vejo. To je dejansko lastnost v Subversionu imenovana »peg-revisions«, kar je nekaj, za kar Git enostavno nima sintaktične protipostavke. Torej, git svn enostavno doda številko različice SVN k imenu veje na isti način, kot bi napisali, da naslovite SVN za peg-revision tiste veje. Če vas peg-revision ne skrbi več, jih enostavno odstranite:

Sedaj so vse stare veje prave veje Git in vse stare oznake so prave oznake Git.

Še nekaj je treba počistiti. Na žalost git svn ustvari dodatno vejo imenovano trunk, ki preslika privzete veje Subversiona, vendar pa kaže točka ref trunk na isto mesto kot master. Ker je master idiomatsko bolj Gitov, takole odstranite dodatno vejo:

Zadnja stvar, ki jo morate narediti, je dodati vaš novi strežnik Git kot daljavo in potisniti nanj. Tu je primer dodajanja vašega strežnika kot daljavo:

Ker želite dodati gor vse vaše veje in oznake, lahko sedaj poženete to:

Vse vaše veje in oznake bi morale biti na vašem novem strežniku Git z lepim in čistim uvozom.

Ker imate Mercurial in Git precej podobna modela za predstavitev verzij in ker je Git nekoliko bolj prilagodljiv, je pretvorba repozitorija iz Mercurial na Git precej enostavna z uporabo orodja imenovanega »hg-fast-export«, ki ga boste morali kopirati:

Prvi korak pretvorbe je dobiti polni klon repozitorija Mercurial, ki ga želite pretvoriti:

Naslednji korak je ustvariti datoteko preslikave avtorja. Mercurial je nekoliko bolj odpustljiv kot Git, zaradi česar bo dal polje avtorja za skupke sprememb, torej je to dober čas za čiščenje hiše. Generiranje tega je ukaz ene vrstice v lupini bash:

To bo vzelo nekaj sekund, odvisno od tega kako dolga je zgodovina vašega projekta in potem bo datoteka /tmp/authors videti nekako takole:

V tem primeru je ista oseba (Bob) ustvarila skupek sprememb pod štirimi različnimi imeni, ena izmed njih je dejansko videti v redu in ena od njih bi bila popolnoma neveljavna za potrditev Git. Hg-fast-export nam omogoča to popraviti s spremembo vsake vrstice v pravilo: "<input>"="<output>", kar preslika <input> v <output>. Znotraj nizov <input> in <output> so podprta vsa ubežana zaporedja, ki jih razume Python kodiran string_escape. Če datoteka s preslikavami avtorjev ne vsebuje prilegajočega se <input>, bo ta avtor posredovan naprej Gitu nespremenjen. Če so vsa uporabniška imena videti v redu, te datoteke sploh ne bomo potrebovali. V tem primeru želimo, da je naša datoteka videti takole:

Enaka datoteka preslikave se lahko uporabi za preimenovanje vej in oznak, ko ime Mercuriala to ne dovoljuje z Gitom.

Naslednji korak je ustvariti naš novi repozitorij Git in pognati izvozni skript:

Zastaviva -r pove hg-fast-export, kje najti repozitorij Mercurial, ki ga želimo pretvoriti, zastavica -A pa mu pove, kje najti datoteko preslikav avtorjev (datoteke preslikav vej in oznak so določene z zastavicama -B in -T flags). Skript prevede skupke sprememb Mercuriala in jih pretvori v skript za Gitovo lastnost »fast-import« (o kateri bomo govorili v podrobnosti nekoliko kasneje). To vzame nekaj časa (čeprav je veliko hitreje, kot bi bilo preko omrežja) in izpis je precej opisen:

To je večinoma vse, kar je. Vse oznake Mercuriala so bile pretvorjene v oznake Git in veje z zaznamki Mercurial so bili pretvorjeni v veje Git. Sedaj ste pripravljeni potisniti repozitorij na njegov novi strežniški dom:

Naslednji sistem, ki ga boste pogledali pri uvažanju, je Perforce. Kot smo govorili zgoraj, sta dva načina, da omogočimo Gitu in Perforcu govoriti drug z drugim: git-p4 in Perforce Git Fusion.

Če vaš sistem ni eden od zgoraj omenjenih, poiščite uvoznika na spletu — kakovostni uvozniki so na voljo za mnoge druge sisteme, vključno s CVS, Clear Case, Visual Source Safe in celo imenikom arhivov. Če nobeno od teh orodij ne deluje za vas, ali imate bolj zapleteno orodje, ali pa potrebujete drugačen postopek uvoza, uporabite git fast-import. Ta ukaz preprosto prebere navodila iz standardnega vhoda za pisanje določenih podatkov Git. Na ta način je veliko lažje ustvariti objekte Git kot z uporabo surovih ukazov Git ali poskusom pisanja surovih objektov (za več informacij glejte poglavje Notranjost Gita). Na ta način lahko napišete uvozni skript, ki iz sistema, iz katerega uvažate, bere potrebne informacije in izpiše preprosta navodila na standardni izhod. Nato lahko to program poženete in njegov izhod preusmerite skozi git fast-import.

Za hitro demonstracijo boste napisali preprost program za uvažanje. Predpostavimo, da delate v mapi current, svoj projekt pa varnostno kopirate tako, da občasno kopirate mapo v varnostno kopijo back_YYYY_MM_DD z oznako datuma, in to želite uvoziti v Git. Vaša mapa je videti takole:

Če želite uvoziti Gitov direktorij, morate pregledati, kako Git shranjuje svoje podatke. Kot se morda spomnite, je Git v osnovi povezan seznam objektov potrditev, ki kažejo na posnetek vsebine. Vse, kar morate storiti, je povedati fast-import, kaj so posnetki vsebine, na kaj kažejo podatki potrditve in v kakšnem vrstnem redu gredo. Vaša strategija bo, da boste posamezne posnetke poiskali po vrstnem redu in za vsako mapo ustvarili potrditev z vsebino te mape, pri tem pa vsako potrditev povezali s prejšnjo.

Kot smo storili v Primer pravilnika, ki ga uveljavlja Git, bomo to napisali v Rubyju, ker gre za jezik, s katerim se običajno ukvarjamo, in ker je običajno enostaven za branje. Ta primer lahko precej enostavno napišete v katerem koli drugem jeziku, ki ga poznate — le ustrezne podatke morate izpisati v stdout. Če delate v sistemu Windows, bodite pozorni, da ne vnesete vsebnosti pomika na konec vrstice — git fast-import zelo natančno zahteva samo vrstice (LF), ne pa vsebnosti pomika s karetom (CRLF), ki jih uporablja Windows.

Najprej se boste premaknili v ciljni imenik in identificirali vsak podimenik, ki predstavlja posnetek, ki ga želite uvoziti kot potrditev. Za vsak podimenik se boste premaknili vanj in natisnili ukaze, ki so potrebni za izvoz. Osnovna zanka je videti tako:

V vaši metodi print_export v vsaki mapi zaženete funkcijo, ki vzame manifest in označbo (angl. mark) prejšnje različice posnetka in vrne manifest in označbo za trenutno različico; tako jih lahko pravilno povežete. »Označba« je izraz v fast-import, ki se nanaša na identifikator, ki ga daste potrditvi; vsakič, ko ustvarite potrditev, ji dodelite označbo, ki jo lahko uporabite za povezavo z drugimi potrditvami. Torej, prva stvar, ki jo morate storiti v vaši metodi print_export, je generirati označbo iz imena mape:

To boste naredili z ustvarjanjem polja direktorijev in uporabili vrednost indeksa kot označbo, saj mora biti označba celo število. Vaša metoda je videti takole:

Zdaj, ko imate celoštevilsko predstavitev svoje potrditve, potrebujete datum za metapodatke potrditve. Ker je datum izražen v imenu mape, ga boste razčlenili. Naslednja vrstica v vaši datoteki print_export je:

kjer je convert_dir_to_date definiran kot:

To vrne celoštevilsko vrednost za podatke v vsakem direktoriju. Zadnji del metapodatkov, ki ga potrebujete za vsako potrditev, so podatki potrjevalca, ki ga vgradite v kodo preko globalne spremenljivke:

Zdaj ste pripravljeni za začetek izpisa podatkov o potrditvi za svoj program uvažanja. Začetni podatki navajajo, da opredeljujete objekt potrditve in na kateri veji je, nato sledi oznaka, ki ste jo generirali, podatki o potrditelju in sporočilu potrditve, nato pa še prejšnja potrditev, če obstaja. Koda je videti tako:

Časovni pas zacementirate v kodo (-0700), ker je to enostavno. Če uvažate iz drugega sistema, morate časovni pas določiti kot odmik. Sporočilo potrditve mora biti izraženo v posebnem formatu:

Format sestoji iz podatka besede, velikosti podatkov, ki jih je treba prebrati, nove vrstice in nazadnje samih podatkov. Ker morate kasneje uporabiti isti format za določanje vsebine datoteke, ustvarite pomožno metodo export_data:

Vse, kar je še ostalo, je določiti vsebino datoteke za vsak posnetek. To je enostavno, saj imate vsak posnetek v mapi — lahko natisnete ukaz deleteall, nato pa vsebino vsake datoteke v mapi. Git bo nato ustrezno zabeležil vsak posnetek:

Opomba: Ker se mnogi sistemi nanašajo na svoje revizije kot spremembe med eno potrditvijo in drugo, lahko hitri uvoz vzame tudi ukaze z vsako potrditvijo, ki določajo, katere datoteke so bile dodane, odstranjene ali spremenjene ter kakšne so nove vsebine. Lahko bi izračunali razlike med posnetki in zagotovili samo te podatke, vendar je to bolj zapleteno — raje dajte Gitu vse podatke in ga pustite, da sam ugotovi. Če je to bolj primerno za vaše podatke, preverite stran priročnika fast-import za podrobnosti o tem, kako zagotoviti svoje podatke na ta način.

Format za naštevanje novih vsebin datotek ali določanje spremenjene datoteke z novimi vsebinami je naslednji:

Tukaj je način 644 (če imate izvršljive datoteke, morate zaznati in določiti namesto tega 755), in znotraj vrstice pove, da boste takoj po tej vrstici našteli vsebine. Vaša metoda inline_data je videti tako:

Ponovno uporabljate metodo export_data, ki ste jo prej definirali, ker je enaka načinu, kako ste določili podatke za sporočilo o potrditvi.

Zadnja stvar, ki jo morate storiti, je vrniti trenutno označbo, da jo lahko prenesete v naslednjo ponovitev:

To je vse. Tu je skript v svoji celoti:

Če poženete ta skript, boste dobili vsebino, ki je videti nekako takole:

Za zagon uvoznika morate izhodno datoteko preusmeriti v git fast-import, medtem ko ste v mapi Git, kamor želite uvoziti podatke. Lahko ustvarite novo mapo in nato v njej začnete z git init, nato pa zaženete svoj skript:

Kot vidite, vam po uspešnem zaključku poda cel kup statističnih podatkov o doseženem napredku. V tem primeru ste skupaj uvozili 13 objektov za 4 potrditve v 1 vejo. Sedaj lahko za ogled nove zgodovine zaženete git log:

In to je to — lep in čist repozitorij Git. Pomembno je opozoriti, da nič ni izvlečeno — na začetku nimate nobene datoteke v svoji delovni mapi. Da bi jih dobili, morate ponastaviti svojo vejo na trenutno stanje veje master:

Z orodjem fast-import lahko storite veliko več — obvladovanje različnih načinov, binarnih podatkov, več vej in združevanje, oznak, kazalnikov napredka in še več. V mapi contrib/fast-import izvorne kode Git je na voljo več primerov bolj zapletenih scenarijev.