Hei Habr. Päätin koskea aiheeseen, jota on käytetty monissa artikkeleissa, tarkemmin sanottuna kuvatakseni suurelta osin epästandardista (sanoisin, että ei-lajiteltavaa) versionhallintajärjestelmien (jäljempänä VCS) käyttöä. Hyvät ohjelmoijat, piilotetaan mätä tomaatit ja kuljemme ohi, koska tämä artikkeli ei ole sinua varten. Kyllä, te kaikki olette jo oppineet Gitin, SVN:n, CVS:n ja monien muiden muotisanojen hienoudet. Tutustukaamme pelkät kuolevaiset kaikkiin SLE:n käytön etuihin.
Kutsun kissan alle kaikki, jotka haluavat tutustua SLE:hen, sekä kaikki, jotka tavalla tai toisella käsittelevät nopeasti muuttuvaa dataa.

Miksi sitä tarvitaan

Olen itse teknillisen korkeakoulun opiskelija ja työskentelen lähes jatkuvasti dokumenttien (tekstien, piirustusten, piirustusten) parissa, vaihtaen niitä kolme (kymmentä, sata) kertaa päivässä. Joskus käy ilmi, että aikana tehdyt muutokset viime viikko, sinun on peruutettava ja palattava asiakirjoihin viikko sitten. No, jos muokkauksia tehtiin vähän, tässä tapauksessa viisikymmentä osumaa Ctrl + Z voi auttaa. Jos dokumentin kanssa on kuitenkin työskennelty tämän viikon aikana enemmän tai vähemmän aktiivisesti, tilaa "ennen viikko sitten tehtyä tärkeää muokkausta" ei voida palauttaa. Tämä vaatii kopion asiakirjasta "ennen tärkeää tarkistusta" sekä tusinaa muuta kopiota "ennen muuta tärkeää tarkistusta", "ennen kyseenalaista tarkistusta" ja "ennen versiota, joka todennäköisesti joudutaan peruuttamaan". Periaatteessa tämä lähestymistapa on mahdollista ja monet käyttävät sitä. Viime aikoihin asti olen itse pitänyt tärkeitä versioita tiedostot, tallentamalla ne "date_time"-etuliitteillä, ja näytti olevan tyytyväinen. Tämän menetelmän etuna on yksinkertaisuus, haittana on työkansioiden "turvotus" ja käytön haitat. Ja jos voit jotenkin käsitellä niistä ensimmäistä (isot kiintolevyt ja 7zip), niin jotain oli tehtävä haitalle.

Mitä sille voidaan tehdä tai mikä on SLE

Revimme Wikipediasta kappaleen: "Versionhallintajärjestelmä (englanniksi Version Control System, VCS tai Revision Control System) on ohjelmisto, joka helpottaa muuttuvien tietojen käsittelyä. Versionhallintajärjestelmän avulla voit tallentaa samasta asiakirjasta useita versioita, tarvittaessa palata useampaan versioon varhaiset versiot, määrittää kuka ja milloin teki tämän tai tuon muutoksen ja paljon muuta. Se on samanlainen kuin Wikipedian periaate - kaikki versiot artikkeleista kaikilla muokkauksilla ovat tutkittavissa.
Siksi VCS:n käyttö tilanteessa, jossa sinun on tallennettava useita tiedostoversioita, on mitä tarvitset. Tämän lähestymistavan etuja ovat helppokäyttöisyys ja ilmaiset säästöt levytila ns. delta-pakkauksen ansiosta (kun itse tiedostoja ei tallenneta eri versioihin, vaan ne muuttuvat versiosta toiseen, mikä vähentää tallennetun tiedon määrää). Kokeillaan.

Mitä ovat SLE

Sama Wikipedia ehdottaa, että VCS voidaan keskittää ja hajauttaa, suuria ja pieniä, kellojen ja pillien kanssa ja ilman. Emme ole erityisen kiinnostuneita tästä, koska käytämme (mukaan vähintään, ensin) vain osa SLE-toiminnallisuutta. Katsotaanpa tätä toimintoa.
Lähes kaikki kova valuutta on eräänlainen tallennustila, joka tallentaa kaikki versiot tiedostoista, joiden kanssa työskentelemme. Tässä on tarpeen selventää, että tallennettujen tiedostojen versiot päättävät useimmiten käyttäjä. Teimme vaikkapa kymmenkunta pientä muokkausta ja päätimme, että on aika tallentaa toimintamme tulokset arkistoon. Mieleen tulee analogia Ctrl + S:n ajoittain painamisesta, sillä ainoa ero on, että tätä tiedoston versiota voidaan käyttää tulevaisuudessa. Luonnollisesti yhdellä iskulla tällä tavalla arkistoon voidaan lisätä versioita mielivaltaisen suuresta tiedostomäärästä. Tätä toimintoa kutsutaan "sitomiseksi" tai "muutosten tekemiseksi" yksinkertaisella tavalla.
Voit milloin tahansa lisätä uuden tai poistaa sen arkistoon (eli näin arkistoa näppärästi kutsutaan) olemassa oleva tiedosto, ja VCS "muistaa" milloin ja mitä lisäsimme/poistimme. Ja committien aikaisten kommenttien ansiosta voit myös kuvailla, miksi tätä toimitusta todella toteutetaan ("lisättiin koru sinne" / "poistettiin mahdollisesti tarpeellinen pala sieltä").
Kun vihdoin ymmärrämme, että meidän on aika palata viikon takaiseen versioon, meillä on koko muutoshistoria. Ja täällä voimme valita mitä tehdä. Jos haluat kopioida tarvittavan osan vanhasta tiedostosta ja liittää sen nykyiseen versioon, pura vanha tiedosto muistista ja kopioi tarvittava siitä. Jos sinun täytyy peruuttaa kokonaan ja jatkaa työskentelyä vanha versio SLE tulee jälleen apuun - voit palata aikaisempaan versioon ja luoda niin sanotun uuden haaran ("haara"), säilyttäen samalla kaiken, minkä "kieltäydyimme" palauttamalla versiot viikko sitten. Siten projektin versiohistoria voidaan esittää graafisesti puuna - "juurista" (projektin alku) "haaroihin" (onnistuneet ja epäonnistuneet muokkaukset). Lisäksi "haara" voidaan luoda myös keinotekoisesti, esimerkiksi siinä tapauksessa, että päätämme kehittää kaksi erilaisia ​​versioita- ensimmäisessä työskentelemme joidenkin korujen parissa, toisessa - toisissa. Lisäksi, jos työtiedostot ovat tekstiasiakirjoja(ja joissakin muissa) on mahdollista yhdistää eri haarat yhdeksi - niin sanottu yhdistäminen ("yhdistäminen"). Kuvitellaan nyt, että useat ihmiset työskentelevät projektin parissa ja jokainen työskentelee omien "helmien" parissa. Yhteisen arkiston läsnäolo tässä tapauksessa yksinkertaistaa huomattavasti kehitystä.

Teoriasta käytäntöön tai aloita SLE:n käyttö

Joten toivon, että olen vakuuttanut sinut siitä, että SLE:n käyttö on hyvä asia. On vain opittava käyttämään SLE:tä. Näin teemme.
On olemassa erilaisia ​​​​versionhallintajärjestelmiä, jotka eroavat toisistaan useita näkökulmia käyttää. Koska emme ole kiinnostuneita (ainakaan aluksi) työn hienouksista erilaisia ​​järjestelmiä, keskitytään niistä yksinkertaisimpiin ja ystävällisimpiin. Nöyrä mielestäni tällainen järjestelmä on kummallista kyllä ​​Mercurial - "alustojen välinen hajautettu versionhallintajärjestelmä, joka on suunniteltu tehokasta työtä erittäin suurilla koodivarastoilla" TortoiseHg GUI:lla. Työskentely järjestelmän kanssa on mahdollista Windows-, Linux- ja Mac OS X -käyttöjärjestelmissä.
Tee heti varaus, että kuvailen työn järjestelmän kanssa Windowsissa. Linuxin hallitseneiden ei ole vaikeaa tutkia kaikkea analogisesti.
Lisäksi opimme samalla työskentelyä ilmainen hosting Mercurial-varastot - bitbucket.org, tarvitaan, jos työskentelet projektin parissa et yksin tai, mikä on erittäin kätevää, haluat käyttää kaikkia projektin versioita Internetin kautta. Se on periaatteessa kätevä Dropboxin korvaaja, jos olet käyttänyt sitä aiemmin.
Asenna ensin Mercurial + TortoiseHg täältä: tortoisehg.bitbucket.org.
Tämä järjestelmä toimii konsolissa, joten käytön helpottamiseksi kirjoitamme myöhemmin useita *. bat tiedosto ov tyypillisille toiminnoille.
Kaikki toiminnot suoritetaan komennolla hg. Kutsutaan ilman parametreja, ja se näyttää luettelon peruskomennoista.
Mikä tahansa valitsemamme hakemisto (käytän "C:\project\"-kansiota) toimii arkistona, johon kaikki tulevan projektimme tiedostot tulisi tallentaa. Kukaan ei tietenkään kiellä useiden arkiston käyttöä yhdellä tietokoneella.
Jotta järjestelmä "ymmärtää", että haluamme luoda arkiston, suoritamme komennon:
hg init c:\projekti
jonka jälkeen luodaan "c:\project\"-kansio, jos sitä ei ole luotu aiemmin, ja "c:\project\.hg\"-kansio, johon Mercurial tallentaa kaikki palvelutiedot.
Muistutamme heti, että haluamme saada tietokoneellemme paikallisen arkiston lisäksi myös etätietovaraston, johon lähetämme kaikki muutokset (tai kuten älykkäät ihmiset sanovat, "työntää" muutokset etävarastoon, alkaen englanninkielinen "push"). Voit tehdä tämän siirtymällä osoitteeseen bitbucket.org, rekisteröitymällä ja luomalla ensimmäinen tietovarasto (Arkistot - Luo uusi arkisto). Anna arkistolle nimi (selvyyden vuoksi kutsun sitä remote_projectiksi) ja napsauta Luo arkisto.
Nyt meillä on kaksi tietovarastoa - paikallinen, joka sijaitsee kansiossa "c:\project\" ja etä, joka sijaitsee osoitteessa "bitbucket.org/your_account_name/remote_project/", jossa tilisi_nimi määritetään rekisteröinnin yhteydessä bitbucketissa, remote_project on arkisto, joka on valittu luotaessa.
Jotta voimme jatkaa oppimista, meidän on lisättävä jotain paikalliseen arkistoon. Luo vain siihen (minun tapauksessani "c:\project\"-kansioon) mikä tahansa tiedosto tulevasta projektistasi tai kopioi nykyinen projektisi sinne.
Nyt tarkalleen ottaen meidän on kerrottava Mercurialille: "lisäsimme sellaisia ​​​​ja sellaisia ​​​​tiedostoja ja pari uutta kansiota projektikansioon", "hg add" -komento on tarkoitettu tähän. Toinen lähestymistapa on kuitenkin kätevämpi - seuraavassa vahvistuksessa käskemme Mercurialia poimia kaikki äskettäin luodut tiedostot projektikansiosta ja unohtaa poistetut, tämä on paljon helpompaa kuin tehdä "hg add c:\project\new_document". .doc" aina, kun luot uuden asiakirjan".
Joten mennään ensimmäiseen sitoumuksemme. Se suoritetaan seuraavalla komennolla:
hg commit -A -m "kommentti sitoutumaan"
Otetaan kaikki järjestyksessä. Komento tulee antaa, kun olemme arkistossa (eli meidän on ensin suoritettava "cd c:\project"). Vaihtoehto "-A" on välttämätön, jotta Mercurial "poimii" äskettäin luotuja tiedostoja (katso yllä), vaihtoehto "-m" sallii sinun lisätä kommentin sitoumukseen. Nämä kommentit näkyvät katseltaessa versioita (tai muutosjoukkoja - muutosluetteloita) TortoiseHg:ssä ja projektisivulla osoitteessa bitbucket.org. On erittäin tärkeää antaa merkityksellisiä kommentteja, jotta et myöhemmin kärsi, muistaen milloin tämä tai tuo muokkaus on tehty.
Arkistossamme on nyt projektimme alkuperäinen versio. Kaikki muut sitoumukset suoritetaan samalla tavalla, kun olemme päättäneet, että on aika tallentaa nykyinen versio.
Tehty toimitus voidaan "työntää" etävarastoon komennolla:
hg push https://bitbucket.org/your_account_name/remote_project
Tässä tapauksessa sinun on myös oltava arkistoa vastaavassa kansiossa. Komennon antamisen jälkeen pyydetään bitbucket.org-tilimme nimeä ja salasanaa, jotta niitä ei syötetä jokaisella painalluksella, komento voidaan korvata seuraavalla:
hg push hg push https://your_account_name:[email protected]/your_account_name/remote_project
Koska arvostamme kaikki komennot * .bat -tiedostoon, salasana tallennetaan tässä tapauksessa avoin lomake, mikä on pieni turvallisuusriski, mutta se on minusta hyväksyttävää.
Mukavuuden vuoksi luomme tiedostoja commit.bat, push.bat ja commit&push.bat, joissa on seuraava sisältö suoran tavoittavuuden vyöhykkeelle:
[commit.bat-tiedoston sisältö]
JOS !%1==! poistu 1
cd C:\projekti
hg commit -A -m "%*"
poistu 0
:exit1
echo "EI KOMENTORIVIÄ ARG!"
:exit0
Tämä tiedosto, jota kutsutaan argumenteilla, sitoo projektin vahvistuskommentteihin lisätyillä argumenteilla. Esimerkki: suoritamme "commit.bat minun ensimmäinen commit" ja saamme sitoumuksen kommentilla "minu ensimmäinen sitoumus". FAR:ssa tähän on kätevää käyttää Ctrl + Enter -yhdistelmää.
[push.bat-tiedoston sisältö]
cd C:\projekti
hg push https://your_account_name:[email protected]/your_account_name/remote_project
Tämä tiedosto työntyy etävarastoon.
[commit&push.bat-tiedoston sisältö]
JOS !%1==! poistu 1
cd C:\projekti
hg commit -A -m "%*"
poistu 0
:exit1
echo "EI KOMENTORIVIÄ ARG!"
:exit0
soita ./push.bat
Tämä tiedosto, jota kutsutaan argumenteilla, suorittaa projektin peräkkäisen toimituksen ja push-toiminnon vahvistuksen kommentteihin syötetyillä argumenteilla.
Lisäksi pienille välitoimituksille suosittelen commit_date_time.bat-tiedoston luomista:
[commit_date_time.bat-tiedoston sisältö]
cd C:\projekti
hg commit -A -m "%DATE% %TIME%"
Tämä tiedosto sitoo nykyisen päivämäärän ja kellonajan kommentiksi, mikä on usein kätevää.
Kysymys sitoumusten ja työntöjen tiheydestä on jokaisen itse päätettävissä, riippuen tehtävien muutosten intensiteetistä ja monimutkaisuudesta. Vaikka on suositeltavaa noudattaa sääntöä "useammin - paremmin".
Napsauta hiiren oikealla painikkeella arkistotiedostoa/kansiota, voit käynnistää Repository Explorerin (TortoiseHg - Repository Explorer), joka luettelee kaikki sitoumukset ja kommentit niihin. Tämä ikkuna näyttää arkistomme puurakenteen, josta voit suorittaa sitoumuksia, työntöjä, palautuksia aikaisempiin versioihin (backout) ja muita toimintoja.
Osoitteessa bitbucket.org/your_account_name/remote_project on samanlainen joukko muutosjoukkoja, ja voit ladata minkä tahansa version projektista yhteen arkistoon, mikä on myös toisinaan erittäin kätevää.
Yleisesti ottaen katson, että ensimmäinen tutustuminen Mercurialiin on ohi. Lisää yksityiskohtainen tieto löytyy osoitteesta: translated.by/you/mercurial-the-definitive-guide/into-ru/trans/

Kenelle tämä artikkeli on tarkoitettu?

Lopetan ehkä siihen, mistä minun pitäisi aloittaa - kenelle tämä artikkeli on tarkoitettu? Vastaus on yksinkertainen - niille, jotka haluavat oppia käyttämään SLE:tä. Onnistuin saamaan useita suunnittelijoita, insinöörejä ja jopa kirjailijan koukkuun VCS:ään. Kokeile sitä ja saatat tehdä työstäsi paljon helpompaa.

P. S. Siirretty "Version Control Systems" -blogiin.

Tunnisteet: Lisää tunnisteita

Versionhallintajärjestelmä ( Versionhallintajärjestelmä, VCS) on ohjelmisto, jonka avulla voit seurata asiakirjoissa tehtyjä muutoksia, peruuttaa niitä tarvittaessa, määrittää kuka ja milloin korjauksia on tehnyt jne. Artikkelissa käsitellään tyyppejä VCS, heidän työnsä periaatteet sekä esimerkkejä ohjelmistotuotteet.

Mikä on versionhallintajärjestelmä?

Todennäköisesti kaikki tuntevat tilanteen, kun projektia työskennellessään on tarpeen tehdä muutoksia, mutta samalla on tarpeen ylläpitää toimiva versio, tässä tapauksessa yleensä luodaan uusi kansio , jonka nimi on todennäköisesti "Uusi kansio", johon on lisätty päivämäärä tai pieni huomautus, se kopioidaan toimiva versio projekti ja työskentelee jo sen parissa. Ajan myötä tällaisten kansioiden määrä voi kasvaa merkittävästi, mikä vaikeuttaa aiempien versioiden palauttamista, muutosten seurantaa jne. Tilanne pahenee huomattavasti, kun projektissa työskentelee useita ihmisiä.

Tällaisten ongelmien ratkaisemiseksi käytetään versionhallintajärjestelmää, jonka avulla voit työskennellä mukavasti projektin parissa sekä yksilöllisesti että ryhmässä. VCS seuraa tiedostojen muutoksia, tarjoaa mahdollisuuksia uusien ja olemassa olevien projektihaarojen yhdistämiseen, hallitsee käyttäjien pääsyä projektiin, mahdollistaa korjausten perumisen ja määrittää kuka, milloin ja mitä muutoksia projektiin on tehnyt. Peruskonsepti VCS on arkisto ( arkisto) on projektitiedostojen ja kansioiden erityinen arkisto, jonka muutoksia seurataan. Kehittäjällä on niin sanottu "työkopio" ( työkopio) projektista, jonka parissa hän työskentelee suoraan. Työkopio on ajoittain synkronoitava arkiston kanssa, tähän toimintoon kuuluu käyttäjän työkopioonsa tekemät muutokset (tätä toimintoa kutsutaan ns. tehdä) ja työkopion päivittäminen, jonka aikana arkiston viimeisin versio ladataan käyttäjälle (tämä prosessi on ns. päivittää).

Keskitetyt ja hajautetut versionhallintajärjestelmät

Versionhallintajärjestelmät voidaan jakaa kahteen ryhmään: hajautettuihin ja keskitettyihin.

Keskitetyt versionhallintajärjestelmät

Keskitettyversionhallintajärjestelmät ovat asiakas-palvelinsovelluksia, kun projektivarasto on olemassa yhdessä esiintymässä ja on tallennettu palvelimelle. Pääsy siihen tehtiin erityisen asiakassovelluksen kautta.Esimerkkejä tällaisista ohjelmistotuotteista ovat mm CVS, kumouksellinen.

CVS (Samanaikaiset versiot -järjestelmä, Simultaneous Versioning System) on yksi ensimmäisistä järjestelmistä, joka yleistyi kehittäjien keskuudessa, se ilmestyi viime vuosisadan 80-luvun lopulla. Tällä hetkellä tätä tuotetta ei kehitetä, tämä johtuu ensisijaisesti useista keskeisistä puutteista, kuten mahdottomuus nimetä tiedostoja uudelleen, niiden tehoton tallennus, käytännössä täydellinen poissaolo eheyden valvonta.

kumouksellinen (SVN) on versionhallintajärjestelmä, joka on luotu korvaamaan CVS. SVN kehitettiin vuonna 2004 ja on edelleen käytössä. Huolimatta monista eduista CVS klo SVN edelleen on haittoja, kuten ongelmia uudelleennimeämisessä, kyvyttömyys poistaa tietoja arkistosta, ongelmia haarojen yhdistämisessä jne. Yleisesti SVN oli (ja on edelleen) merkittävä parannus verrattuna cvs.

Hajautetut versionhallintajärjestelmät

Hajautetut versionhallintajärjestelmät ( Hajautettu versionhallintajärjestelmä, DVCS) avulla voit tallentaa arkiston (sen kopion) jokaisen tämän järjestelmän kanssa työskentelevän kehittäjän kanssa. Tässä tapauksessa voit valita (ehdollisesti) keskustietovaraston, johon paikallisista tehdyt muutokset lähetetään ja jonka kanssa nämä paikalliset arkistot synkronoidaan. Työskentelessään tällaisen järjestelmän kanssa käyttäjät synkronoivat ajoittain paikalliset tietovarastonsa keskustietovaraston kanssa ja työskentelevät suoraan paikallisen kopionsa kanssa. Kun paikalliseen kopioon on tehty riittävästi muutoksia, ne (muutokset) lähetetään palvelimelle. Tässä tapauksessa palvelin valitaan useimmiten ehdollisesti, koska. useimmissa DVCS ei ole olemassa sellaista asiaa kuin "omistettu palvelin, jossa on keskustietovarasto".

Tämän lähestymistavan suuri etu on kehittäjän autonomia projektin parissa työskennellessä, joustavuus yhteinen järjestelmä ja parannettu luotettavuus, kun jokaisella kehittäjällä on paikallinen kopio keskusvarastosta. Kaksi kuuluisinta DVCS- Tämä git Ja Oikukas.

Aloitetaan Oikukas, tämä järjestelmä on ilmainen DVCS, joka on rakennettu siten, että siitä puuttuu keskustietovaraston käsite toimimaan tämän kanssa VCS käytetty (yleensä) konsoli-apuohjelma hg. Oikukas sisältää kaikki versionhallintajärjestelmän ominaisuudet, kuten haaroitus, yhdistäminen, synkronointi muiden arkistojen kanssa. Tämä projekti käyttöä ja tukea suuri määrä suuret kehittäjät, mukaan lukien Mozilla, avoin toimisto, OpenJDK ja monet muut. Itse tuote on kirjoitettu kielellä Python ja se on saatavana useimmissa moderneissa käyttöjärjestelmät (Windows, Mac käyttöjärjestelmä, Linux), on myös huomattava määrä apuohjelmia GUI työskennellä jonkun kanssa Oikukas. Pääkilpailija Oikukas hajautettujen versionhallintajärjestelmien markkinoilla on git joka on tähän mennessä voittanut kilpailun johtopaikasta.

git- Linus Torvaldsin kehittämä hajautettu versionhallintajärjestelmä, joka toimii käyttöjärjestelmän ytimen parissa Linux. Joukossa suuria hankkeita, joka käyttää git, voimme valita ytimen Linux, Qt, Android. git ilmainen ja lisensoitu GNU GPL 2 ja aivan kuten Oikukas, on saatavilla lähes kaikissa käyttöjärjestelmissä. Omillaan perusominaisuudet git samanlainen kuin Oikukas(ja muut DVCS), mutta useiden etujen vuoksi ( suuri nopeus työ, mahdollisuus integroitua muihin VCS, käyttäjäystävällinen käyttöliittymä) ja tämän järjestelmän ympärille muodostunut erittäin aktiivinen yhteisö, git tuli markkinajohtaja hajautetuissa versionhallintajärjestelmissä.On huomattava, että tällaisten järjestelmien suuresta suosiosta huolimatta git, suuryritykset kuten Google, käytä niitä VCS.

Se oli johdantoluento versionhallintajärjestelmistä. Seuraavassa koko esitys koskee vain git.

Jos sinä suosit oppia videoluennoista, niin suosittelemme luokkakurssia aiheesta git alkaen Geek Brains , mene linkki ja etsi kurssi Kurssit-osiosta “git. Nopea alku". Hän vapaa sinun tarvitsee vain rekisteröityä sivustolle. Suosittelemme, että tutustut tähän resurssiin tarkemmin, siinä on vielä paljon mielenkiintoista!

Onko sinulla hieno uusi ohjelmistokehityksen liikeidea?Tarvitseeko sinun kehittää teknisesti edistyksellistä ratkaisua? Vai onko sinulla suuri joukko ohjelmoijia, jotka työskentelevät saman tehtävän parissa? Muista sitten nämä kolme sanaa:versionhallintajärjestelmä .

Versionhallintajärjestelmä (cvs), 2017 - Vertaa: Git, SVN, Mercurial

, tai vcs- tämä estää projektia hajoamasta, kun sen parissa työskentelee paljon ihmisiä. Ohjelmoijat, johtajat, tekstinkirjoittajat voivat työskennellä kukin oman kappaleensa parissa häiritsemättä toisiaan ja aiheuttamatta vahinkoa, jota ei voitu korjata.

Jos et ole perehtynyt käsitteeseenversionhallintajärjestelmät, sitten täällä kaikki näkyy hyvin selvästi.

Tai katso video GitHubista.

Joten mikä versionhallintajärjestelmä sopii projektiisi?

Olemme vertailleet useita suosittuja ratkaisuja auttaaksemme sinua tekemään valintasi.

Tämä on erittäin erikoistunut tekninen aihe. Olemme yrittäneet tehdä arvostelustamme ymmärrettävän kaikille. Mutta jos sinulla ei ole ohjelmointikokemusta, muista tarkistaa kehitysosastoltasi ennen kuin teet mitään päätöksiä.

Versionhallintajärjestelmät, mukaan lukien tunnetut SVN (Subversion) ja Git, luotiin alun perin kehittämään kehitystiimiä yhteisiä projekteja aiheuttamatta hämmennystä. Ohjausjärjestelmässä sinun ei tarvitse itsenäisesti seurata koodihaaroja ja tutkia niihin liittyviä huomautuksia. Sen sijaan käytetään keskusvarastoa, jossa kaikki on järjestetty, jäsennelty. Täällä on kätevää päivittää tiedostoja, lisätä kommentteja ja jopa yhdistää projektihaaroja.

Mielipiteitä mistäversionhallintajärjestelmäparas, vaihtelevat suuresti, ja tämä johtaa kiihkeä keskustelu ohjelmoijien keskuudessa. Valinta ja opiskeluversionhallintajärjestelmätMuista projektissasi, että yhden tai toisen ratkaisun hyödyt ovat usein subjektiivisia. Esimerkiksi ohjelmoijan henkilökohtaiset mieltymykset tai esimerkiksi indikaattorit, kuten suorituskyky, IDE-laajennusten ominaisuudet jne.

Suurin ero versionhallintajärjestelmien välillä on, ovatko ne asiakaspalvelin- vai hajautettuja (p2p). Onko heillä keskusvarasto (palvelin), josta koodi tulee ja mistä se palaa tehtyjä muutoksia. Vai onko se kopio paikallisessa tallennustilassa, päivitetty vertaisten kautta: lisää hajautettu verkko, jota käytetään synkronointiin, korjaustiedostojen jakamiseen (muutossarjoihin) ja nykyisen koodin ylläpitämiseen.

On myös syytä harkita tietyn syöttämisen / hallitsemisen nopeutta, toimivuutta ja kynnystäohjausjärjestelmät. Harkitse yleisimpiäversionhallintajärjestelmätja syyt, miksi ohjelmoijat suosivat tiettyjä ratkaisuja.

Samanaikainen versiojärjestelmä (CVS)

CVS ilmestyi 1980-luvulla ja on edelleen suosittu sekä kaupallisten tuotekehittäjien että avoimen lähdekoodin kehittäjien keskuudessa.

CVS on ehtojen alainenGNU General Public License ja antaa sinun saada palvelimelta haluttu versio projekti -"uloskirjautuminen" (ote) ja sitten eteenpäin takaisin palvelimelle,check-in" (paluu),tehtyjen muutosten kanssa.

Alunperin CVS luotiin versioristiriitojen välttämiseksi. Kaikille osallistujille toimitettiin vain uusin versio koodista käytettäväksi. Se oli ensimmäinen versionhallintajärjestelmä. Käyttäjän täytyi nopeasti tehdä muutoksia arkistoon ennen kuin muut pääsivät hänen edellään.

Nyt CVS tukee koodihaaroja sisältävien projektien työskentelyä. Osoittautuu, että tuotteesta on useita muunnelmia erilaisia ​​ominaisuuksia jotka voidaan yhdistää myöhemmin.

CVS-palvelimet toimii yleensä Unixin alla, mutta CVS -Asiakkaita on saatavilla myös muille suosituille käyttöjärjestelmille. CVS - "kypsä", aika-testattuversionhallintajärjestelmä. Se on edelleen avoimen lähdekoodin järjestelmä, mutta uusia ominaisuuksia lisätään nykyään harvoin.

Samalla CVSNT on erilliseksi projektiksi erotettu versio CVS varten Windows-palvelimet, - laajentaa nyt aktiivisesti toimintoja.

Edut:

• Ajan testattu tekniikka, joka on ollut markkinoilla vuosikymmeniä.

Virheet:

• Tiedostojen uudelleennimeäminen tai siirtäminen ei näy historiassa
• Tietoturvariskit, jotka liittyvät tiedostoihin johtaviin symbolisiin linkkeihin
• Ei tukea atomioperaatioille, mikä voi johtaa koodin korruptioon
• Haaraliikkeet ohjelmakoodi kallis, koska tämäohjausjärjestelmäei ole tarkoitettu pitkäaikaisiin projekteihin, joissa on koodihaaroja

Apache Subversion (SVN)

SVN luotu vaihtoehtona CVS puutteiden korjaamiseksi CVS ja samalla varmistaa korkea yhteensopivuus sen kanssa.

Kuten CVS , SVN on ilmainen järjestelmä versionhallinta avoin lähdekoodi. Ainoalla erolla, että sitä jaetaan Apache-lisenssillä, ei sen allaavata lisenssisopimus GNU.

SVN käyttää niin sanottuja atomioperaatioita ylläpitääkseen tietokannan eheyttä. Kun uusi versio julkaistaan, joko kaikki korjaukset tai mitään niistä ei sovelleta lopulliseen tuotteeseen. Siten koodi on suojattu kaoottisilta osittaisilta muutoksilta, jotka ovat ristiriidassa keskenään ja aiheuttavat virheitä.

Monet kehittäjät ovat vaihtaneetSVN, koska uusi teknologia perivät parhaat mahdollisuudet CVS ja samalla laajensi niitä.

CVS:ssä ollessaan toiminnot koodihaaroilla ovat kalliita eikä järjestelmäarkkitehtuuri tarjoa, SVN on luotu juuri tätä varten. Eli suurempiin projekteihin, joissa on haarakoodi ja monia kehitysalueita.

SVN:n haitat mainitaan suhteellisesti alhainen nopeus ja puute hajautettu ohjaus versiot. Hajautettu versionhallinta käyttää peer-to-peer-mallia keskitetyn palvelimen sijasta koodipäivitysten tallentamiseen. Vaikka peer-to-peer-malli toimii parhaiten avoimen lähdekoodin projekteissa, se ei ole ihanteellinen muissa tapauksissa. Palvelinpuolen lähestymistavan haittapuoli on, että kun palvelin kaatuu, asiakkaat eivät pääse käsiksi koodiin.

Edut:

• järjestelmäpohjainen CVS
• Mahdollistaa atomioperaatiot
• Koodihaaroitustoiminnot ovat halvempia
• Laaja valikoima IDE-laajennuksia
• Ei käytä vertaismallia

Virheet:

• Virheet jatkuvat edelleen liittyvät tiedostojen ja hakemistojen uudelleennimeämiseen
• Epätyydyttävä komentosarja arkiston kanssa työskentelyä varten
• Suhteellisen alhainen nopeus

git

Tämä järjestelmä luotiin ohjaamaan kehitystä Linux-ytimet ja käyttää lähestymistapaa, joka eroaa olennaisesti CVS:stä ja SVN:stä.

Perusta git käsitteet määriteltiin nopeamman jakelun luomiseksiversionhallintajärjestelmä, toisin kuin kohdassa käytetyt säännöt ja ratkaisut CVS . Koska Git kehitettiin pääasiassa Linuxille, se toimii nopeimmin tällä käyttöjärjestelmällä.

Git toimii myös Unix-tyyppisissä järjestelmissä (kuten MacOS) ja työskentelyyn Windows-alusta mSysGit-pakettia käytetään.

Ohjelmakoodi ei ehkä ole käytettävissä käytettäessä tietokonetta ilman arkistoa. Tähän ongelmaan on ratkaisuja, ja jotkut kehittäjät uskovat, että Gitin nopeus on kohtuullinen hinta vaivasta maksettavaksi.

Lisäksi Gitissä on monia työkaluja muutoshistoriassa liikkumiseen. Jokainen lähdekoodin työkopio sisältää koko kehityshistorian, mikä on erittäin hyödyllistä ohjelmoitaessa ilman Internet-yhteyttä.

Edut:

• Täydellinen niille, jotka vihaavat CVS/SVN
• Merkittävä suorituskyvyn kasvu
• Halvat toiminnot koodihaaroilla
• Koko kehityshistoria saatavilla offline-tilassa
• Hajautettu, vertaisverkkomalli

Virheet:

• Korkea pääsy (oppimis) kynnys niille, jotka ovat aiemmin käyttäneet SVN:ää
• Rajoitettu Windowsin tuki(verrattuna Linuxiin)

Oikukas

Oikukas julkaistiin samaan aikaan kuin Git. se on sama hajautettu versionhallintajärjestelmä.

Mercurial luotiin vaihtoehdoksi Gitille Linux-ydinmoduulien kehittämiseen. Mutta koska Git valittiin, Mercurialia käytetään vähemmän. Kuitenkin monet johtavat kehittäjät työskentelevät esimerkiksi tämän järjestelmän kanssaopenoffice.org .

Mercurialin versionhallintajärjestelmä on erilainenversionhallintajärjestelmätkoska se on enimmäkseen kirjoitettu Pythonilla (ei C). Jotkut osat on kuitenkin toteutettu laajennusmoduuleina C:ssä.

Koska järjestelmä on hajautettu ja kirjoitettu Pythonilla, monet Python-ohjelmoijat ovat taipuvaisia ​​Mercurialiin.

Käyttäjät huomauttavat, että Mercurial säilytti osan SVN:n ominaisuuksista ollessaan hajautettu järjestelmä, ja tämän samankaltaisuuden vuoksi pääsykynnys on alhaisempi niille, jotka ovat jo perehtyneet SVN:ään. Mercurialin dokumentaatio on myös kattavampi, mikä auttaa sinua tottumaan eroihin nopeammin.

Yksi merkittäviä puutteita Mercurial on se, että toisin kuin Git, se ei voi yhdistää kahta päähaaraa, koska Mercurial käyttää laajennusjärjestelmää, ei komentosarjatukea. Tämä on hienoa joillekin ohjelmoijille, mutta monet eivät halua luopua Gitin voimasta.

Edut:

• Gitiin verrattuna se on helpompi oppia
• Yksityiskohtainen dokumentaatio
• hajautettu malliversionhallintajärjestelmät

Virheet:

• Ei mahdollisuutta yhdistää kahta päähaaraa
• Käytä laajennuksia, ei skriptejä
• Vähemmän mahdollisuuksia epätyypillisille ratkaisuille

Mikäversionhallintajärjestelmä sopii minulle?

Useimmissa tapauksissa kehittäjät käyttävät CVS koska he ovat tottuneet siihen. Jos tiimi työskentelee jo projektin parissa, on mahdollisuus siirtää kaikki kehitystyöt toiseenohjausjärjestelmäjotenkin ei inspiroi. Jos heidän täytyisi silti muuttaa järjestelmää, he todennäköisesti vaihtaisivat SVN:ään.

CVS on jo saavuttanut "kypsän teknologian" tilan, mikä tarkoittaa, että se ei enää esittele radikaaleja uusia ominaisuuksia ja ratkaisuja. Tottumuksen vauhti katoaa ihmisten siirtyessä SVN:ään. Joten CVS:stä on vähitellen tulossa menneisyyttä.

Nykyään SVN on kämmenellä palvelimien joukossaversionhallintajärjestelmät. Se sisältää edut CVS ja ylittää ne. Jos puhumme levinneisyydestä, kohtaat todennäköisesti useammin CVS tai SVN kuin Git tai Mercurial. Joten yhden palvelintekniikan tunteminen, vaikka se ei ole välttämätöntä, tekee siirtymisestä helpompaa.

Teknologian laajan käytön ja kypsyyden vuoksi SVN on kertynyt iso pohja tieto, jonka avulla käyttäjät voivat saada apua helposti.

Git on selvästi kilpailijoitaan nopeampi. Hankkeille, jotka on luotu hajautettunaversionhallintajärjestelmät, tämä on selvä parannus.

Gitin merkittävä haittapuoli on, että joskus on vaikea selittää sen vivahteitaohjausjärjestelmät, ja tämä hidastaa työnkulkua ohjelmoijien tottuessa siihen. Kuitenkin heti kun "saapuskynnys" ylitetään, tuottavuus kasvaa ja koodihaarojen hallinnan mukavuus maksaa täysin käytetyn ajan.

Niille, jotka vihaavat Gitiä (ja sillä on halveksijat kehittäjäyhteisössä), Mercurial on kompromissi SVN:n ja Gitin välillä. Tätä järjestelmää käytetään monissa tunnetuissa projekteissa, ja sillä on myös hyvä dokumentaatio.

Myös Gitin Windows-yhteensopiva versio etenee lähemmäs Linux-versiota, joten saatat silti pystyä käyttämään tätä järjestelmää, vaikka et kehitä Linuxissa.

Ymmärtääksesi, mikä on sinulle paras, harkitse projektin ja tiimisi erityispiirteitä. Keskustele kehittäjien kanssa!

Jos projektisi vaatii yhden lähdepuun, jonka parissa pieni ryhmä ohjelmoijia työskentelee, SVN on sinun vaihtoehtosi. Se on luotettava ja suunniteltu juuri tällaisiin tapauksiin.

Jos käytät avoimen lähdekoodin projektia, jossa eri aika useat ohjelmoijat työskentelevät tai jos niin oletetaan jatkuva päivitys koodi, valitse Git. Nopeus- ja lähdepuun hallinta on täällä paljon parempi kuin SVN:ssä.

Jos olet tienhaarassa tai et vain pidä SVN:n tai Gitin toiminnasta, Mercurial on sinua varten.

Kaikki nämä järjestelmät ovat täysin toimivia. Ja myös ilmainen. Niitä käytetään luomiseen ohjelmisto, sivustot ja jopa käyttöjärjestelmät, joita käytät ja joista tiedät.

Ensinnäkin päätä, sopiiko toinen vai toinenohjausjärjestelmäversioita yrityksellesi, ja sitten - aivan yhtä tärkeää - varmista, että tämä valinta ei raivoa ohjelmoijia.

SVN:n käytön aloittaminen

Jos et ole koskaan työskennellyt SVN:n tai Gitin kanssa etkä tiedä, miten pääset alkuun, niinisännöintiratkaisu yhdistettynä graafiseen käyttöliittymäänauttaa pääsemään nopeasti vauhtiin.

Kuten useimmissa tapauksissa, tärkeintä on aloittaa työ, ja sitten tulee ymmärrystä. Versionhallintajärjestelmän käyttö on hyvin samanlaista kuin tiedostojen käsittely palvelimella FTP-asiakasohjelmalla.

HUOMAUTUS:Isännöintiratkaisuja on moniaversionhallintajärjestelmät, mukaan lukien ilmainen koeaika. Voit luoda ensimmäisen arkiston niiden perusteella (paikan yhteistä työtä kooditiedostoilla) täysin ilmainen. Tässä on joitain näistä palveluista:

SVN- ja GIT-isännöinti

Ensimmäisen arkiston luominen

Kun olet luonut tilin, sinun on luotava arkisto - jokaiselle alustalle erikseen. Yleensä se näyttää tältä:

• Kirjaudu tilillesi, napsauta projektejasi.
• Projektin luominen:

• Kirjoita "Luo uusi projekti" -riville projektisi nimi
• Napsauta "Luo projekti" -painiketta

• SVN-yhteys:

• Kun olet luonut projektin, valitse "Source Control" -välilehti (lähdekoodiversiot)
• Napsauta "Ota lähdehallinta käyttöön" -linkkiä
• Anna arkistolle nimi
• Napsauta "Tallenna"

Graafiset SVN- ja GIT-asiakkaat

Joten arkisto on luotu. Nyt on välttämätöntä, että kaikki näkyy siinä yksinkertaisesti ja selkeästi. Tätä varten tarvitset graafisen käyttöliittymän.

— kätevä ohjelma työskennellä jonkun kanssaversionhallintajärjestelmätMicrosoft Windowsissa ja luultavasti paras Apache Subversion -asiakasohjelma. TortoiseSVN toteutettu laajennuksena Windows kuoret, minkä ansiosta se on helppo integroida selain. Lisäksi se on avoimen lähdekoodin ohjelma, jolle on saatavilla 34 kielipakettia.

SmartGit

- Git graafinen asiakas ( avoin lähdekoodi hajautettuversionhallintajärjestelmä). Toimii Windowsissa, Mac OS X:ssä ja Linuxissa.Lisenssin hinta - 39 dollaria

"Checkout" arkisto ("Tarkista")

Eli asiakas on valittu. Nyt sinun on luotava arkisto ohjausjärjestelmälle. Pitää päästä sisäänArkiston URL-osoite, käyttäjätunnus ja salasana.

URL-osoite näyttää yleensä tältä:https://svn .hostname.com/svn/ > (voit käyttää https:// (SSL), jos sinulla on maksettu tili)

1. Mene juurikansio, napsauta "Katso ulos" -painiketta ja luo työkansio asiakkaalle. Nyt voit lisätä siihen tiedostoja.
2. Purettuasi projektitiedostot voit muokata niitä tietokoneesi paikallisessa hakemistossa.

Kun olet tehnyt muutoksia tiedostoihin, napsauta työkalupalkin "Kirjaudu sisään" -painiketta tallentaaksesi ne. Voit tarkastella muutoksia ja lisätä niihin kommentteja - se on melkoista hyvä idea, koska jatkossa tiedät tarkalleen, mitä olet työstänyt, mitä muutoksia on tehty ja pidät muut projektiin osallistujat ajan tasalla.

Asiakkaasi tulee myös tarjota mahdollisuus aloittaa versioiden käsittely milloin tahansa avaamalla versiolokin tai muutoshistorian - sitten voit tarvittaessa "palauttaa" aiempi versio jokaiselle tiedostolle erikseen. Nyt kun olet perehtynyt peruskäsitteisiin, dokumentaatioon

RCS:n (Revision Control System) kehitti 1980-luvun alussa Walter F. Tichy. Järjestelmän avulla voit tallentaa vain yhden tiedoston versioita, joten sinun on hallittava useita tiedostoja manuaalisesti. Jokaisen järjestelmän hallinnassa olevan tiedoston versiotiedot tallennetaan erityiseen tiedostoon, johon on liitetty alkuperäisen tiedoston nimi ",v"-merkeillä. Esimerkiksi tiedoston file.txt versiot tallennetaan tiedostoon file.txt,v . Versioiden tallentamiseen järjestelmä käyttää diff-apuohjelmaa, eli vain versioiden väliset muutokset tallennetaan.

Harkitse esimerkkiä istunnosta RCS:n kanssa ($-merkki tässä ja alla tarkoittaa käyttöjärjestelmän kehotetta). Kun haluamme laittaa tiedoston RCS-ohjaukseen, käytämme ci (check-in, register) -komentoa:

$ci tiedosto.txt

Tämä komento luo tiedoston file.txt,v ja poistaa alkuperäinen tiedosto file.txt (ellei sitä ole kielletty). Tämä komento pyytää myös kuvausta kaikille tallennetuille versioille. Koska järjestelmä poisti alkuperäisen tiedoston, meidän on pyydettävä se takaisin, jotta voimme tehdä muutoksia. Käytämme tätä varten co (from check-out, control) -komentoa:

$cofile.txt

Tämä komento poistaa uusin versio tiedostomme tiedostosta file.txt,v . Nyt voimme muokata tiedostoa file.txt ja kun olemme tehneet muutokset, suorita ci-komento uudelleen tallentaaksesi tiedoston uuden muokatun version:

$ci tiedosto.txt

Tätä komentoa suoritettaessa järjestelmä pyytää meiltä kuvauksen muutoksista ja tallentaa sitten tiedoston uuden version.

Vaikka RCS noudattaa vähimmäisvaatimukset versionhallintajärjestelmään nähden siinä on seuraavat päähaitat, jotka myös toimivat kannustimena seuraavan harkittavana olevan järjestelmän luomiseen:

• Kun työskentelet vain yhden tiedoston kanssa, jokaista tiedostoa on ohjattava erikseen;
• Epämukava mekanismi samanaikainen toiminta useat järjestelmän käyttäjät, tallennustila yksinkertaisesti estetään, kunnes sen estänyt käyttäjä avaa sen;

CVS

CVS (Concurrent Versions System) on edelleen yleisimmin käytetty järjestelmä, mutta se menettää nopeasti suosiotaan puutteiden vuoksi, joita käsittelen alla. Dick Grune kehitti CVS:n 1980-luvun puolivälissä. Yksittäisten tiedostojen tallentamiseen CVS (sama kuin RCS) käyttää RCS-muodossa olevia tiedostoja, mutta voit hallita hakemistoissa olevia tiedostoryhmiä. CVS käyttää myös asiakas-palvelin-arkkitehtuuria, jossa kaikki versiotiedot on tallennettu palvelimelle. Asiakas-palvelin-arkkitehtuurin käyttö mahdollistaa CVS:n käytön myös maantieteellisesti hajautetuissa käyttäjäryhmissä, joissa jokaisella käyttäjällä on oma työhakemistonsa, jossa on kopio projektista.

Kuten nimestä voi päätellä, käyttäjät voivat jakaa järjestelmän. Mahdolliset ristiriidat saman tiedoston muuttamisessa ratkaistaan ​​sillä, että järjestelmä sallii sinun tehdä muutoksia vain tiedoston uusimpaan versioon. Siksi on aina hyvä idea päivittää tiedostojen työkopiot ennen muutosten tekemistä mahdollisten ristiriitaisten muutosten varalta. Päivitettäessä järjestelmä tekee muutoksia työkopioon automaattisesti, ja vain ristiriitaisten muutosten sattuessa jossakin tiedoston paikasta vaaditaan ristiriitakohdan manuaalinen korjaus.

CVS:n avulla voit myös ylläpitää useita kehityslinjoja projektille kehityshaaroja käyttämällä. Siten, kuten edellä mainittiin, on mahdollista korjata vikoja projektin ensimmäisessä versiossa ja kehittää samanaikaisesti uusia toimintoja.

Tarkastellaan pientä esimerkkiistuntoa CVS:n kanssa. Ensinnäkin sinun on tuotava projekti CVS: ään, tämä tehdään tuontikomennolla (import):

$ cd jokin projekti $ cvs import -m "Uusi projekti" polku arkistossa none start

Tässä valitsimella -m voit määrittää muutosten kuvauksen suoraan komentorivillä ja jos se jätetään pois, sitä kutsutaan tekstieditori. Seuraavaksi osoitetaan polku, johon projekti tallennetaan arkistoon (tapauksessamme polku arkistossa) ja sen jälkeen on kaksi nimiötä: kehittäjätunniste (voi olla hyödyllinen, jos käytät CVS:ää kehitettyjen projektien työskentelyyn joku muu) ja projektin nimi.

Kun olemme ladanneet projektimme arkistoon, meidän on luotava uusi hakemisto, jossa projektin työkopio sijaitsee CVS:n hallinnassa, ja ladata projekti käyttämällä checkout (control) -komentoa tai lyhennettynä co :

$ cd some-working-dir $ cvs checkout polku arkistossa

Checkout-komennolla määritämme polun projektiimme arkistossa, jonka määritimme yllä tuontikomennolla.

Nyt voimme tehdä muutoksia projektiin ja ladata ne arkistoon käyttämällä commit-komentoa (commit changes), tai lyhennettynä ci:llä:

$ cvs commit -m "Joitakin muutoksia"

Aivan kuten tuontikomennon kohdalla, määritämme kommentin muutoksiimme valitsimella -m.

Jos haluamme päivittää työhakemistomme uusi versio projekti käyttämämme arkistosta päivityskomento(päivitys), tai lyhyesti ylös:

$ cvs päivitys

cvs oli käytössä iso määrä hankkeita, mutta se ei tietenkään vailla puutteita, jotka myöhemmin johtivat seuraavan harkittavan järjestelmän syntymiseen. Harkitse tärkeimpiä haittoja:

• Koska versiot on tallennettu RCS-tiedostoihin, hakemistoversioita ei voi tallentaa. Normaali tapa tämän esteen ohittaminen on tallentamalla tiedosto (esimerkiksi README.txt) hakemistoon;
• Tiedostojen siirtäminen tai uudelleennimeäminen ei ole versionhallinnan alaista. Tavallinen tapa tehdä tämä on kopioida ensin tiedosto, poistaa vanha cvs remove -komennolla ja sitten lisätä se uudella nimellä cvs add -komennolla;

kumouksellinen

Subversionin (SVN) kehitti vuonna 2000 CollabNet. SVN suunniteltiin alun perin "parhaaksi CVS:ksi" ja kehittäjien päätavoitteena oli korjata CVS:n suunnittelussa tehdyt virheet samalla kun säilytetään samanlainen käyttöliittymä. SVN, kuten CVS, käyttää asiakas-palvelin-arkkitehtuuria. Merkittävimpiä muutoksia verrattuna CVS:ään ovat:

• Atomimodifikaatio (commit). Jos sitoumus keskeytetään, muutoksia ei tehdä.
• Tiedostojen uudelleennimeäminen, kopioiminen ja siirtäminen tallentaa koko muutoshistorian.
• Hakemistot, symboliset linkit ja metatiedot ovat versionhallinnan alaisia.
• Tehokas muutosmuisti binääritiedostoille.

Katsotaanpa esimerkkejä komennoista, vaikka on huomattava, että useimmat niistä ovat käytännössä samoja kuin CVS-komennot. Jos haluat käyttää projektia SVN:n kanssa, sinun on ensin tuotava se arkistoon käyttämällä tuontikomentoa:

$ cd jokin-projekti $ svn import -m "Uusi projekti" polku arkistossa

Toisin kuin CVS, sinun ei tarvitse määrittää kehittäjä- ja projektitunnisteita, joita ei käytännössä käytetä usein.

Nyt meidän on luotava työkopio projektista käyttämällä checkout (control) tai co-komentoa:

$ cd some-working-dir $ svn checkout polku arkistossa

Muutosten tekemisen jälkeen käytämme commit-komentoa tai ci:tä tallentaaksemme muutokset arkistoon:

$ svn commit -m "Joitakin muutoksia"

Ja projektin työkopion päivittämiseen käytetään päivitys (päivitys) tai ylös -komentoa.

Versionhallintajärjestelmä(englannista. Version Control System - VCS tai Revision Control System) - erityinen ohjelmisto usein muuttuvien tietojen kanssa työskentelemiseen, jonka avulla voit tallentaa useita versioita samasta asiakirjasta ja tarvittaessa palata aikaisempiin versioihin, määrittää kuka sen on tehnyt ja kun yksi tai toinen muuttuu, ja paljon muuta.

Tällaisia ​​järjestelmiä käytetään laajimmin ohjelmistokehityksessä kehitettävän ohjelman tiedostojen tallentamiseen.

Usein käy niin, että useat ihmiset työskentelevät saman projektin parissa samanaikaisesti, ja jos kaksi henkilöä muuttaa samaa tiedostoa, toinen heistä voi vahingossa kumota toisen tekemät muutokset. Versionhallintajärjestelmät seuraavat tällaisia ​​ristiriitoja ja tarjoavat työkaluja niiden ratkaisemiseen. Useimmat näistä järjestelmistä voivat automaattisesti yhdistää (yhdistää) tehdyt muutokset eri kehittäjät. Tällainen muutosten automaattinen yhdistäminen on kuitenkin yleensä mahdollista vain tekstitiedostoille ja edellyttäen, että tämän tiedoston eri (ei päällekkäisiä) osia on muutettu. Tämä rajoitus johtuu siitä, että useimmat versionhallintajärjestelmät ovat keskittyneet tukemaan ohjelmistokehitysprosessia ja lähdekoodeja ohjelmat on tallennettu tekstitiedostoja. Jos automaattinen yhdistäminen epäonnistuu, järjestelmä voi tarjoutua ratkaisemaan ongelman manuaalisesti.

Jotkut versionhallintajärjestelmät antavat sinulle mahdollisuuden lukita tiedosto varastoon. Lukitus estää muita käyttäjiä hankkimasta työkopiota tai estää tiedoston työkopion muokkaamisen (esim. tiedostojärjestelmä) ja tarjoaa siten yksinoikeuden vain asiakirjaa käsittelevälle käyttäjälle.

Useimmat versionhallintajärjestelmät tarjoavat seuraavat ominaisuudet:

• antaa sinun luoda erilaisia ​​muunnelmia yksi asiakirja (haara) kanssa yhteinen historia muutokset ennen haarapistettä ja erilaisilla sen jälkeen;
• mahdollistaa sen, että voidaan selvittää, kuka ja milloin lisäsi tai muutti tiettyä riviä tiedostoon;
• pitää muutoslokia, johon käyttäjät voivat kirjoittaa selityksiä siitä, mitä ja miksi he muuttivat tässä versiossa;
• hallita käyttäjien käyttöoikeuksia, sallien tai kieltäen tietojen lukemisen tai muokkaamisen sen mukaan, kuka tätä toimintoa pyytää.

Jokaisella versionhallintajärjestelmällä on omat erityispiirteensä, jotka liittyvät komentosarjaan, käyttäjän käyttäytymiseen ja hallintaan. tästä huolimatta yleinen järjestys Useimpien VCS:ien työ on täysin stereotyyppistä. Tässä oletetaan, että projekti, oli se mikä tahansa, on jo olemassa ja sen arkisto isännöi palvelimella, johon kehittäjä saa pääsyn.

Järjestelmän käytön aloittaminen. Ensimmäinen toiminto, joka kehittäjän on suoritettava, on tarkistaa projektin työkopio tai sen työstettävä osa. Tämä toiminto suoritetaan käyttämällä tavallinen komento version purku (checkout tai klooni) tai sen kanssa erityinen joukkue, joka itse asiassa suorittaa saman toiminnon. Kehittäjä määrittää kopioitavan version, oletus on yleensä uusin (tai pääkäyttäjän valitsema versio).

päivittäinen työkierto. Tyypillinen kehittäjän työsykli työpäivän aikana on seuraava:

• työkopion päivitys: kun projektin pääversioon tehdään muutoksia, kehittäjän tietokoneella oleva työkopio vanhenee ja sen poikkeama projektin pääversiosta kasvaa, mikä lisää ristiriitaisten muutosten riskiä (katso alla), ja on välttämätöntä pitää työkopio tilassa, joka on mahdollisimman lähellä nykyisiä pääversioversioita, joten kehittäjä suorittaa työkopion päivitysoperaation (päivitys) mahdollisimman usein, joka määräytyy muutosten tiheyden mukaan kehityksestä riippuen aktiivisuus, kehittäjien lukumäärä ja myös kuhunkin päivitykseen käytetty aika;
• projektin muutos: kehittäjä muokkaa projektia muuttamalla siihen sisältyviä tiedostoja työkopiossa projektin toimeksiannon mukaisesti, tämä työ tehdään paikallisesti eikä vaadi kutsuja VCS-palvelimelle;
• muutosten tekeminen: suoritettuaan tehtävän seuraavan työvaiheen kehittäjä sitoutuu (sitomaan) tekemänsä muutokset siirtämällä ne palvelimelle (joko päähaaralle, jos tehtävän työ on kokonaan valmis, tai tämän tehtävän erilliseen kehityshaaraan ).