Send ditt gode arbeid i kunnskapsbasen er enkelt. Bruk skjemaet nedenfor

Studenter, hovedfagsstudenter, unge forskere som bruker kunnskapsbasen i studiene og arbeidet vil være deg veldig takknemlig.

postet på http://www.allbest.ru/

Utdannings- og vitenskapsdepartementet i Den russiske føderasjonen

Forbundsstatsbudsjett utdanning

Institusjon for høyere profesjonsutdanning

"TOMSK STATSuniversitet

KONTROLLSYSTEMER OG RADIOELEKTRONIKK" (TUSUR)

Avdeling radiosystemer(RTS)

Kursarbeid

i kurset "Informasjonsteknologi"

VERSJONSKONTROLLSYSTEMER

Elever fra gruppe 121-3 Korolev D.O.,

Kuleshov M.V., Sadov D.A., Taimasov S.S.

Leder Nozdrevatykh B.F.

Kursarbeid 46 s., 31 figurer, 2 tabeller, kilder.

VERSJONSKONTROLLSYSTEM, GIT, SVN, MERCURIAL.

Dette kursarbeidet undersøker de mest populære versjonskontrollsystemene.

Hensikten med arbeidet er å sette seg inn i versjonskontrollsystemer, forstå deres virkemåte, installasjon og konfigurasjon.

Under arbeidet ble det installert, konfigurert og testet tre typer versjonskontrollsystemer.

Som et resultat er tre ferdige versjonskontrollsystemer blitt kompilert, tabeller som sammenligner funksjonene til disse systemene er kompilert, og en ordbok med termer som brukes når du arbeider med programmer er gitt.

Kursarbeid gjennomføres i tekst Microsoft redaktør Word 2010 og er tilgjengelig i trykte og elektroniske formater.

kontrollversjon systemgrensesnitt

Introduksjon

3.1 Komme i gang med prosjektet

3.2 Daglig arbeidssyklus

3.3 Grener

3.4 Slå sammen versjoner

3.5 Konflikter og deres løsning

3.6 Låser

3.7 Prosjektversjoner, tagger

4.1 Lokale versjonskontrollsystemer

4.2 Sentralisert modell

5.1.1 Systemkrav

5.1.2 Konsept

5.1.3 Komme i gang

5.2.1 Systemkrav

5.2.2 Installasjon

5.2.3 Grunnleggende konsept

5.2.4 Opprette et depot

5.2.5 Importere et prosjekt

5.2.7 Gjøre endringer

5.2.8 Legge til nye filer

5.2.9 Avbryt endringer

5.3.1 Systemkrav

5.3.2 Konsept

5.3.3 Komme i gang

Konklusjon

Vedlegg A

Vedlegg B

Vedlegg B

Introduksjon

I dag i en verden der det er stor mengde komplekse systemer, er det behov for modifikasjon elektroniske dokumenter på ulike stadier av utviklingen. Under sin eksistens kan et elektronisk dokument bli gjenstand for et stort antall endringer. Imidlertid skjer det ofte at for videre arbeid Ikke bare den siste versjonen av dokumentet er nødvendig, men også forskjellige tidligere versjoner.

Selvfølgelig kan du lagre flere ulike alternativer nødvendig dokument, men denne metoden er ineffektiv. Vi må bruke mye tid og krefter, spesiell oppmerksomhet kreves og det er stor sannsynlighet for feil. I tillegg må vi lagre et stort antall nesten identiske dokumenter.

Som et resultat er det utviklet programvareverktøy som forenkler denne mekanismen. Disse verktøyene kalles versjonskontrollsystemer. Det er flere systemer av denne typen, som hver er relevante under visse bruksbetingelser.

Hovedideen med versjonskontrollsystemer er å huske alle endringer som er gjort, så vel som kommentarer fra brukerne som har gjort dem. Etter dette blir det klart hvem, når og hva som endret seg, hvorfor og hvorfor. Og, viktigere, alle disse endringene kan deretter rulles tilbake når som helst.

I samsvar med målet er det nødvendig å løse følgende oppgaver:

Definer konseptet for et versjonskontrollsystem;

Forstå hvordan slike systemer fungerer;

Gjennomgå installasjons- og lanseringsregler;

Analysere eksisterende versjonskontrollsystemer;

Vurder hovedtypene av denne typen system.

Målene for arbeidet bestemte strukturen på forhånd. Kursarbeidet består av fem kapitler, innledning, konklusjon, litteraturliste og vedlegg.

1. Konseptet med et versjonskontrollsystem

Versjonskontrollsystem (VCS) er programvare for å lette arbeidet med å endre informasjon. Et versjonskontrollsystem lar deg lagre flere versjoner av samme dokument, gå tilbake til tidligere versjoner om nødvendig, og bestemme hvem som har gjort en bestemt endring og når.

2. Bruke et versjonskontrollsystem

Disse typer systemer brukes mest i utviklingen programvare, slik at du kan lagre kildekodene til programmene som utvikles. VCS lar utviklere lagre tidligere versjoner av filer fra utvikling og hente dem derfra. Den lagrer versjonsinformasjon for hver fil (og hele prosjektstrukturen) i en samling som vanligvis kalles et depot. Men ikke desto mindre kan disse systemene brukes på andre kunnskapsområder, som inkluderer et stort antall elektroniske dokumenter som ofte endres. For eksempel brukes de i økende grad i CAD, vanligvis som en del av produktdatastyringssystemer (PDM). Versjonsstyring brukes i verktøy for konfigurasjonsadministrasjon.

Bruk av VCS er absolutt obligatorisk for utvikleren dersom prosjektet er på mer enn noen hundre linjer eller hvis flere utviklere jobber sammen om prosjektet.

Versjonskontrollsystemer løser følgende problemer:

Lagring av filversjoner;

Muligheten til å få tak i tidligere versjoner av lagrede filer;

Se endringer som er gjort mellom versjonene spesifisert i forespørselen;

3. Typisk prosedyre for arbeid med systemet

Hver VCS har sine egne spesifikke funksjoner i settet med kommandoer, hvordan brukere jobber og administrasjon. Imidlertid er den generelle operasjonsprosedyren for de fleste VCS-er fullstendig stereotypisk. Her forutsettes det at prosjektet, uansett hva det måtte være, allerede eksisterer og depotet ligger på serveren som utvikleren får tilgang til.

3.1 Komme i gang med prosjektet

Det første trinnet en utvikler må ta er å hente en arbeidskopi av prosjektet eller den delen av det som skal jobbes med. Denne handlingen utføres ved hjelp av en standardversjon utsjekkingskommando (kasse eller klone) eller en spesiell kommando som faktisk utfører samme handling. Utvikleren spesifiserer versjonen som skal kopieres; som standard kopieres vanligvis den nyeste versjonen (eller den som er valgt av administratoren som hoved).

Ekstraksjonskommandoen etablerer en tilkobling til serveren, og prosjektet i form av et tre med kataloger og filer kopieres til utviklerens datamaskin. En vanlig praksis er å duplisere en arbeidskopi: i tillegg til hovedkatalogen med prosjektet på lokal disk I tillegg er en annen kopi av den tatt opp. Når du jobber med et prosjekt, endrer utvikleren bare filene i hovedarbeidskopien. En annen lokal kopi lagres som en referanse, slik at du når som helst, uten å kontakte serveren, kan bestemme hvilke endringer som er gjort i spesifikk fil eller prosjektet som helhet og fra hvilken versjon arbeidskopien ble laget; som regel ethvert forsøk manuell endring denne kopien fører til feil i driften av VCS-programvaren.

3.2 Daglig arbeidssyklus

Med noen variasjoner bestemt av funksjonene til systemet og detaljene i den vedtatte forretningsprosessen, ser den vanlige syklusen av en utvikleres arbeid i løpet av en arbeidsdag slik ut:

1) Oppdatering av arbeidskopien. Når det gjøres endringer i hovedversjonen av prosjektet, blir arbeidskopien på utviklerens datamaskin gammel: avviket med hovedversjonen av prosjektet øker. Dette øker risikoen for motstridende endringer. Derfor er det praktisk å støtte arbeidskopi i en tilstand så nær den gjeldende hovedversjonen som mulig, hvor utvikleren utfører en oppdateringsoperasjon på arbeidskopien så ofte som mulig.

2) Endring av prosjektet. Utvikleren endrer prosjektet ved å endre de inkluderte filene i arbeidskopien i samsvar med designspesifikasjonen. Dette arbeidet utføres lokalt og krever ikke anrop til VCS-serveren.

3) Retting av endringer. Etter å ha fullført neste trinn av arbeidet med en oppgave, forplikter utvikleren endringene sine, overfører dem til serveren, enten til hovedgrenen, hvis arbeidet med oppgaven er fullstendig fullført, eller til en egen utviklingsgren for denne oppgaven. VCS kan kreve at utvikleren oppdaterer arbeidskopien før den forplikter seg. Hvis systemet støtter reolendringer, kan endringer overføres til serveren uten å binde seg. Hvis den godkjente arbeidspolitikken i hardvalutasystemet tillater dette, kan endringer ikke registreres daglig, men bare etter fullført arbeid med oppgaven; i dette tilfellet lagres alle endringer knyttet til jobben kun i utviklerens lokale arbeidskopi til jobben er fullført.

3.3 Grener

Du kan gjøre mindre korrigeringer i prosjektet ved å redigere arbeidskopien direkte og deretter overføre endringene direkte til hovedgrenen (trunken) på serveren. Men når du utfører en betydelig mengde arbeid, blir denne ordren upraktisk: mangelen på registrering av mellomliggende endringer på serveren tillater ikke arbeid med noe i en gruppemodus; i tillegg øker risikoen for å miste endringer under lokale ulykker og evne til å analysere og gå tilbake til tidligere er tapte kodevarianter innenfor dette arbeidet. Derfor, for slike endringer, er den vanlige praksisen å opprette grener, lage en versjon av en ny versjon av prosjektet eller en del av det, utviklingen av denne utføres parallelt med endringer i hovedversjonen. Når arbeidet som grenen ble opprettet for er fullført, blir grenen integrert i hovedgrenen. Dette kan gjøres med merge-kommandoen, eller ved å lage en oppdatering som inneholder endringer som er gjort under utviklingen av grenen og bruke denne oppdateringen på den gjeldende hovedversjonen av prosjektet.

3.4 Slå sammen versjoner

Tre typer operasjoner utført i versjonskontroll kan resultere i behov for å slå sammen endringer:

Oppdatering av arbeidskopien;

Registrering av endringer;

Slå sammen grener.

Hvert system har en automatisk sammenslåingsmekanisme som fungerer basert på følgende prinsipper:

Endringer kan bestå av å endre innholdet i en fil, opprette en ny fil eller katalog, slette eller gi nytt navn til en eksisterende fil eller katalog i prosjektet;

Hvis to endringer refererer til forskjellige og ikke-relaterte filer og/eller kataloger, kan de alltid slås sammen automatisk. Sammenslåingen deres er at endringene som er gjort i hver versjon av prosjektet kopieres inn i den sammenslåtte versjonen;

Opprette, slette og gi nytt navn til filer i prosjektkataloger kan slås sammen automatisk så lenge de ikke er i konflikt med hverandre. I dette tilfellet blir endringer gjort i hver versjon av prosjektet kopiert til den sammenslåtte versjonen.

De motstridende er vanligvis:

Slette og endre samme fil eller katalog;

Slette og gi nytt navn til samme fil eller katalog;

Skapelse i forskjellige versjoner fil med samme navn og forskjellig innhold;

Endringer innen en tekstfil laget i forskjellige versjoner kan kombineres hvis de er i forskjellige steder denne filen og ikke krysse hverandre. I dette tilfellet er alle endringer som er gjort inkludert i den sammenslåtte versjonen;

Endringer i samme fil, med mindre det er en tekstfil, er alltid motstridende og kan ikke slås sammen automatisk.

I alle tilfeller er basisversjonen som skal slås sammen versjonen der de sammenslåtte versjonene ble delt. Hvis dette er en commit-operasjon, vil basisversjonen være versjonen av den siste oppdateringen før commit; hvis en oppdatering, så versjonen av den forrige oppdateringen; hvis du slår sammen grener, så versjonen der den tilsvarende grenen ble opprettet. Følgelig vil endringssettene som sammenlignes være settene med endringer som er gjort fra base til gjeldende versjon i alle kombinerte varianter.

Absolutt flertall moderne systemer Versjonskontroll er først og fremst rettet mot programvareutviklingsprosjekter der hovedtypen filinnhold er tekst. Følgelig er mekanismene for automatisk sammenslåing av endringer fokusert på å behandle tekstfiler.

Når det skal avgjøres om det er tillatt å slå sammen endringer innenfor samme tekstfil, fungerer en standard linje-for-linje tekstsammenligningsmekanisme (et eksempel på implementeringen er GNU diff-systemverktøyet), som sammenligner de sammenslåtte versjonene med den grunnleggende og bygger en liste over endringer, det vil si lagt til, slettet og erstattet sett med linjer . Fante sett med modifiserte strenger som ikke krysser hverandre anses som kompatible, og deres sammenslåing gjøres automatisk. Hvis de sammenslåtte filene inneholder endringer som påvirker samme fillinje, fører dette til en konflikt. Slike filer kan bare slås sammen manuelt. Andre filer enn tekstfiler er binære fra VCS-synspunkt og tillater ikke automatisk sammenslåing.

3.5 Konflikter og deres løsning

En situasjon der endringene som er gjort i dem overlapper hverandre ved sammenslåing av flere versjoner, kalles en konflikt. Hvis det er en konflikt med endringer, kan ikke versjonskontrollsystemet automatisk opprette et sammenslått prosjekt, og er tvunget til å kontakte utvikleren. Som nevnt ovenfor kan det oppstå konflikter i stadier av å forplikte seg til endringer, oppdatere eller slå sammen grener. I alle tilfeller, når en konflikt oppdages, stoppes den tilsvarende operasjonen til den er løst.

For å løse en konflikt, tilbyr systemet generelt utvikleren tre alternativer for motstridende filer: base, lokal og server. Motstridende endringer vises enten til utvikleren i en spesiell programvaremodul for sammenslåing av endringer, eller er ganske enkelt merket med spesialmarkering direkte i teksten til den sammenslåtte filen.

Konflikter i filsystemet løses lettere: bare sletting av en fil kan komme i konflikt med en av de andre operasjonene, og rekkefølgen på filene i katalogen spiller ingen rolle, så utvikleren kan bare velge hvilken operasjon som skal lagres i sammenslått versjon.

3.6 Låser

Låsemekanismen lar en av utviklerne bare ta eget bruk en fil eller gruppe med filer å gjøre endringer i. Mens filen er låst, forblir den skrivebeskyttet for alle andre utviklere, og ethvert forsøk på å gjøre endringer i den blir avvist av serveren. Teknisk sett kan blokkering organiseres på forskjellige måter. Følgende mekanisme er typisk for moderne systemer:

Filer som krever låsing for å jobbe med er merket med et spesielt flagg "låst";

Hvis en fil er merket som låst, blir den gitt et skrivebeskyttet attributt på det lokale filsystemet når en arbeidskopi hentes fra serveren, som forhindrer at den blir redigert ved et uhell;

En utvikler som ønsker å endre en låst fil kaller spesiallag lås (lås) som indikerer navnet på denne filen. Resultatet av denne kommandoen er følgende:

1. serveren sjekker om filen allerede er blokkert av en annen utvikler; i så fall mislykkes blokkeringskommandoen.

2. filen på serveren er merket som "blokkert", med IDen til utvikleren som blokkerte den og blokkeringstiden lagres;

3. Hvis blokkeringen på serveren er vellykket, fjernes "skrivebeskyttet"-attributtet fra arbeidskopifilen på det lokale filsystemet, som lar deg begynne å redigere den.

Hvis det under operasjonen viser seg at filen ikke trenger å endres, kan han ringe opp kommandoen , utløserlås). Alle endringer i filen vil bli angret, den lokale filen vil gå tilbake til en skrivebeskyttet tilstand, attributtet "låst" vil bli fjernet fra filen på serveren, og andre utviklere vil kunne endre denne filen;

Etter fullført arbeid med den låste filen, forplikter utvikleren endringene. Vanligvis fjernes blokkeringen automatisk.

3.7 Prosjektversjoner, tagger

Versjonskontrollsystemet sikrer lagring av alle eksisterende versjoner av filer og, som et resultat, alle versjoner av prosjektet som helhet som har skjedd siden begynnelsen av utviklingen. Men selve konseptet "versjon" i ulike systemer kan tolkes på to forskjellige måter.

Noen systemer støtter filversjon. Dette betyr at enhver fil som vises i prosjektet mottar eget nummer versjoner. Når en utvikler forplikter endringer til en fil, blir den tilsvarende delen av de forpliktede endringene brukt på filen, og filen mottar et nytt, vanligvis sekvensielt, versjonsnummer.

For andre systemer refererer konseptet "versjon" ikke til en individuell fil, men til hele depotet. Et nyopprettet tomt depot har en versjon på 1 eller 0, eventuelle commit-endringer fører til en økning i dette antallet. Det er faktisk ikke noe versjonsnummer for en individuell fil her.

Begge alternativene er imidlertid ikke veldig praktiske. For mer praktisk å merke prosjektversjoner, støtter versjonskontrollsystemer konseptet med tagger.

En tag er en symbolsk etikett som kan assosieres med en spesifikk versjon av en fil og/eller katalog i et depot. Ved å bruke riktig kommando kan alle eller deler av prosjektfilene som oppfyller visse betingelser, tildeles en gitt etikett. På denne måten kan du identifisere versjonen av prosjektet ved å fikse tilstanden på et ønsket tidspunkt. Som regel er tagging-systemet ganske fleksibelt og lar deg merke flere versjoner av filer og kataloger med én tag. Dette lar deg bygge en "prosjektversjon" på en hvilken som helst vilkårlig måte.

4.1 Lokale versjonskontrollsystemer

Den mest foretrukne VCS for overvåking av boligutvikling vil være den lokale typen. For å løse dette problemet ble det utviklet spesielle VCS-er med en enkel database der alle lokale filer er lagret.

Figur 4.1 Opplegg for lokal SCR

En av de mest populære VCS-ene av denne typen er RCS, som fortsatt er installert på mange datamaskiner.

4.2 Sentralisert modell

Tradisjonelle versjonskontrollsystemer bruker en sentralisert modell, hvor det er et enkelt dokumentlager som administreres spesiell server, som utfører de fleste versjonskontrollfunksjonene. En bruker som arbeider med dokumenter må først hente versjonen av dokumentet han trenger fra depotet; Vanligvis opprettes en lokal kopi av dokumentet, den såkalte "arbeidskopien". Den siste versjonen eller noen av de tidligere kan fås, som kan velges etter versjonsnummer eller opprettelsesdato, noen ganger etter andre kriterier. Etter at nødvendige endringer er gjort i dokumentet, legges den nye versjonen i depotet. I motsetning til bare å lagre en fil, slettes ikke den forrige versjonen, men forblir også i lagringen og kan hentes derfra når som helst.

Slike systemer, som CVS, Subversion og Perforce, har en sentral server som lagrer alle filer under versjonskontroll, og en rekke klienter som mottar kopier av filene fra den. Dette har vært standarden for versjonskontrollsystemer i mange år.

Figur 4.2 Sentralisert versjonskontrollskjema

Denne tilnærmingen har mange fordeler, spesielt i forhold til lokal SLE. For eksempel vet alle hvem som gjør hva i prosjektet. Administratorer har klar kontroll over hvem som kan gjøre hva, og selvfølgelig er CSKB mye enklere å administrere enn lokale databaser på hver klient.

Imidlertid er det flere alvorlige ulemper ved denne tilnærmingen. Det mest åpenbare er at den sentraliserte serveren er det svake punktet i hele systemet. Hvis serveren går ned i en time, kan ikke utviklere samhandle på en time, og ingen kan lagre en ny versjon av arbeidet sitt. Hvis disken med den sentrale databasen er skadet og det ikke er noen sikkerhetskopi, mister du absolutt alt - hele historien til prosjektet, med unntak av noen få fungerende versjoner lagret på brukernes arbeidsmaskiner. Lokale VCS-er er underlagt det samme problemet: Hvis hele prosjekthistorikken er lagret på ett sted, risikerer du å miste alt.

4.3 Distribuerte versjonskontrollsystemer

Slike systemer bruker en distribuert modell i stedet for den tradisjonelle klient-server-modellen. Generelt trenger de ikke en sentralisert lagring: hele historikken for dokumentendringer lagres på hver datamaskin, i lokal lagring, og om nødvendig blir individuelle fragmenter av den lokale lagringshistorikken synkronisert med en lignende lagring på en annen datamaskin. Derfor, i tilfelle serveren som arbeidet gikk ned gjennom, går ned, kan et hvilket som helst klientlager kopieres tilbake til serveren for å gjenopprette databasen. I noen av disse systemene er lokal lagring plassert direkte i arbeidskopikatalogene.

Figur 4.3 Distribuert VCS-modell

Når en bruker av et slikt system utfører vanlige handlinger, som å hente en spesifikk versjon av et dokument, lage en ny versjon og lignende, jobber han med sin lokale kopi av depotet. Etter hvert som endringer blir gjort, begynner depoter som tilhører forskjellige utviklere å variere, og det er behov for å synkronisere dem. Slik synkronisering kan oppnås ved å utveksle patcher eller såkalte sett mellom brukere.

Den beskrevne modellen er logisk sett nær å lage en egen gren for hver utvikler i et klassisk versjonskontrollsystem. Forskjellen er at før synkronisering ser ikke andre utviklere denne grenen. Så lenge en utvikler kun endrer sin egen gren, påvirker ikke arbeidet hans andre prosjektmedlemmer og omvendt. Etter ferdigstillelse av den separate delen av arbeidet, slås endringene som er gjort på grenene sammen med hovedgrenen (felles). Både ved sammenslåing av grener og ved synkronisering av ulike depoter er versjonskonflikter mulig. I dette tilfellet gir alle systemer visse metoder for å oppdage og løse flettekonflikter.

Fra brukerens synspunkt kjennetegnes et distribuert system av behovet for å opprette et lokalt depot og tilstedeværelsen av kommandospråk to ekstra kommandoer: kommandoen for å motta et arkiv fra en ekstern datamaskin og overføre arkivet til den eksterne datamaskinen. Den første kommandoen slår sammen endringer fra de eksterne og lokale depotene og plasserer resultatet i det lokale depotet; den andre, tvert imot, slår sammen endringer fra to depoter og plasserer resultatet i et eksternt depot. Vanligvis lar flettekommandoer i distribuerte systemer deg velge hvilke sett med endringer som skal skyves til eller trekkes fra et annet depot, korrigere flettekonflikter direkte under operasjonen eller etter dens feil, og prøve på nytt eller gjenoppta en uferdig sammenslåing. Vanligvis lykkes overføring av endringene til andres depot bare hvis det ikke er noen konflikter. Hvis det oppstår konflikter, må brukeren først slå sammen versjonene i depotet sitt, og først deretter overføre dem til andre.

Det anbefales vanligvis å organisere arbeidet med systemet slik at brukere alltid eller overveiende utfører sammenslåinger i depotene sine. Det vil si, i motsetning til sentraliserte systemer, der brukere sender inn endringene sine til den sentrale serveren når de finner det passende, i distribuerte systemer er det mer naturlig å få versjonssammenslåingen initiert av personen som trenger å motta resultatet (for eksempel en utvikler som administrerer en byggeserver).

De viktigste fordelene med distribuerte systemer er deres fleksibilitet og betydelig større (sammenlignet med sentraliserte systemer) autonomi for en individuell arbeidsplass. Hver utviklers datamaskin er faktisk en uavhengig og fullt funksjonell server; fra slike datamaskiner kan du bygge et system av enhver struktur og kompleksitetsnivå ved å angi ønsket synkroniseringsrekkefølge.

Ulempene med distribuerte systemer inkluderer en økning i det nødvendige volumet diskminne: hver datamaskin må lagre en fullstendig versjonshistorikk, mens i et sentralisert system er det vanligvis bare en arbeidskopi som lagres på utviklerens datamaskin, det vil si en del av depotet på et tidspunkt og endringene som er gjort. En mindre åpenbar, men ubehagelig ulempe er at det er nesten umulig å implementere noe av funksjonaliteten fra sentraliserte systemer i et distribuert system. Dette:

- Blokkering av en fil eller gruppe med filer (for å lagre blokkeringsattributtet kreves det en sentral server som er offentlig tilgjengelig og konstant online). Dette tvinger spesielle administrative grep om man må jobbe med binære filer som ikke egner seg for automatisk sammenslåing;

- Overvåking av en bestemt fil eller gruppe av filer;

- En enkelt kontinuerlig nummerering av systemversjoner og/eller filer, der versjonsnummeret øker monotont. I distribuerte systemer må man nøye seg med lokale versjonsbetegnelser og brukstagger, hvis formål er bestemt av en avtale mellom utviklere eller selskapets bedriftsstandarder;

- Lokale brukere arbeider med en separat prøve med lite volum fra et lagringsanlegg av betydelig størrelse og intern kompleksitet på en ekstern server.

Følgende typiske situasjoner kan identifiseres der bruken av et distribuert system gir merkbare fordeler:

- Periodisk synkronisering av flere datamaskiner under kontroll av én utvikler. Bruk av et distribuert system eliminerer behovet for å tildele en av datamaskinene som en server;

- Samarbeid om et prosjekt av en liten, geografisk fordelt gruppe utviklere uten tildeling av delte ressurser. Som i det forrige tilfellet implementeres et arbeidsskjema uten en hovedserver, og relevansen til depotene opprettholdes av periodiske synkroniseringer i henhold til "alle med alle"-skjemaet;

Et stort distribuert prosjekt, hvor deltakerne kan jobbe på hver sin side i lang tid, men ikke har en konstant tilknytning til nettverket. Et slikt prosjekt kan bruke en sentralisert server, som kopier av alle deltakerne synkroniseres med. Det er mulig å jobbe uten "gruppe"-servere, deretter synkroniserer utviklere av en gruppe endringer seg imellom, hvoretter enhver av dem overfører endringene til den sentrale serveren.

5. Eksempler på versjonskontrollsystemer

5.1 GIT

5.1.1 Systemkrav

Git Fungerer under følgende operativsystemer: Windows, Linux og Mac OS.

For å installere Git på Windows trenger du bare å laste ned exe-installasjonsfilen fra prosjektsiden på GitHub og kjøre den. Etter installasjonen vil du ha både en konsollversjon (inkludert en SSH-klient) og en standard grafisk.

5.1.2 Konsept

Git er et distribuert versjonskontrollsystem. I den kan filer være i en av tre tilstander: forpliktet, modifisert og forberedt. "Committed" betyr at filen allerede er lagret i din lokale database. Endrede filer inkluderer filer som har endret seg, men som ennå ikke er ferdigbehandlet. Iscenesatte filer er modifiserte filer som er merket for inkludering i neste commit.

Dermed har prosjekter som bruker Git tre deler: Git-katalogen, arbeidskatalogen og oppsamlingsområdet.

Git-katalogen er der Git lagrer prosjektets metadata og objektdatabase. Det er den viktigste delen av Git, og er det som kopieres når du kloner et depot fra en annen datamaskin.

Arbeidskatalogen er en kopi av en spesifikk versjon av prosjektet hentet fra databasen. Disse filene hentes fra en komprimert database i Git-katalogen og legges på disken slik at du kan se og redigere dem.

Staging-området er en vanlig fil, vanligvis lagret i Git-katalogen, som inneholder informasjon om hva som skal gå inn i neste commit. Det kalles noen ganger indeksen, men nylig har det blitt standard å kalle det staging-området ( staging area) .

En standard arbeidsflyt med Git ser omtrent slik ut:

1. Du gjør endringer i filene i arbeidskatalogen din.

2. Forbered filer ved å legge til øyeblikksbilder i området for forberedte filer.

3. Gjør en commit som tar de forberedte filene fra indeksen og plasserer dem i Git-katalogen for permanent lagring.

Hvis arbeidsversjonen av filen samsvarer med versjonen i Git-katalogen, anses filen som committed. Hvis filen endres, men legges til det forberedte dataområdet, forberedes den. Hvis filen endret etter utlasting fra databasen, men ikke var utarbeidet, så anses det som endret.

5.1.3 Komme i gang

Alle jobber i Git finner sted inne i et depot som inneholder alle arbeidets filer. Du kan opprette et depot på forskjellige måter.

1. Via kontekstmenyen. For å gjøre dette trenger du bare å høyreklikke i ønsket katalog og velge Git Init Here.

Figur 5.1.1 Opprette et depot ved hjelp av kontekstmenyen

2. Bruke kommandolinjen. For å gjøre dette på samme måte, i den nødvendige katalogen, velg Git Bash i kontekstmenyen. En kommandolinje åpnes der vi oppretter depotet ved å bruke Git Init-kommandoen.

Figur 5.1.2 Opprette et depot ved hjelp av kommandolinjen

Hvis du aldri har brukt git før, må du først skrive inn navn og e-post ved å bruke henholdsvis følgende kommandoer:

git config --global bruker.navn "Ditt navn"

git config --global bruker.e-post [e-postbeskyttet]

Det opprettede depotet vil inneholde en .git-katalog. For å legge til en fil til depotet, trenger du bare å kopiere den til arbeidskatalogen din. La oss legge til ex.txt-filen til depotet. Ved å bruke git status-kommandoen vil vi sørge for at Git har sett filen.

Figur 5.1.3 Legge til og sjekke en fil i depotet

Deretter, for å legge til en fil under versjonskontroll, bør du indeksere disse filene og utføre den første commit av endringer. Dette kan gjøres med noen få git add-kommandoer som spesifiserer filene som skal indekseres, og deretter git commit.

Figur 5.1.4 Legge til en fil under versjonskontroll

Git status-kommandoen er hovedverktøyet som brukes til å bestemme hvilke filer som er i hvilken tilstand.

For å begynne å spore (legg til under versjonskontroll) en ny fil, bruk git add “filename” kommandoen. Denne kommandoen tar som en parameter banen til en fil eller katalog, hvis det er en katalog, legger kommandoen rekursivt til (indekserer) alle filene i den gitte katalogen.

Git commit -m “comment” er en kommando for å lage en commit, fikse en endring.

Ved å bruke det grafiske grensesnittet til Git Gui vil vi gjenta forrige operasjon. For å gjøre dette, velg Git Gui-elementet i kontekstmenyen.

Figur 5.1.5

I vinduet som åpnes velger du "Opprett et nytt depot." Deretter angir vi katalogen der vi ønsker å plassere depotet.

Figur 5.1.6 Opprette et depot i Git Gui

Legg til Ex.txt-filen i katalogen. Klikk deretter på "Reread"-knappen. For å legge til en fil i versjonskontroll, må du klikke på "Forbered alle"-knappen. Ex.txt-filen skal flytte fra "Changed"-vinduet til "Prepared"-vinduet. For å fikse endringen, bruk "Lagre"-knappen.

5.1.5 Opprette en kopi av depotet

I disse dager har du et stort antall hostingalternativer å velge mellom, alle med sine egne fordeler og ulemper.

I denne delen går vi gjennom prosessen med å opprette en konto og et nytt prosjekt på GitHub. Dette vil gi deg en ide om hva som er involvert.

GitHub er den største Git-vertssiden for åpen kildekode-prosjekter i dag, og en av få som tilbyr både offentlig og privat hosting.

Det første du må gjøre er å sette opp en konto og opprette depotet ditt på http://github.com/plans.

Deretter, på Git-kommandolinjen, skriv inn kommandoene vi allerede kjenner:

Git legg til ex.txt

Git commit -m "comment"

Git ekstern legg til opprinnelse https://github.com/Arbuz-z-z/MyHomework.git

Git push -u origin master

Git remote add-kommandoen er for å legge til eksterne repositories, og git push-kommandoen er for å skyve lokale endringer til en ekstern server.

Figur 5.1.7

Skriv inn brukernavnet og passordet som ble spesifisert under registreringen:

Figur 5.1.8

Nå er prosjektet vårt lagt ut på GitHub, i depotet - MyHomework med filen Tusur.txt og vi kan gi en lenke til den til alle vi ønsker å dele prosjektet med.

Figur 5.1.9 Repository på GitHub

5.2 TortoiseSVN

5.2.1 Systemkrav

TortoiseSVN kjører på Windows XP (med Service Pack 3) eller høyere, og er tilgjengelig i både 32-biters og 64-biters versjoner. Installasjonsprogrammet for 64-biters Windows inkluderer også en 32-bits del.

5.2.2 Installasjon

TortoiseSVN kommer som en enkel å bruke installasjonsfil.

5.2.3 Grunnleggende konsept

Oppbevaring. Subversion bruker en sentral database som inneholder alle versjonerte filer med deres full historie. Denne databasen kalles et depot. Lageret er vanligvis plassert kl filserver, som Subversion er installert på, og leverer data til Subversion-klienter (for eksempel TortoiseSVN) på forespørsel. Hvis du gjør backup, og kopier deretter lagringen din, siden den er originalen av alle dataene dine.

Arbeidskopi. Det er akkurat her du jobber. Hver utvikler har sin egen arbeidskopi, noen ganger kalt en sandkasse, på sin lokale datamaskin. Du kan få det fra depotet siste versjon filer, arbeid med det lokalt uten å samhandle med noen andre, og når du er sikker på endringene, kan du overføre disse filene tilbake til depotet. Arbeidskopien inneholder ikke historien til prosjektet, men inneholder en kopi av alle filene som var i depotet før du begynte å gjøre endringer.

TortoiseSVN er en Windows Explorer-utvidelse, så først må du starte Explorer.

Figur 5.2.1 Visning i Utforsker

5.2.4 Opprette et depot

For dette prosjektet trenger vi et depot opprettet på et sikkert sted og en Subversion-server for å administrere det. Vi kommer til å bruke Subversions lokale lagringsfunksjon, som gir direkte tilgang til lagring opprettet på harddisken din og ikke krever en server.

La oss først lage en ny tom katalog på PC-en. Det kan være hvor som helst, men for denne opplæringen skal vi kalle det s:\svn_repos. Nå, høyreklikk på den nye mappen og velg TortoiseSVN fra kontekstmenyen > Opprett depot her... Depotet som er opprettet inne i mappen er klart til bruk. Vi vil også opprette en intern mappestruktur ved å klikke på knappen "Opprett katalogstruktur".

Figur 5.2.2 Opprette et depot

Figur 5.2.3 Bla gjennom repository

5.2.5 Importere et prosjekt

Vi har for tiden lager, men det er helt tomt for øyeblikket. La oss anta at vi har et sett med filer i E:\\TortoiseSVN som vi ønsker å legge til. La oss gå til TortoiseSVN-mappen i Utforsker og høyreklikke på den. Velg nå TortoiseSVN > Importer..., som vil få opp en dialogboks.

Figur 5.2.4 Importvindu

Subversion-depotet er tilgjengelig med en URL, som lar oss peke til depotet hvor som helst på Internett. I i dette tilfellet vi må peke på vårt lokale depot, som har URL-filen:///s:/svn_repos, og som vi legger til navnet på vårt TortoiseSVN-prosjekt.

En annen viktig funksjon i denne dialogboksen er vinduet Importer melding, hvor vi kan legge til en melding om hva vi gjør. Når vi trenger å gå gjennom historien til et prosjekt, vil disse meldingene være en verdifull hjelp for å se hvilke endringer som ble gjort og når.

5.2.6 Sjekke ut en arbeidskopi

Nå har vi et prosjekt i depotet vårt, og vi må lage en arbeidskopi for det daglige arbeidet. Det er verdt å merke seg at import av en mappe ikke automatisk gjør den mappen til en arbeidskopi. For å lage en ny arbeidskopi bruker Subversion begrepet "Check Out". Vi skal trekke ut TortoiseSVN-mappen fra vårt depot til en utviklingsmappe kalt e:\\TortoiseSVN\svn_repos. La oss lage denne mappen, høyreklikk på den og velg TortoiseSVN > Pakk ut... Skriv inn URL-en som skal pakkes ut, i dette tilfellet file:///s:/svn_repos/TortoiseSVN, og klikk OK. Utviklingsmappen vår vil bli fylt med filer fra depotet.

Utseendet til denne mappen er forskjellig fra en vanlig mappe. Hver fil har nå et grønt flagg i venstre hjørne. Dette er TortoiseSVN-statusikoner som bare finnes i arbeidskopien. Grønn status betyr at filen ikke skiller seg fra versjonen av filen i depotet.

5.2.7 Gjøre endringer

Du kan begynne å jobbe. I mappe TortoiseSVN vi begynner å endre filer - la oss si at vi gjør endringer i TortoiseSVN.docx-filene. Merk at ikonene på disse filene nå er røde og indikerer at endringer ble gjort lokalt.

Høyreklikk på en av de modifiserte filene og velg TortoiseSVN > Forskjeller. TortoiseSVN-filsammenligningsverktøyet vil starte og vise deg nøyaktig hvilke linjer i filene som ble endret.

Figur 5.2.5 Filsammenligning

La oss nå oppdatere lagringen. Denne handlingen kalles "Commit Changes". La oss klikke Høyreklikk på TortoiseSVN-mappen og velg TortoiseSVN > Commit-kommandoen. En forpliktelsesdialog vil vises med en liste over endrede filer, og det vil være et hakemerke ved siden av hver enkelt. Vi kan bare velge noen få filer fra listen for å forplikte.

Figur 5.2.6 Committing filer

5.2.8 Legge til nye filer

Mens vi jobber med prosjektet, trenger vi legg til nye filer, anta at vi har lagt til nye funksjoner i en fil og lagt til hjelp i en eksisterende fil. Høyreklikk på mappen og velg TortoiseSVN > Legg til. Legg til-dialogen viser alle uversjonerte filer, og vi kan velge filene vi vil legge til. En annen måte å legge til filer på er å høyreklikke på selve filen og velge TortoiseSVN > Legg til.

Hvis vi nå åpner commit-mappen, vil den nye filen vises som "Lagt til" og den eksisterende filen som "Endret".

5.2.9 Avbryt endringer

Et fellestrekk ved alle revisjonsstyringssystemer er funksjonen som lar oss angre endringer som vi tidligere har gjort.

Hvis vi ønsker å bli kvitt endringer som vi ennå ikke har klart å registrere og gjenopprette nødvendig fil i den formen den var før endringene begynte, velg deretter kommandoen TortoiseSVN > Fjern endringer. Denne handlingen vil angre endringene våre og returnere den faste versjonen av filen vi startet med. Hvis vi bare vil fjerne noen endringer, kan vi bruke TortoiseMerge-verktøyet for å se endringene og selektiv sletting endret linjer.

Hvis vi ønsker å angre en spesifikk revisjon, starter vi med loggdialogen og finner den problematiske revisjonen. Velg kommandoen Kontekstmeny > Forkast endringer fra denne revisjonen, og disse endringene vil bli forkastet.

5.2.10 TortoiseSVN-funksjoner. Shell-integrasjon

TortoiseSVN integreres direkte i Windows-skallet (dvs. Explorer). Dette betyr at du kan jobbe med verktøyene du allerede er kjent med, og ikke trenger å bytte til en annen applikasjon hver gang du trenger versjonskontrollfunksjoner!

Og du trenger ikke engang å bruke Explorer. TortoiseSVNs kontekstmenyer fungerer i mange andre filbehandlere, og i filen åpner dialoger som brukes i de fleste standard Windows-applikasjoner. Du bør imidlertid være oppmerksom på at TortoiseSVN opprinnelig er designet som en utvidelse for Windows Utforsker, og andre applikasjoner har kanskje ikke full integrasjon, for eksempel ikonoverlegg som kanskje ikke vises.

Statusen til hver versjonsfil og mappe er angitt med et lite merke på toppen av hovedikonet. På denne måten kan du se statusen til arbeidskopien din med et øyeblikk.

5.2.11 Grafisk brukergrensesnitt

Når du ser på en liste over endringer i en fil eller mappe, kan du klikke på en revisjon for å se kommentarene for den forpliktelsen. En liste over endrede filer er også tilgjengelig - bare dobbeltklikk på en fil for å se hvilke spesifikke endringer som er gjort.

Forpliktelsesdialogen er en liste som viser alle filene og mappene som vil bli inkludert i forpliktelsen. Hvert listeelement har en avmerkingsboks slik at du kan velge nøyaktig hva du vil inkludere i forpliktelsen. Uversjonerte filer kan også være til stede i denne listen, slik at du ikke glemmer å legge til en ny fil eller mappe til commit.

Alle Subversion-kommandoer er tilgjengelige fra Explorer-kontekstmenyen. TortoiseSVN legger til sin egen undermeny der.

5.3 Mercurial

5.3.1 Systemkrav

P Mercurial-pakker er tilgjengelige for alle populære operativsystemer: Windows, Mac OS, Linux (Ubuntu, Debian, Fedora, OpenSUSE, Gentoo), Solaris.

Den beste versjonen av Mercurial for Windows er TortoiseHg, som finnes på http://tortoisehg.org. Denne pakken tillater kommandolinje og grafisk brukergrensesnitt.

5.3.2 Konsept

Mercurial er et distribuert (desentralisert) versjonskontrollsystem. Dette betyr at arbeidsflyten vanligvis ser slik ut:

1. På personlig datamaskin et nytt depot opprettes (ved å klone et eksisterende depot, opprette et nytt osv.);

2. Filer endres/legges til/slettes i arbeidskatalogen til dette depotet;

3. Endringer er forpliktet til dette depotet (det vil si til et lokalt depot på en personlig datamaskin);

4. Trinn 2 og 3 gjentas så mange ganger som nødvendig;

5. Om nødvendig synkroniseres endringer med andre depoter: andres endringssett trekkes og/eller deres egne skyves.

Det vil si at alt daglig arbeid skjer i det lokale depotet, og når behovet oppstår, sendes resultatene av deres arbeid til ett eller flere andre depoter. Antall trinn når du arbeider med eksterne repositories kan reduseres ved å sette Mercurial til automatisk sending endringer til andre depoter ved forpliktelse.

5.3.3 Komme i gang

Du kan jobbe i Mercurial gjennom kontekstmenyen i Explorer, arbeidsområdevinduet TortoiseHg Workbench (programmet lager en tilsvarende snarvei under installasjonen) eller kommandolinjen ved å bruke hg-kommandoen.

5.3.4 Opprette et depot og arbeide med filer

I Mercurial skjer alt inne i depotet. Prosjektlageret inneholder alle filene som er "relatert" til prosjektet, samt endringshistorikken til disse filene. Det er tre forskjellige måter å lage et depot på.

For å opprette et depot gjennom Utforsker-kontekstmenyen, høyreklikk ganske enkelt på ønsket mappe og velg det aktuelle elementet.

Figur 5.3.1 Opprette et depot

I vinduet som vises kan du bekrefte plasseringen til depotmappen og åpne det opprettede depotet i produksjonsmiljøet.

Figur 5.3.2 Plassering av depotmappen

Depotet opprettes på lignende måte direkte i TortoiseHg Workbench-vinduet: File\New Repository-sekvensen kaller opp vinduet ovenfor med samme navn. På kommandolinjen bruker du hg init-kommandoen til å opprette et depot i gjeldende katalog<имя хранилища>. Det opprettede depotet vil inneholde en .hg-katalog.

Figur 5.3.3 Opprette en depotmappe via kommandolinjen

Hvis vi vil legge til eksisterende filer til depotet, kopierer vi dem inn i arbeidskatalogen og bruker hg add-kommandoen for å fortelle Mercurial om å begynne å overvåke dem. La oss legge til filen i depotet og lage en ny revisjon.

Figur 5.3.4 Legge til en fil til depotet og opprette en ny revisjon

La oss sørge for at Mercurial ser den lagrede filen. Statuskommandoen viser statusen til arbeidskopien sammenlignet med statusen til det lokale depotet. Mercurial viser at den ser filen example.txt, men den filen er ennå ikke under versjonskontroll (tegnet "?" til venstre for filnavnet). For å fortelle Mercurial at den må versjonsrelateres, kjører vi hg add. Symbolet "A" vises til venstre for filnavnet, noe som betyr at readme.txt-filen vil bli lagt til i versjonskontrollsystemet under neste commit (når du oppretter en ny revisjon), som utføres med hg commit-kommandoen .

hg commit-kommandoen kan mislykkes første gang. Mercurial registrerer navnet og adressen din med hver revisjon slik at du eller andre brukere kan kontakte forfatteren av hver endring. For å angi brukernavnet må du gjøre endringer i hgrc-filen som ligger i .hg-katalogen i arbeidskatalogen. Det første innholdet i denne filen skal se omtrent slik ut:

# Dette er en Mercurial-konfigurasjonsfil.

brukernavn = Fornavn Etternavn [e-postbeskyttet]

Linjen "" erklærer en del av konfigurasjonsfilen. Du kan lese "brukernavn =..." som "sett verdien av brukernavnvariabelen i ui-delen". Seksjoner fortsetter til nye seksjoner begynner. Blanke linjer og linjer som begynner med "#" ignoreres. Du kan bruke hvilken som helst tekst som brukernavnverdi, siden denne informasjonen er ment for andre å bruke og ikke for Mercurial å tolke. Eksemplet ovenfor brukte en vanlig konvensjon for dette: en kombinasjon av navn og e-postadresse.

Når vi foretar endringer, tar Mercurial oss til et tekstredigeringsprogram for å legge inn en kommentar som beskriver endringene vi har gjort i endringssettet. En slik beskrivelse kalles endringsmelding (beskrivelse av endringer, beskrivelse av revisjon). Dette vil være en rekord for lesere av hva vi gjorde og hvorfor, og vil bli utgitt når vi kjører hg-logg etter at vi er ferdige med å publisere revisjonen.

Editoren som åpnes når du kjører hg commit vil inneholde en tom linje og flere linjer som starter med "HG:".

HG: Skriv inn commit-melding. Linjer som begynner med "HG:" fjernes.

HG: La meldingen stå tom for å avbryte commit.

HG: --

HG: bruker: bruker

HG: gren "standard"

HG: endret eksempel.txt

Mercurial ignorerer linjer som begynner med "HG:". Den bruker dem bare til å fortelle oss hvilke filer den vil skrive endringer til. Redigering eller sletting av disse linjene vil ikke påvirke noe. Hvis du ombestemmer deg om å publisere endringer mens du redigerer en kommentar, går du ganske enkelt ut av redigeringsprogrammet uten å lagre filen blir endret. Dette vil ikke føre til endringer i verken depotet eller arbeidskatalogen.

Kommandoen hg log skriver som standard bare den første linjen i endringsbeskrivelsen. Derfor er det bedre å skrive kommentaren slik at den første linjen skilles. Det er ingen harde og raske regler for resten av revisjonsbeskrivelsen. Mercurial selv behandler eller bryr seg ikke om innholdet i endringsmeldinger, selv om prosjektet ditt kan ha regler som dikterer bestemt formatering.

La oss gjenta disse operasjonene ved å bruke TortoiseHg Workbench GUI. Før du legger til filen i arbeidskatalogen, ser vinduet slik ut.

Figur 5.3.5 Legge til en fil i arbeidskatalogen

La oss overføre filen til depotet og oppdatere vinduet ved å klikke på knappen til venstre på verktøylinjen. La oss legge til filen i versjonskontrollsystemet ved å bruke den riktige kontekstmenykommandoen (lik hg add).

Figur 5.3.6 Kontekstmenykommando

Figur 5.3.7 Legge til en fil

Etter at filen er lagt til, skrives en beskrivelse av revisjonen i vinduet øverst til høyre, og en ny revisjon opprettes ved å klikke på "Commit"-knappen. En oversikt over endringene som er gjort vises i vinduet nederst til høyre. Du vil legge merke til at endringene er representert i form av grafer.

Figur 5.3.8 Endre grafer

Du kan også foreta endringer ved å bruke Hg Commit-kommandoen i kontekstmenyen til en fil som er plassert i depotet, uten å starte Workbench.

Figur 5.3.9 Forplikte endringer

Kommandoen hg log eller hg diff her tilsvarer "Sammenlign filrevisjoner" (høyreklikk på filnavnet).

Figur 5.3.10 Sammenligning av filrevisjoner

I samme vindu kan du gå tilbake til en av de tidligere revisjonene ved å bruke kommandoen "Gå tilbake til revisjon..." eller "Tilbakestill endringer..." i hovedvinduet. La oss demonstrere med et eksempel, etter først å ha registrert noen flere endringer i example.txt-filen. Linjen uthevet i rødt er reverserte endringer.

Figur 5.3.11 Avbryt endringer

5.3.5 Opprette en kopi av depotet

Selv om du kan kopiere depotet som en vanlig katalog, er det bedre å bruke Mercurials innebygde kommando. Det kalles hg clone fordi det lager en identisk kopi av et eksisterende depot. En av fordelene med å bruke hg clone er at den lar deg klone depoter over nettverket. En annen er at den husker hvor vi klonet den fra.

Hvert Mercurial-lager er komplett, selvstendig og uavhengig. Den inneholder sin egen kopi av prosjektfilene og deres historie. Et klonet depot husker hvor det ble klonet fra, men kommuniserer ikke med det depotet, eller noe annet, før du ber det om det. Derfor står du fritt til å eksperimentere med depotet ditt. Dette er trygt fordi depotet ditt er en "lukket sandkasse", endringer som ikke vil påvirke noe annet enn seg selv.

La oss lage en ekstern kopi av lagringen vår (vi vil bruke Google Drive-mappen, som i seg selv er en skytjeneste), som vi vil utføre kommandosekvensen File\Clone storage i TortoiseHg Workbench for. Resultatet er vist i følgende figur.

Figur 5.3.12 Opprette en ekstern kopi av lagringen

Mercurial lar oss flytte endringer til et annet depot fra depotet vi er i dette øyeblikket vi er. La oss legge til en ny revisjon (under den lokale endringskommentaren) til kildelageret og utføre kommandoen Storage\Synchronization\Push. Grensesnitt arbeidsmiljø lar deg velge bare de revisjonene som må skyves. Vær oppmerksom på at en ny gren ble opprettet i det eksterne hvelvlageret for den mottatte revisjonen.

...

Lignende dokumenter

Mulighetene til et versjonskontrollsystem - et program designet for å jobbe med endrede dokumenter. Dens egenskaper og brukspraksis. Innvendig struktur i lageret. Arbeidskopi av versjonsdokumenter. Sentralisert og distribuert VCS.

presentasjon, lagt til 01.05.2014


Analyse av metoder og midler for tilgangskontroll til filer. Sikkerhetsproblemer ved arbeid med filer, tilgangskontrollverktøy. Ideologi for grensesnittkonstruksjon, arkitektoniske krav. Drift av systemklasser. Estimering av kostnaden for et programvareprodukt.

avhandling, lagt til 21.12.2012


Analyse av Windows 8 OS-arkitekturen. Sammenligning med tidligere versjoner (Moderne UI-grensesnitt, arbeid med kontoer, sikkerhetsmodell, oppgavebehandling, filhistorikk, systemgjenoppretting, lagringsplasser). Funksjoner for forskjellige versjoner av Windows 8.

kursarbeid, lagt til 25.01.2016


Utviklingsstadier automatisert system ta imot og bestille bordbestillinger i etablissementer. Analyse av utviklingsmiljøet for Android Development Tools. generelle egenskaper komponentdiagrammer iOS-applikasjoner. Hensyn til serverversjonskontrollsystemet.

kursarbeid, lagt til 14.05.2014


Grafiske grensesnitt og utvidelser for DOS. Historie om utviklingen av Microsoft Windows-operativsystemet. Innovasjoner av moderne versjoner: brukergrensesnitt, språkintegrasjon, sikkerhetssystemer. Kronologi for utvikling og arkitektur av GNU/Linux-systemet.

sammendrag, lagt til 25.10.2010


DirectX-utviklingssett for Microsoft Windows, egenskaper for sett med COM-kompatible objekter i sammensetningen. Nøkkelfunksjoner i versjoner, shader-språk. Beskrivelse av hovedfunksjonene som brukes. Kildekoden til programmet, eksempler på driften.

kursarbeid, lagt til 16.02.2015


Windows som en mellommann mellom brukeren og operativsystemet, forenkler prosessen med kommunikasjon mellom dem, historien om dannelsen og utviklingen av de første versjonene. Funksjonelle funksjoner Og Windows-forskjeller 95/98/ME og Windows NT/2000/XP/Vista/7, deres arkitektoniske løsninger.

presentasjon, lagt til 23.10.2013


Redusere kostnadene for reparasjonsarbeid for å eliminere defekter, oppnådd ved å bruke et informasjonssystem for å kontrollere dem. Analyse fagområde og programvare. Beregning av besparelser på grunn av økt brukerproduktivitet.

avhandling, lagt til 19.01.2017


Konsept, essens, struktur og typer operativsystemer. Egenskaper ved operasjonssalen Windows-systemer XP, krav til installasjonen, sammenlignende analyse av versjoner, konfigurasjonsfunksjoner, versjonsoppdateringer, installasjon av enhetsdrivere og å legge til nye.

sammendrag, lagt til 20.10.2009


Utseendet til de første versjonene av Windows grafiske grensesnitt og utvidelser for DOS. Windows-familier 3.x og Windows 9.x, deres funksjoner og hovedfunksjoner. Utviklingen av Plug and Play-teknologi. De viktigste forbedringene i moderne versjoner Windows.

Jeg er overrasket over hvor mange elektronikkingeniører som ikke bruker versjonskontrollsystemer i sine design. Jeg var sånn selv helt til jeg prøvde det. Nå starter jeg hvert prosjekt ved å lage et depot.

Hva det er?

Så, versjonskontrollsystemer (VCS) er et program som lar deg lagre hele utviklingshistorien til et prosjekt.

Hvorfor er dette nødvendig?

Dette er et veldig, virkelig mega-praktisk utviklingsverktøy. Det hender at du skrev og skrev et program og til slutt brøt noe. Hvis programmet var i versjonskontroll kan du enkelt rulle tilbake til en tidligere versjon av prosjektet og se hva som endret seg, dette har reddet meg mange ganger.

For eksempel begynte jeg nylig å oppleve fartsgrenser i et FPGA-prosjekt. På bokstavelig talt 5 minutter fant jeg en versjon der de ikke hadde krasjet ennå og fant årsaken

Hvis flere personer jobber med et prosjekt, er det nesten umulig å jobbe uten et kontrollsystem – kaos begynner, alle gjør noe annerledes og det er ikke klart hvem som gjorde hva. Med en SUV kan du enkelt se hvem som gjorde hva, endringer gjort av andre blir mye mindre uventede.

I tillegg er det mer eksotiske bruksområder. For eksempel overfører jeg endringer til dette nettstedet til serveren ved hjelp av et versjonskontrollsystem.

Hvilken skal du velge?

Det finnes et stort utvalg av versjonskontrollsystemer. Personlig valgte jeg Mercurial for meg selv. Flott system, som jeg anbefaler til alle - raskt, på tvers av plattformer, med en utmerket grafisk klient. Eksistensen av nettstedet viste seg å være et veldig sterkt argument i dens favør. Jeg har aldri angret på valget mitt.

Foruten Mercurial er git og svn ganske vanlig nå. Git er mer vanlig i Linux-mengden, svn er mer vanlig i et bedriftsmiljø. Jeg prøvde å bruke dem (men ikke så lenge), men jeg så ikke noe som ville gjøre det verdt å slutte med Mercurial.

Det er en nettside hvor du kan lagre prosjektene dine. Det er bemerkelsesverdig for det faktum at du, i motsetning til github, kan lage lukkede depoter gratis (et depot er et sted hvor prosjekter lagres). Du trenger kun å betale for de prosjektene som er stengt og som mer enn 5 personer jobber med. Samtidig kan grensen utvides til 8 ved å sende ut invitasjoner. Jeg har ennå ikke overskredet denne grensen. I tillegg er det en wiki og en feilsporer, generelt alt du trenger for å utvikle prosjekter.

Da jeg begynte å jobbe med det, støttet siden kun Mercurial (delvis på grunn av dette valgte jeg Mercurial), men nå kan du lage git-repositories der. I tillegg kan du koble domenet ditt til bitbucket. Her er for eksempel min versjon: hg.bsvi.ru

Hvordan starte?

Først må du laste ned klienten. Jeg bruker skilpaddeHg. Jeg tror det ikke vil være noen problemer med installasjonen.

Etter installasjonen er det en god idé å angi et standard brukernavn. For å gjøre dette må du redigere filen C:/Users/BSVi/mercurial.ini, du må legge til linjen der

Brukernavn = bsvi

Naturligvis må bsvi erstattes med navnet ditt.

Nå er vi klare til å lage et prosjekt og begynne å gjøre noe. For å gjøre dette, klikk på "Opprett depot":

Der fyller vi inn navn, beskrivelse, velger språk. Du kan legge til en wiki og en feilsporing.

Klikk nå på "klone"-knappen og kopier det som vises der:

Videre operasjoner avhenger av hvilken filbehandler du bruker. Personlig bruker jeg langt. Jeg limer bare inn den kopierte linjen i kommandolinjen:

Hvis du bruker explorer (um), total commander eller noe sånt, må du høyreklikke og velge:


Der, i kildefeltet, må du sette inn banen, naturligvis, uten hg-klon:

Du vil bli bedt om passordet ditt, og test-repo-katalogen vil vises, hvor prosjektet faktisk vil være plassert.

La oss legge til noen filer

Hvis du allerede har utviklinger for prosjektet, kan du ganske enkelt kopiere dem til en katalog. For pedagogiske formål vil vi lage en fil main.c med følgende innhold:

#inkludere int main() ( return 0; )

La oss nå forplikte oss. En forpliktelse er å gjøre endringer i et prosjekt. For å gjøre dette, start hg workbench. Jeg skriver bare thg på kommandolinjen, for oppdagere filbehandlere du må trykke RMB->Hg Workbench.

Det vil være et spørsmålstegn ved siden av filen vår (dette betyr at den ikke er lagt til prosjektet). La oss sette en hake ved siden av og skrive en beskrivelse av hva som ble gjort:


Selvfølgelig, etter dette, klikk på "forplikte" -knappen.

Det er det, det er gjort endringer i prosjektet. Her må du være oppmerksom på at endringene bare ble gjort på den lokale datamaskinen (det vil si at de ennå ikke er på serveren). For å overføre endringer til serveren, må du klikke på "push"-knappen, her er den:

Naturligvis, for å pushe endringer til serveren, trenger du et passord.

La oss endre filen

La oss nå se på en av de svært viktige funksjonene til versjonskontrollsystemer - filversjonssporing. La oss legge til skjermutgang til programmet vårt:

#inkludere int main() ( printf("mercurial regler!"); return 0; )

La oss gå til hg arbeidsbenk. Når jeg jobber med et prosjekt, lukker jeg det ikke engang (mer om det senere), trykk på f5 for å oppdatere listen over filer. Nå kan du se hva som har endret seg siden forrige commit:

Og dette er et veldig kraftig verktøy. Vanligvis, under feilsøking, dukker det opp en haug med forskjellig søppel i filene. Så å se på hva du skal forplikte renser prosjektet veldig godt for søppel.

Hva skal man gjøre med søppel?

Når du jobber med et prosjekt, dukker det opp mye søppel - for eksempel objektfiler, filer generert av IDE, noen midlertidige filer, og så videre. Det ville vært fint å fjerne alt som ikke er relatert til selve prosjektet fra depotet. Det er en fil for this.hgignore (ja, med en prikk i begynnelsen av navnet).

La oss legge til en søppelfil til prosjektet. For eksempel opprettet jeg main.obj:

Hvis du nå oppdaterer listen over filer, vil naturligvis hg workbench tilby å legge til denne filen i prosjektet:

La oss nå lage en file.hgigonre og skrive der at vi vil ignorere alle filer med obj-utvidelsen:
syntaks:glob *.obj

Hvis du oppdaterer listen over filer, vil obj-filene forsvinne, men .hgignore-filen vil dukke opp, som kan utføres:

Hvordan kan jeg rulle tilbake endringer?

La oss gjenopprette programmet til tilstanden det hadde før det ble vist på skjermen. For å gjøre dette, velg bare forpliktelsen du vil gå tilbake til og klikk på denne knappen:

Du kan rulle tilbake en egen fil på nesten samme måte.

Konklusjon

Det er alt, dette er minimumskunnskapen om versjonskontrollsystemer som lar deg lagre historien om prosjektutvikling. Naturligvis er det mange andre muligheter, som jeg vil snakke om senere.

Mange tror at versjonskontrollsystemer bare skal brukes hvis du utvikler noe i en stor mengde, men dette er ikke sant :) Selv når du jobber med et prosjekt alene, er versjonskontrollsystemer til stor hjelp.

For eksempel, her er et skjermbilde av min UTC (som jeg utvikler selv) på det vanskeligste stedet i hg workbench:

Misha Radionov

Hva er versjonskontrollsystemer og hvorfor trenger du dem?

Tilbake til

Se for deg situasjonen: du leide en utvikler for å legge til for eksempel en rask bestillingsfunksjon i nettbutikken din. Siden siden må fungere og generere inntekter hele tiden, bestemmer utvikleren seg for å utføre arbeid på sin lokale server.

Mens det fungerer, sendte designeren ny logo, som du umiddelbart erstattet i malen på hovedversjonen av nettstedet. Samtidig reduserte du fonten i produktnavnene slik at alt får plass på skjermen til netbooken til en av kundene dine. Så oppdaterte du et par produktbilder. På dette tidspunktet bestemte utvikleren seg for å gjøre deg en tjeneste - å rense ut den ærlig talt unødvendige funksjonaliteten i sin versjon av nettstedet ditt som den forrige utvikleren skrev. Som ofte skjer, tror dere begge at dere ikke har gjort noe alvorlig. Men du tar feil.

Når utviklerens versjon er lastet opp til siden, klemmer alle utviklingsdeltakerne hodet. Arbeidsresultatene dine blir slettet, feil vises. Det er ikke klart hva problemet er. Forhåpentligvis vil du på dette tidspunktet i det minste ha en fungerende sikkerhetskopi, og i verste fall vil du bruke flere dager på å fange opp problemer manuelt. Hvordan unngå å komme i en slik situasjon? La oss snakke.

Hva er VCS?

Versjonskontrollsystem (fra engelsk Version Control System, VCS eller Revision Control System) - programvare for å gjøre det enklere å jobbe med å endre informasjon. Wikipedia

Og nå på en enkel måte

Et versjonskontrollsystem lar deg lagre flere versjoner av samme dokument, gå tilbake til tidligere versjoner om nødvendig, bestemme hvem som har gjort en bestemt endring og når, og mye mer.

Med andre ord lar VCS flere utviklere endre de samme filene samtidig og uten å lage lokale kopier på datamaskinene deres. I dette tilfellet lagres alle modifikasjonsalternativer separat, og du kan gjøre forskjellige varianter samme fil, med hensyn til ulike redigeringer fra forskjellige folk. Hvis flere endringer påvirker det samme fragmentet av dokumentet, vil systemet be deg om å velge ønsket alternativ.

Vanligvis, for å jobbe med et versjonskontrollsystem, brukes en egen datamaskin (server) eller en Internett-tjeneste, som gir muligheten til å leie en slik server.

Enkelt eksempel

Hvis flere personer jobber med ett Excel-dokument, kan bare én person redigere filen, resten har skrivebeskyttet tilgang. Ved å bruke VCS får du muligheten til å redigere en fil på en gang og av alle. Den eneste betingelsen er at etter å ha gjort endringer, må filen lagres på serveren, og ikke til lokal datamaskin. Men som nevnt ovenfor lar verktøyene deg utføre slike handlinger enkelt og enkelt.

Versjonskontrollsystem i Flag studio

I vårt arbeid bruker vi Git versjonskontrollsystem. Dette systemet er en av de vanligste VCS. Dette resulterer i mye støtte fra Git-fellesskapet. En annen fordel er at det er enkelt å mestre systemet, fordi... det er et bredt spekter programvareprodukter utviklet spesielt for dette systemet.

Vi bruker et kodeutviklingsprogram kalt IntelliJ IDEA. Det gir en IDE, det vil si en stor funksjonell base for utviklere, inkludert brukervennlig grensesnitt om å jobbe med versjonskontroll. Så, uten å forlate programmet, kan vi se hvilke endringer som ble gjort av en eller annen utvikler på nettstedet vi trenger. Eller, uten frykt for å miste endringene dine, få endringer gjort av en annen utvikler. IDEA-grensesnittet ser omtrent slik ut:

Vi bruker Bitbucket-skytjenesten til å lagre versjoner. Denne tjenesten har et praktisk grensesnitt og lar deg, i tillegg til tjenester for lagring av versjonene dine, administrere tilgangsregler til produktene dine forskjellige brukere. Fordelen med å bruke skylagring er at det ikke stilles krav til kunnskap om serveroppsett og administrasjon. Du får alt ut av esken og kan begynne å bruke det med en gang. Alt du laster opp til bitbucket er privat, dvs. uten din tillatelse kan ingen andre se det du lagrer. Bitbucket-grensesnitt:

Hva gir bruk av VCS oss?

• Full tillit til at filene vi mottar fra systemet alltid er oppdatert til enhver tid.
• Muligheten til å få den nødvendige versjonen fra hvilken som helst datamaskin som lar deg koble til serveren.
• Når du lagrer en fil i VCS, trenger du ikke tenke på at noen som jobber med den samme filen vil lagre og overskrive endringene.
• For programvareutviklere lar bruk av systemet deg også godta/avvise endringer som er gjort av en av utviklerne.

Hva gir dette til våre kunder?

La oss gå tilbake til situasjonen som ble diskutert i begynnelsen. Slik det ville vært med VCS. Utvikleren laster opp koden sin til en egen gren. Du gjennomgår endringene og bruker dem bare hvis du ser at alt er i orden. Alt er lagret på ett sted, trygt, raskt og praktisk. Og når det er flere utviklere, vil du ikke kunne klare deg uten VCS i det hele tatt.

Vennligst aktiver JavaScript for å se

Grunnleggende om VCS

Introduksjon

Før du snakker om et bestemt versjonskontrollsystem, må du forstå hva det er, hva de er og hvorfor de dukket opp i utgangspunktet. Dette foredraget er ment å gi en innledende introduksjon til versjonskontroll og versjonskontrollsystemer, og først vil jeg snakke om opprinnelsen til versjonskontrollverktøy, hvilke versjonskontrollsystemer som er populære for tiden og hva de viktigste forskjellene er mellom dem.

Om versjonskontroll

Hva er versjonskontroll og hvorfor trenger du det?

Det er nok verdt å starte med definisjonen av et versjonskontrollsystem (VCS) – dette er et system som registrerer endringer i en eller flere filer slik at det i fremtiden er mulig å gå tilbake til enkelte gamle versjoner av disse filene.

Nylig er filer sluttresultatet for mange yrker (for eksempel skriving, vitenskapelig arbeid og selvfølgelig programvareutvikling). Det brukes mye tid og krefter på å utvikle og vedlikeholde disse filene, og ingen ønsker å måtte bruke enda mer tid og krefter på å gjenopprette data som er tapt som følge av endringer.

La oss forestille oss at en programmerer utvikler et prosjekt som består av en liten fil (eksemplet er forresten ganske ekte, ikke syntetisk, og har blitt møtt i det virkelige liv). Etter å ha sluppet den første versjonen av prosjektet, står han overfor et vanskelig valg: det er nødvendig å fikse problemene som er rapportert av brukere av den første versjonen, og samtidig utvikle noe nytt for den andre. Selv om du bare trenger å fikse problemer som oppstår, er det stor sannsynlighet for at prosjektet etter en endring slutter å fungere, og du må finne ut hva som ble endret for å gjøre det lettere å lokalisere problemet. Det er også tilrådelig å føre en slags logg over endringer og korrigeringer som er gjort, for ikke å gjøre det samme arbeidet flere ganger.

I det enkleste tilfellet kan problemet ovenfor løses ved å lagre flere kopier av filene, for eksempel en for å fikse feil i den første versjonen av prosjektet og en andre for nye endringer. Siden endringene vanligvis ikke er veldig store sammenlignet med filstørrelsen, er det mulig å lagre bare de endrede linjene ved å bruke diff-verktøyet og senere slå dem sammen ved å bruke patch-verktøyet. Men hva om prosjektet består av flere tusen filer og hundre mennesker jobber med det? Hvis vi i dette tilfellet bruker metoden med lagring separate kopier filer (eller til og med bare endringer), vil prosjektet stoppe opp veldig raskt. I påfølgende forelesninger vil jeg bruke programkildekoder for eksempler, men faktisk kan nesten alle typer filer plasseres under versjonskontroll.

Hvis du er en grafisk designer eller webdesigner og ønsker å lagre alle versjoner av et bilde eller layout - og det ville du sannsynligvis gjort - så er det en veldig klok avgjørelse å bruke et versjonskontrollsystem. VCS gjør det mulig å returnere individuelle filer til som før, tilbake til tidligere tilstand hele prosjektet, se endringer som skjer over tid, finne ut hvem som var den siste som gjorde endringer i en modul som plutselig sluttet å fungere, hvem og når introduserte en slags feil i koden, og mye mer. Generelt, hvis du, mens du bruker VCS, ødelegger alt eller mister filer, kan alt enkelt gjenopprettes. I tillegg vil overheaden for alt du får være veldig liten.

Lokale versjonskontrollsystemer

Som nevnt tidligere, er ett eksempel på en lokal SUV ekstremt enkelt: mange mennesker foretrekker å kontrollere versjoner ved å kopiere filer til en annen katalog (vanligvis legge til dagens dato til katalognavnet). Denne tilnærmingen er veldig vanlig fordi den er enkel, men den mislykkes også oftere. Det er veldig lett å glemme at du er i feil katalog og ved et uhell endrer feil fil, eller kopierer filer til feil sted og overskriver filene du trenger. For å løse dette problemet har programmerere lenge utviklet lokal VCS med en enkel database som lagrer alle endringer i de nødvendige filene

En av de mest populære VCS-ene av denne typen er RCS (Revision Control System), som fortsatt er installert på mange datamaskiner. Selv på det moderne Mac OS X-operativsystemet er rcs-verktøyet installert sammen med utviklerverktøy. RCS ble utviklet på begynnelsen av 1980-tallet av Walter F. Tichy. Systemet lar deg lagre versjoner av kun én fil, så du må administrere flere filer manuelt. For hver fil under systemkontroll lagres versjonsinformasjon i spesiell fil med navnet på originalfilen som tegnene ",v" er lagt til på slutten. For eksempel, for filen file.txt, vil versjonene bli lagret i filen file.txt,v. Dette verktøyet er basert på arbeid med sett med patcher mellom par med versjoner (en patch er en fil som beskriver forskjellen mellom filene). Dette lar deg gjenskape hvilken som helst fil når som helst, og bruke patcher sekvensielt. Systemet bruker diff-verktøyet til å lagre versjoner. Selv om RCS oppfyller minimumskravene for et versjonskontrollsystem, har det følgende hovedulemper, som også fungerte som drivkraften for opprettelsen av følgende system under vurdering:

• Arbeid med kun én fil, hver fil må kontrolleres separat;
• Upraktisk mekanisme samtidig arbeid flere brukere med systemet, blir lagringen ganske enkelt blokkert til brukeren som blokkerte den låser den opp;
• Ingen frigjør deg fra sikkerhetskopier; du risikerer å miste alt.

Sentraliserte versjonskontrollsystemer

Den neste store utfordringen var behovet for å samarbeide med utviklere på andre datamaskiner. For å løse dette ble det laget sentraliserte versjonskontrollsystemer (CVCS). Slike systemer, som CVS, Subversion og Perforce, har en sentral server som lagrer alle filer under versjonskontroll, og en rekke klienter som mottar kopier av filene fra den. Dette har vært standarden for versjonskontrollsystemer i mange år.

Denne tilnærmingen har mange fordeler, spesielt i forhold til lokal SLE. For eksempel vet alle hvem som gjør hva i prosjektet. Administratorer har klar kontroll over hvem som kan gjøre hva, og selvfølgelig er CSKB mye enklere å administrere enn lokale databaser på hver klient. Imidlertid er det flere alvorlige ulemper ved denne tilnærmingen. Den mest åpenbare er at den sentraliserte serveren er det svake punktet i hele systemet. Hvis serveren går ned i en time, kan ikke utviklere samhandle på en time, og ingen kan lagre en ny versjon av arbeidet sitt. Hvis disken med den sentrale databasen er skadet og det ikke er noen sikkerhetskopi, mister du absolutt alt - hele historien til prosjektet, med mulig unntak av flere fungerende versjoner lagret på brukernes arbeidsmaskiner.

CVS

CVS (Concurrent Versions System) er fortsatt det mest brukte systemet, men mister raskt sin popularitet på grunn av mangler som jeg vil diskutere nedenfor. Dick Grune utviklet CVS på midten av 1980-tallet. For å lagre individuelle filer, bruker CVS (så vel som RCS) filer i RCS-formatet, men lar deg administrere grupper av filer som ligger i kataloger. CVS bruker også en klient-server-arkitektur der all versjonsinformasjon er lagret på serveren. Ved å bruke en klient-server-arkitektur kan CVS brukes selv av geografisk distribuerte team av brukere der hver bruker har sin egen arbeidskatalog med en kopi av prosjektet. Som navnet tilsier, kan brukere dele systemet.

Mulige konflikter ved endring av samme fil løses ved at systemet kun tillater endringer i den nyeste versjonen av filen. Derfor anbefales det alltid å oppdatere arbeidskopien av filene før du laster opp endringene i tilfelle mulige motstridende endringer. Ved oppdatering gjør systemet endringer i arbeidskopien automatisk og kun ved motstridende endringer på en av filplasseringene kreves manuell korrigering av konfliktplasseringen.

CVS lar deg også opprettholde flere utviklingslinjer på et prosjekt ved å bruke utviklingsgrener. Dermed kan du, som nevnt ovenfor, rette feil i den første versjonen av prosjektet og samtidig utvikle ny funksjonalitet.

CVS ble brukt av et stort antall prosjekter, men det var selvfølgelig ikke uten mangler, noe som senere førte til utseendet til neste system under vurdering. La oss se på de viktigste ulempene:

• Siden versjoner er lagret i RCS-filer, er det ikke mulig å lagre katalogversjoner. Standard metodeå omgå denne hindringen er å lagre en fil (for eksempel README.txt) i en katalog;
• Å flytte eller gi nytt navn til filer er ikke underlagt versjonskontroll. Standardmåten å gjøre dette på er først å kopiere filen, fjerne den gamle ved å bruke cvs remove-kommandoen og deretter legge den til med det nye navnet ved å bruke cvs add-kommandoen;

Subversion

Subversion (SVN) ble utviklet i 2000 på initiativ av CollabNet. SVN ble opprinnelig utviklet som en "bedre CVS" og hovedmålet til utviklerne var å rette opp feil som ble gjort i CVS-designet samtidig som de beholdt et lignende grensesnitt. SVN, som CVS, bruker en klient-server-arkitektur. De viktigste endringene sammenlignet med CVS inkluderer:

• Atomendringer (commit). Hvis commit-behandlingen avbrytes, vil ingen endringer bli gjort.
• Å gi nytt navn, kopiere og flytte filer bevarer hele endringshistorikken.
• Kataloger, symbolske lenker og metadata er underlagt versjonskontroll.
• Effektiv endringslagring for binære filer.

Distribuerte versjonskontrollsystemer

Og i denne situasjonen kommer distribuerte versjonskontrollsystemer (DVCS) inn i bildet. I systemer som Git, Mercurial, Bazaar eller Darcs sjekker ikke klienter bare ut de nyeste versjonene av filer, men kopierer hele depotet. Derfor, i tilfelle serveren som arbeidet gikk gjennom "dør", kan ethvert klientlager kopieres tilbake til serveren for å gjenopprette databasen. Hver gang en klient henter en ny versjon av filer, lager han selv full kopi alle data.

I tillegg lar de fleste av disse systemene deg jobbe med flere eksterne depoter, slik at du kan jobbe forskjellig med forskjellige grupper av mennesker på samme prosjekt samtidig. Dermed kan du i ett prosjekt gjennomføre flere typer arbeidsprosesser samtidig, noe som er umulig i sentraliserte systemer.

Hvorfor trengs distribuerte systemer?

Som navnet antyder, er en av hovedideene til distribuerte systemer fraværet av en tydelig utpekt sentral versjonsbutikk - et depot. Når det gjelder distribuerte systemer, kan et sett med versjoner distribueres helt eller delvis mellom ulike depoter, inkludert eksterne. Denne modellen passer perfekt inn i arbeidet til distribuerte team, for eksempel et team av utviklere distribuert over hele verden som jobber med ett åpen kildekode-prosjekt. kildekode. Utvikleren av et slikt team kan laste ned all versjonsinformasjon og deretter jobbe kun på den lokale maskinen. Så snart resultatet av en av arbeidsstadiene er oppnådd, kan endringene lastes opp til et av de sentrale depotene eller publiseres for visning på utviklerens nettsted, eller i mailingliste. Andre prosjektdeltakere vil på sin side kunne oppdatere sin kopi av versjonsdepotet med nye endringer, eller prøve de publiserte endringene på en egen testutviklingsgren. Dessverre, uten god prosjektorganisering, kan mangelen på ett sentralt depot være en ulempe for distribuerte systemer. Hvis det i tilfelle av sentraliserte systemer alltid er ett felles depot hvor du kan hente den nyeste versjonen av prosjektet, må du i tilfelle av distribuerte systemer organisatorisk bestemme hvilken av prosjektgrenene som skal være den viktigste. Hvorfor distribuert system versjonskontroll kan være av interesse for noen som allerede bruker et sentralisert system - for eksempel Subversion? Alt arbeid innebærer å ta beslutninger, og i de fleste tilfeller må du prøve forskjellige alternativer: Når du jobber med versjonskontrollsystemer, brukes utviklingsgrener for å vurdere ulike alternativer og arbeide med store endringer. Selv om dette er et ganske naturlig konsept, er det ikke lett å bruke i Subversion. Dessuten blir alt mer komplisert i tilfelle av flere sekvensielle sammenslåinger fra en gren til en annen - i dette tilfellet må du angi de første og endelige versjonene av hver endring nøyaktig for å unngå konflikter og feil. For distribuerte versjonskontrollsystemer er utviklingsgrener et av de grunnleggende konseptene - i de fleste tilfeller er hver kopi av en versjonsbutikk en utviklingsgren. Dermed er mekanismen for å slå sammen endringer fra en gren til en annen når det gjelder distribuerte systemer, en av de viktigste, som lar brukerne anstrenge seg mindre når de bruker systemet.

Kort beskrivelse av populære distribuerte SUV-er

• Git er et distribuert versjonskontrollsystem utviklet av Linus Torvalds. Git var opprinnelig ment for bruk i utviklingsprosessen Linux-kjerner, men begynte senere å bli brukt i mange andre prosjekter - som for eksempel X.org og Ruby on Rails, Drupal. Git er for øyeblikket det raskeste distribuerte systemet som bruker den minste revisjonsbutikken. Men samtidig, for brukere som migrerer, for eksempel fra Subversion, kan Git-grensesnittet virke komplisert;
• Mercurial er et distribuert system skrevet i Python språk med flere utvidelser i C. Prosjekter som bruker Mercurial inkluderer Mozilla og MoinMoin.
• Bazaar er et system utviklet av Canonical, kjent for sin Ubuntu-distribusjon og nettstedet https://launchpad.net/. Systemet er hovedsakelig skrevet i Python og brukes av prosjekter som MySQL.
• Codeville er et distribuert system skrevet i Python som bruker en innovativ algoritme for å kombinere endringer (flette). Systemet brukes for eksempel i utviklingen av den originale BitTorrent-klienten.
• Darcs er et distribuert versjonskontrollsystem skrevet i Haskell, brukt for eksempel av Buildbot-prosjektet.
• Monotone er et system skrevet i C++ og bruker SQLite som revisjonslagring.

Spørsmålet ville vært passende for 25 år siden. I omtrent 10 år nå har bruk av et versjonskontrollsystem vært et must for alle lag. Felles, praktisk, sikker lagring av kildekoder med endringshistorikk, kollektivt eierskap av koden, oppgavefordeling og applikasjonsfunksjonalitet i teamet. Samt automatisering av bygg, distribusjoner og kontinuerlig integrasjon generelt.

Ivan Nemytchenko, GitLab
Gjør livet ditt enklere når du utvikler programvareprodukter sammen.

Alexander Makarchuk, qb
Optimalisering av teamutvikling.

Petr Urvaev, SimbirSoft
Under utviklingen endres prosjektkoden aktivt. Samtidig er det nødvendig å føre oversikt over hva som allerede er gjort og koordinere handlingene til individuelle deltakere for å samtidig endre koden slik at forbedringer fra prosjektdeltakere tar hensyn til alle tidligere gjort endringer av andre deltakere. Et versjonskontrollsystem lar deg automatisere denne prosessen.

2. Hvilke faktorer påvirker valg av versjonskontrollsystem?

Nikolay Fetyukhin,MST
Støtte kjernen til versjonskontrollsystemet og dets spesifikke implementering, gjøre teamet kjent med det. Oftest brukes ett system for alle prosjekter. Unntak kan for eksempel være kundekrav.

Ivan Nemytchenko, GitLab
Populariteten til et bestemt system, hvorfra alt annet følger: støtte i applikasjoner og tjenester, mengde og kvalitet på dokumentasjon, tilgjengelighet av en ekspert "i nærheten", etc.

Alexander Makarchuk, qb
I vårt tilfelle er valget basert på populariteten til versjonskontrollsystemet og ferdighetsnivået til utviklerne med det.

Petr Urvaev, SimbirSoft
For det første tilsvarer egenskapene til versjonskontrollsystemet utviklingsprosessen som ble vedtatt av teamet. For det andre, hvilket versjonskontrollsystem er mer vanlig for prosjektdeltakere å jobbe med?

3. Hvordan implementere bruk av versjonskontroll i et team?

Nikolay Fetyukhin,MST
I dag uteksamineres selv moderne studenter med en generell forståelse av hvorfor versjonskontrollsystemer er nødvendig, så spørsmålet om implementering er ikke helt korrekt. Vanligvis starter alle prosjekter med å lage et depot som standard. Hvis du er i det generelle tilfellet, bør du snakke med teamet, finne ut hvorfor det ikke er noe versjonskontrollsystem på prosjektet (noen ganger er det forskjellige veldig spesifikke tilfeller), og hvis problemene kan overvinnes, hold et par seminarer i teamet på et spesifikt versjonskontrollsystem (hvis nødvendig) og kjør.

Ivan Nemytchenko, GitLab
Gi dem muligheten til å jobbe uten et versjonskontrollsystem slik at de kjenner all smerten. Deretter "slipp" dem et Git-jukseark, og de vil lære og implementere alt selv. Men slik kan man jobbe med skoleelever og elever. Voksne utviklere har vanligvis ikke dette spørsmålet.

Alexander Makarchuk, qb
Sakte men sikkert kommer alle til dette på egenhånd.

Petr Urvaev, SimbirSoft
I flertall moderne prosjekter behovet for å bruke et versjonskontrollsystem reiser ingen spørsmål. Når du lærer å jobbe med det, er det nok å konfigurere det til komfortabelt arbeid og les et kort foredrag om hovedfunksjonene til versjonskontrollsystemet som brukes, og gir eksempler på bruk.

4. Hva gjorde Git til standarden i verden av versjonskontrollsystemer? Vil noen kunne fortrenge ham fra hans ledende posisjon?

Nikolay Fetyukhin,MST
Git introduserte opprinnelig noen nyttige ting, for eksempel lokale forpliktelser, og løste også mange grensammenslåingsproblemer som plaget den tidligere trendsetteren, Subversion (SVN). Helt fra begynnelsen kjempet den for popularitet med Mercurial (Hg), som er enklere i noen aspekter, men tok til slutt ledelsen.

Ivan Nemytchenko, GitLab
Takket være det faktum at Linus Torvalds angrep problemet med distribuert utvikling fra høyre side, med tanke på manglene til forgjengersystemer. Bevege seg? Til hva?

Alexander Makarchuk, qb
Takket være det faktum at Git er flott. Ingen vil fortrenge ham på veldig lenge.

Petr Urvaev, SimbirSoft
Hovedfordelen med Git er utviklingen av verktøy for å jobbe med det og evnen til å lagre resultatene av arbeidet med flere parallelle åpne oppgaver i den, slik at mellomresultatene ikke påvirker hverandre, og samtidig kan de endelige resultatene ganske enkelt kombineres til en endelig versjon av applikasjonen. En viktig rolle i den universelle populariteten til Git i CVS-verdenen ble også spilt av GitHub-ressursen, som er vert for tusenvis av depoter på forskjellige språk.

5. Hva liker ikke utviklere med Git? Hvorfor velger noen andre mindre populære løsninger?

Nikolay Fetyukhin,MST
Den eneste betydelige ulempen med Git for oss er noen problemer med å spore endringer: grener kan slettes, og bare en sammenslåingsforpliktelse kan gjenstå. Dette skyldes i stor grad at Git har filialer knyttet til commits. Git har også en brattere læringskurve enn den nevnte Mercurial eller Subversion.

Alexander Makarchuk, qb
Innenfor rammen av våre oppgaver er alle fornøyde.

Petr Urvaev, SimbirSoft
Git er ganske praktisk, men krever læring (for de som ikke allerede vet det) og aktive trinn for å bytte til det, så noen lag foretrekker å bli med versjonskontrollsystemene de bruker. Valget av versjonskontrollsystem kan også bestemmes av utviklingsverktøyene som brukes.

6. Hvor vanlig er det å bruke versjonskontrollsystemer for å administrere andre filer enn bare kode?

Nikolay Fetyukhin,MST
Foreløpig overalt. De samme skysystemene som One Drive, Yandex.Disk, Dropbox og Google Drive er basert på en ideologi som replikerer versjonskontrollsystemer.

I praksis er bruken av konvensjonelle versjonskontrollsystemer for lagring av dokumenter vanlig, men ikke for vanlig; finesser oppstår ved beregning av endringer, siden de fleste av dagens vanlige dokumentformater er binære, og endringssettene deres ikke er lesbare for mennesker.

Alexander Makarchuk, qb
Stadig brukt.

Petr Urvaev, SimbirSoft
Versjonskontrollsystemer er først og fremst rettet mot å jobbe med et stort antall små filer, som hovedsakelig brukes i utvikling. Bruk lignende systemer for filer av ikke-tekstformater (binære), som regel er det ineffektivt, og i noen tilfeller er det helt umulig. Derfor, for å lagre andre filer, brukes vanligvis spesialiserte systemer, tilpasset til å fungere med visse dataformater.