Send dit gode arbejde i videnbasen er enkel. Brug formularen nedenfor

Studerende, kandidatstuderende, unge forskere, der bruger videnbasen i deres studier og arbejde, vil være dig meget taknemmelig.

opslået på http://www.allbest.ru/

Ministeriet for Uddannelse og Videnskab i Den Russiske Føderation

Forbundsstatsbudget uddannelse

Institut for videregående faglig uddannelse

"TOMSK STATE UNIVERSITY

STYRESYSTEMER OG RADIOELEKTRONIK" (TUSUR)

Afdeling radiosystemer(RTS)

Kursusarbejde

i kurset "Informationsteknologier"

VERSIONS STYRINGSSYSTEMER

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

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

Leder Nozdrevatykh B.F.

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

VERSIONS STYRINGSSYSTEM, GIT, SVN, MERCURIAL.

Dette kursusarbejde undersøger de mest populære versionskontrolsystemer.

Formålet med arbejdet er at sætte sig ind i versionskontrolsystemer, forstå deres drift, installation og konfiguration.

Under arbejdet blev tre typer versionskontrolsystemer installeret, konfigureret og testet.

Som et resultat heraf er der blevet kompileret tre fuldt brugsklare versionskontrolsystemer, tabeller, der sammenligner disse systemers funktioner, og en ordbog med termer, der bruges, når man arbejder med programmer, er tilvejebragt.

Kursusarbejde udføres i tekst Microsoft editor Word 2010 og er tilgængelig i trykte og elektroniske formater.

kontrolversion systemgrænseflade

Introduktion

3.1 Kom godt i gang med projektet

3.2 Daglig arbejdscyklus

3.3 Filialer

3.4 Sammenlægning af versioner

3.5 Konflikter og deres løsning

3.6 Låse

3.7 Projektversioner, tags

4.1 Lokale versionskontrolsystemer

4.2 Centraliseret model

5.1.1 Systemkrav

5.1.2 Koncept

5.1.3 Kom godt i gang

5.2.1 Systemkrav

5.2.2 Installation

5.2.3 Grundkoncept

5.2.4 Oprettelse af et lager

5.2.5 Import af et projekt

5.2.7 Foretage ændringer

5.2.8 Tilføjelse af nye filer

5.2.9 Annuller ændringer

5.3.1 Systemkrav

5.3.2 Koncept

5.3.3 Kom godt i gang

Konklusion

Bilag A

Bilag B

Bilag B

Introduktion

I dag i en verden, hvor der er stor mængde komplekse systemer, er der behov for modifikation elektroniske dokumenter på forskellige stadier af deres udvikling. Under dets eksistens kan et elektronisk dokument være genstand for en lang række ændringer. Det sker dog ofte, at for videre arbejde Ikke kun den seneste version af dokumentet er nødvendig, men også forskellige tidligere versioner.

Du kan selvfølgelig opbevare flere forskellige muligheder påkrævet dokument, men denne metode er ineffektiv. Vi skal bruge meget tid og kræfter, der kræves særlig opmærksomhed, og der er stor sandsynlighed for fejl. Derudover skal vi opbevare et stort antal næsten identiske dokumenter.

Som et resultat er der udviklet softwareværktøjer, der forenkler denne mekanisme. Disse værktøjer kaldes versionskontrolsystemer. Der er flere systemer af denne art, som hver især er relevante under visse betingelser for deres brug.

Hovedideen med versionskontrolsystemer er at huske alle ændringer, der er foretaget, såvel som kommentarer fra de brugere, der har lavet dem. Herefter bliver det klart, hvem, hvornår og hvad ændrede sig, hvorfor og hvorfor. Og vigtigst af alt, alle disse ændringer kan derefter rulles tilbage på et hvilket som helst tidspunkt.

I overensstemmelse med målet er det nødvendigt at løse følgende opgaver:

Definer konceptet for et versionskontrolsystem;

Forstå, hvordan sådanne systemer fungerer;

Gennemgå installations- og lanceringsregler;

Analysere eksisterende versionskontrolsystemer;

Overvej hovedtyperne af denne type system.

Målene for arbejdet forudbestemte dets struktur. Kursusarbejdet består af fem kapitler, introduktion, konklusion, litteraturliste og bilag.

1. Konceptet med et versionskontrolsystem

Version Control System (VCS) er software til at lette arbejdet med skiftende information. Et versionskontrolsystem giver dig mulighed for at gemme flere versioner af det samme dokument, vende tilbage til tidligere versioner, hvis det er nødvendigt, og bestemme, hvem der har foretaget en bestemt ændring og hvornår.

2. Brug af et versionskontrolsystem

Disse typer systemer bruges mest i udviklingen software, så du kan gemme kildekoderne til de programmer, der udvikles. VCS giver udviklere mulighed for at gemme tidligere versioner af filer fra udvikling og hente dem derfra. Det gemmer versionsoplysninger for hver fil (og hele projektstrukturen) i en samling, der normalt kaldes et lager. Men ikke desto mindre kan disse systemer bruges på andre vidensområder, som omfatter et stort antal hyppigt skiftende elektroniske dokumenter. For eksempel bruges de i stigende grad i CAD, normalt som en del af produktdatastyringssystemer (PDM). Versionering bruges i konfigurationsstyringsværktøjer.

Brugen af ​​VCS er bestemt obligatorisk for udvikleren, hvis projektet er mere end et par hundrede linjer, eller hvis flere udviklere arbejder sammen om projektet.

Versionskontrolsystemer løser følgende problemer:

Lagring af filversioner;

Evnen til at hente tidligere versioner af lagrede filer;

Se ændringer foretaget mellem de versioner, der er angivet i anmodningen;

3. Typisk procedure for at arbejde med systemet

Hver VCS har sine egne specifikke funktioner i sættet af kommandoer, hvordan brugere arbejder og administration. Imidlertid er den generelle betjeningsprocedure for de fleste VCS'er fuldstændig stereotyp. Her antages det, at projektet, hvad end det måtte være, allerede eksisterer, og dets repository er placeret på den server, som udvikleren får adgang til.

3.1 Kom godt i gang med projektet

Det første skridt, en udvikler skal tage, er at hente en arbejdskopi af projektet eller den del af det, der skal arbejdes på. Denne handling udføres ved hjælp af en standardversion checkout-kommando (checkout eller clone) eller en speciel kommando, der faktisk udfører den samme handling. Udvikleren angiver den version, der skal kopieres; som standard kopieres den seneste version (eller den, der er valgt af administratoren som den primære) normalt.

Udtrækningskommandoen etablerer en forbindelse til serveren, og projektet i form af et træ af mapper og filer kopieres til udviklerens computer. En almindelig praksis er at duplikere en arbejdskopi: ud over hovedbiblioteket med projektet på lokal disk Desuden optages endnu en kopi af den. Når du arbejder på et projekt, ændrer udvikleren kun filerne i hovedarbejdskopien. En anden lokal kopi gemmes som en reference, så du til enhver tid, uden at kontakte serveren, kan bestemme, hvilke ændringer der er foretaget i specifik fil eller projektet som helhed og fra hvilken version arbejdskopien er lavet; som regel ethvert forsøg manuel ændring denne kopi fører til fejl i driften af ​​VCS-softwaren.

3.2 Daglig arbejdscyklus

Med nogle variationer bestemt af funktionerne i systemet og detaljerne i den vedtagne forretningsproces, ser den sædvanlige cyklus af en udviklers arbejde i løbet af en arbejdsdag således ud:

1) Opdatering af arbejdskopien. Efterhånden som der foretages ændringer i hovedversionen af ​​projektet, bliver arbejdskopien på udviklerens computer gammel: dens uoverensstemmelse med hovedversionen af ​​projektet øges. Dette øger risikoen for modstridende ændringer. Derfor er det praktisk at støtte arbejdskopi i en tilstand så tæt som muligt på den aktuelle hovedversion, for hvilken udvikleren udfører en opdateringsoperation på arbejdskopien så ofte som muligt.

2) Ændring af projektet. Udvikleren ændrer projektet ved at ændre de inkluderede filer i arbejdskopien i overensstemmelse med designspecifikationen. Dette arbejde udføres lokalt og kræver ikke opkald til VCS-serveren.

3) Rettelse af ændringer. Efter at have afsluttet den næste fase af arbejdet med en opgave, forpligter udvikleren sine ændringer og overfører dem til serveren, enten til hovedgrenen, hvis arbejdet med opgaven er fuldstændig afsluttet, eller til en separat udviklingsgren for denne opgave. VCS kan kræve, at udvikleren opdaterer arbejdskopien, før den forpligter sig. Hvis systemet understøtter reolændringer, kan ændringer overføres til serveren uden at forpligte sig. Hvis den godkendte arbejdspolitik i hårdvalutasystemet tillader dette, kan ændringer ikke registreres dagligt, men kun efter afslutning af arbejdet med opgaven; i dette tilfælde gemmes alle ændringer forbundet med jobbet kun i udviklerens lokale arbejdskopi, indtil jobbet er fuldført.

3.3 Filialer

Du kan lave mindre rettelser i projektet ved direkte at redigere arbejdskopien og derefter committe ændringerne direkte til hovedgrenen (trunken) på serveren. Men når der udføres en betydelig mængde arbejde, bliver denne ordre ubelejlig: manglen på registrering af mellemliggende ændringer på serveren tillader ikke arbejde på noget i en gruppetilstand; desuden øges risikoen for at miste ændringer under lokale ulykker, og evnen til at analysere og vende tilbage til tidligere er mistet kodevarianter inden for dette arbejde. Derfor, for sådanne ændringer, er den sædvanlige praksis at oprette filialer, oprette en version af en ny version af projektet eller en del af det, hvis udvikling udføres parallelt med ændringer i hovedversionen. Når det arbejde, som filialen blev oprettet til, er afsluttet, genintegreres filialen i hovedgrenen. Dette kan gøres med flettekommandoen eller ved at oprette en patch, der indeholder ændringer foretaget under udviklingen af ​​grenen og anvende denne patch til den aktuelle hovedversion af projektet.

3.4 Sammenlægning af versioner

Tre typer operationer udført i versionskontrol kan resultere i behovet for at flette ændringer:

Opdatering af arbejdskopien;

Registrering af ændringer;

Sammenlægning af grene.

Hvert system har en automatisk flettemekanisme, der fungerer baseret på følgende principper:

Ændringer kan bestå i at ændre indholdet af en fil, oprette en ny fil eller mappe, slette eller omdøbe en allerede eksisterende fil eller mappe i projektet;

Hvis to ændringer refererer til forskellige og ikke-relaterede filer og/eller mapper, kan de altid flettes automatisk. Deres sammenlægning er, at de ændringer, der er foretaget i hver version af projektet, kopieres til den flettede version;

Oprettelse, sletning og omdøbning af filer i projektmapper kan flettes automatisk, så længe de ikke er i konflikt med hinanden. I dette tilfælde kopieres ændringer foretaget i hver version af projektet til den flettede version.

De modstridende er normalt:

Sletning og ændring af den samme fil eller mappe;

Sletning og omdøbning af den samme fil eller mappe;

Skabelsen i forskellige versioner fil med samme navn og forskelligt indhold;

Ændringer inden for en tekstfil lavet i forskellige udgaver kan kombineres, hvis de er i forskellige steder denne fil og krydser ikke. I dette tilfælde er alle ændringer inkluderet i den flettede version;

Ændringer i den samme fil, medmindre det er en tekstfil, er altid modstridende og kan ikke flettes automatisk.

I alle tilfælde er den basisversion, der skal flettes, den version, hvori de flettede versioner blev opdelt. Hvis dette er en commit-operation, så vil basisversionen være versionen af ​​den sidste opdatering før commit; hvis en opdatering, så versionen af ​​den forrige opdatering; hvis du fusionerer brancher, så den version, hvor den tilsvarende gren blev oprettet. Følgelig vil de ændringssæt, der sammenlignes, være de sæt af ændringer, der er foretaget fra basis til nuværende version i alle kombinerede varianter.

Absolut flertal moderne systemer Versionskontrol er primært rettet mod softwareudviklingsprojekter, hvor hovedtypen af ​​filindhold er tekst. Følgelig er mekanismerne til automatisk fletning af ændringer fokuseret på behandling af tekstfiler.

Når det afgøres, om det er tilladt at flette ændringer inden for den samme tekstfil, fungerer en standard-linje-for-linje-tekstsammenligningsmekanisme (et eksempel på dens implementering er GNU diff-systemværktøjet), som sammenligner de flettede versioner med basisversionen og bygger en liste over ændringer, det vil sige tilføjede, slettede og erstattede sæt af linjer . Fundne sæt af modificerede strenge, der ikke krydser hinanden, anses for at være kompatible, og deres fletning sker automatisk. Hvis de flettede filer indeholder ændringer, der påvirker den samme fillinje, fører dette til en konflikt. Sådanne filer kan kun flettes manuelt. Alle andre filer end tekstfiler er binære fra VCS-synspunktet og tillader ikke automatisk fletning.

3.5 Konflikter og deres løsning

En situation, hvor ændringerne i dem overlapper hinanden ved sammenlægning af flere versioner, kaldes en konflikt. Hvis der er en konflikt mellem ændringer, kan versionskontrolsystemet ikke automatisk oprette et fusioneret projekt og er tvunget til at kontakte udvikleren. Som nævnt ovenfor kan der opstå konflikter i stadierne af begå ændringer, opdatering eller sammenlægning af filialer. I alle tilfælde, når en konflikt opdages, stoppes den tilsvarende handling, indtil den er løst.

For at løse en konflikt tilbyder systemet generelt udvikleren tre muligheder for modstridende filer: base, lokal og server. Modstridende ændringer vises enten til udvikleren i et specielt softwaremodul til fletning af ændringer, eller er blot markeret med speciel markup direkte i teksten i den flettede fil.

Konflikter i filsystemet løses nemmere: kun sletning af en fil kan være i konflikt med en af ​​de andre operationer, og rækkefølgen af ​​filerne i mappen er ligegyldig, så udvikleren kan kun vælge, hvilken handling der skal gemmes i sammenlagt version.

3.6 Låse

Låsemekanismen tillader en af ​​udviklerne kun at tage eget brug en fil eller gruppe af filer at foretage ændringer i. Mens filen er låst, forbliver den skrivebeskyttet for alle andre udviklere, og ethvert forsøg på at foretage ændringer i den afvises af serveren. Teknisk set kan blokering organiseres på forskellige måder. Følgende mekanisme er typisk for moderne systemer:

Filer, der kræver låsning for at arbejde med, er markeret med et særligt flag "låst";

Hvis en fil er markeret som låst, så får den, når en arbejdskopi hentes fra serveren, en skrivebeskyttet attribut på det lokale filsystem, som forhindrer den i at blive redigeret ved et uheld;

En udvikler, der ønsker at ændre en låst fil, kalder særligt hold lås (lås), der angiver navnet på denne fil. Resultatet af denne kommando er følgende:

1. serveren kontrollerer, om filen allerede er blokeret af en anden udvikler; hvis det er tilfældet, mislykkes blokeringskommandoen.

2. filen på serveren er markeret som "blokeret", med ID'et på den udvikler, der blokerede den, og blokeringstiden gemmes;

3. Hvis blokeringen på serveren lykkes, fjernes "read-only"-attributten fra arbejdskopifilen på det lokale filsystem, hvilket giver dig mulighed for at begynde at redigere den.

Hvis det under driften viser sig, at filen ikke skal ændres, kan han kalde oplåsningskommandoen , udløserlås). Alle ændringer af filen fortrydes, den lokale fil vil vende tilbage til en skrivebeskyttet tilstand, den "låste" attribut vil blive fjernet fra filen på serveren, og andre udviklere vil være i stand til at ændre denne fil;

Når arbejdet med den låste fil er afsluttet, forpligter udvikleren ændringerne. Normalt fjernes blokeringen automatisk.

3.7 Projektversioner, tags

Versionskontrolsystemet sikrer lagring af alle eksisterende versioner af filer og som følge heraf alle versioner af projektet som helhed, der er opstået siden begyndelsen af ​​dets udvikling. Men selve begrebet "version" i forskellige systemer kan fortolkes på to forskellige måder.

Nogle systemer understøtter filversionering. Det betyder, at enhver fil, der vises i projektet, modtager eget nummer versioner. Når en udvikler forpligter ændringer til en fil, anvendes den tilsvarende del af de forpligtede ændringer til filen, og filen modtager et nyt, normalt sekventielt, versionsnummer.

For andre systemer refererer begrebet "version" ikke til en individuel fil, men til hele depotet. Et nyoprettet tomt lager har en version på 1 eller 0, enhver commit-ændring fører til en stigning i dette antal. Der er faktisk ikke noget versionsnummer for en individuel fil her.

Begge muligheder er dog ikke særlig bekvemme. For mere bekvemt at markere projektversioner understøtter versionskontrolsystemer konceptet med tags.

Et tag er en symbolsk etiket, der kan knyttes til en specifik version af en fil og/eller et bibliotek i et lager. Ved at bruge den passende kommando kan alle eller dele af projektfilerne, der opfylder visse betingelser, tildeles en given etiket. På denne måde kan du identificere versionen af ​​projektet ved at rette dens tilstand på et ønsket tidspunkt. Som regel er tagging-systemet ret fleksibelt og giver dig mulighed for at tagge flere versioner af filer og mapper med ét tag. Dette giver dig mulighed for at bygge en "projektversion" på enhver vilkårlig måde.

4.1 Lokale versionskontrolsystemer

Den mest foretrukne VCS til overvågning af boligudvikling vil være den lokale type. For at løse dette problem blev der udviklet specielle VCS'er med en simpel database, hvori alle lokale filer er gemt.

Figur 4.1 Skema over lokal SCR

En af de mest populære VCS'er af denne type er RCS, som stadig er installeret på mange computere.

4.2 Centraliseret model

Traditionelle versionskontrolsystemer bruger en centraliseret model, hvor der er et enkelt dokumentlager, der administreres speciel server, som udfører de fleste versionskontrolfunktioner. En bruger, der arbejder med dokumenter, skal først hente den version af dokumentet, han har brug for, fra depotet; Normalt oprettes en lokal kopi af dokumentet, den såkaldte "arbejdskopi". Den seneste version eller en af ​​de tidligere kan fås, som kan vælges efter versionsnummer eller oprettelsesdato, nogle gange efter andre kriterier. Efter at de nødvendige ændringer er foretaget i dokumentet, placeres den nye version i depotet. I modsætning til blot at gemme en fil, slettes den tidligere version ikke, men forbliver også i lageret og kan hentes derfra til enhver tid.

Sådanne systemer, såsom CVS, Subversion og Perforce, har en central server, der gemmer alle filer under versionskontrol, og en række klienter, der modtager kopier af filerne fra den. Dette har været standarden for versionskontrolsystemer i mange år.

Figur 4.2 Centraliseret versionskontrolskema

Denne tilgang har mange fordele, især i forhold til lokal SLE. For eksempel ved alle, hvem der laver hvad i projektet. Administratorer har klar kontrol over, hvem der kan gøre hvad, og selvfølgelig er CSKB meget nemmere at administrere end lokale databaser på hver klient.

Der er dog flere alvorlige ulemper ved denne tilgang. Det mest åbenlyse er, at den centraliserede server er det svage punkt i hele systemet. Hvis serveren går ned i en time, kan udviklere ikke interagere i en time, og ingen kan gemme en ny version af deres arbejde. Hvis disken med den centrale database er beskadiget, og der ikke er en sikkerhedskopi, mister du absolut alt - hele projektets historie, med undtagelse af nogle få fungerende versioner gemt på brugernes arbejdsmaskiner. Lokale VCS'er er underlagt det samme problem: Hvis hele projekthistorikken er gemt ét sted, risikerer du at miste alt.

4.3 Distribuerede versionskontrolsystemer

Sådanne systemer bruger en distribueret model i stedet for den traditionelle klient-server-model. Generelt har de ikke brug for en central lagring: hele historikken for dokumentændringer gemmes på hver computer, i lokal lagring, og om nødvendigt synkroniseres individuelle fragmenter af den lokale lagringshistorik med en lignende lagring på en anden computer. Derfor, i tilfælde af at serveren, som arbejdet gik ned igennem, går ned, kan ethvert klientlager kopieres tilbage til serveren for at gendanne databasen. I nogle af disse systemer er lokal lagring placeret direkte i arbejdskopibibliotekerne.

Figur 4.3 Distribueret VCS-model

Når en bruger af et sådant system udfører normale handlinger, såsom at hente en specifik version af et dokument, oprette en ny version og lignende, arbejder han med sin lokale kopi af depotet. Efterhånden som der foretages ændringer, begynder depoter, der tilhører forskellige udviklere, at adskille sig, og der er behov for at synkronisere dem. En sådan synkronisering kan opnås ved at udveksle patches eller såkaldte sæt mellem brugere.

Den beskrevne model er logisk tæt på at skabe en separat gren for hver udvikler i et klassisk versionskontrolsystem. Forskellen er, at indtil synkronisering kan andre udviklere ikke se denne gren. Så længe en udvikler kun ændrer sin egen gren, påvirker hans arbejde ikke andre projektmedlemmer og omvendt. Efter afslutningen af ​​den separate del af arbejdet sammenlægges ændringerne i grenene med hovedgrenen (fælles). Både ved sammenlægning af grene og ved synkronisering af forskellige repositories er versionskonflikter mulige. I dette tilfælde giver alle systemer visse metoder til at opdage og løse flettekonflikter.

Fra brugerens synspunkt er et distribueret system kendetegnet ved behovet for at oprette et lokalt lager og tilstedeværelsen af kommandosprog to ekstra kommandoer: kommandoen til at modtage et lager fra en fjerncomputer og overføre dit lager til fjerncomputeren. Den første kommando fletter ændringer fra de eksterne og lokale arkiver og placerer resultatet i det lokale arkiv; den anden, tværtimod, slår ændringer fra to depoter sammen og placerer resultatet i et fjernlager. Typisk giver flettekommandoer i distribuerede systemer dig mulighed for at vælge, hvilke sæt ændringer der skal skubbes til eller trækkes fra et andet lager, rette flettekonflikter direkte under operationen eller efter dens fejl, og gentage eller genoptage en ufærdig fletning. Det lykkes typisk kun at overføre dine ændringer til en andens lager, hvis der ikke er nogen konflikter. Hvis der opstår konflikter, skal brugeren først flette versionerne i sit lager, og først derefter overføre dem til andre.

Det anbefales normalt at organisere arbejdet med systemet, så brugere altid eller overvejende udfører fletninger i deres repositories. Det vil sige, at i modsætning til centraliserede systemer, hvor brugere sender deres ændringer til den centrale server, når de finder det passende, er det i distribuerede systemer mere naturligt at lade sammenlægningen af ​​versioner initiere af den, der skal modtage resultatet (f.eks. en udvikler). administrere en build-server).

De vigtigste fordele ved distribuerede systemer er deres fleksibilitet og betydeligt større (sammenlignet med centraliserede systemer) autonomi på en individuel arbejdsplads. Hver udviklers computer er faktisk en uafhængig og fuldt funktionel server; fra sådanne computere kan du bygge et system af enhver struktur og kompleksitetsniveau ved at indstille den ønskede synkroniseringsrækkefølge.

Ulemperne ved distribuerede systemer omfatter en stigning i det nødvendige volumen diskhukommelse: hver computer skal gemme en komplet versionshistorik, mens der i et centraliseret system normalt kun er en arbejdskopi gemt på udviklerens computer, det vil sige et udsnit af lageret på et tidspunkt og de ændringer, der er foretaget. En mindre indlysende, men ubehagelig ulempe er, at det er næsten umuligt at implementere noget af den funktionalitet, som centraliserede systemer leverer i et distribueret system. Det her:

- Blokering af en fil eller gruppe af filer (for at gemme blokeringsattributten kræves en central server, der er offentligt tilgængelig og konstant online). Dette tvinger særlige administrative foranstaltninger til at blive taget, hvis man skal arbejde med binære filer, der ikke er egnede til automatisk fletning;

- Overvågning af en specifik fil eller gruppe af filer;

- En enkelt kontinuerlig nummerering af systemversioner og/eller filer, hvor versionsnummeret stiger monotont. I distribuerede systemer må man nøjes med lokale versionsbetegnelser og brugstags, hvis formål er bestemt af en aftale mellem udviklere eller virksomhedens virksomhedsstandarder;

- Lokale brugere arbejder med en separat prøve med lille volumen fra en lagerfacilitet af betydelig størrelse og intern kompleksitet på en ekstern server.

Følgende typiske situationer kan identificeres, hvor brugen af ​​et distribueret system giver mærkbare fordele:

- Periodisk synkronisering af flere computere under kontrol af én udvikler. Brug af et distribueret system eliminerer behovet for at allokere en af ​​computerne som en server;

- Samarbejde om et projekt af en lille, geografisk fordelt gruppe af udviklere uden tildeling af delte ressourcer. Som i det foregående tilfælde implementeres et arbejdsskema uden en hovedserver, og arkivernes relevans vedligeholdes af periodiske synkroniseringer i henhold til "alle med alle"-skemaet;

Et stort distribueret projekt, hvor deltagerne kan arbejde på hver deres side i lang tid, men ikke har en konstant forbindelse til netværket. Et sådant projekt kan bruge en centraliseret server, hvormed kopier af alle dets deltagere synkroniseres. Det er muligt at arbejde uden "gruppe"-servere, så synkroniserer udviklere af en gruppe ændringer indbyrdes, hvorefter enhver af dem overfører ændringerne til den centrale server.

5. Eksempler på versionskontrolsystemer

5.1 GIT

5.1.1 Systemkrav

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

For at installere Git på Windows skal du blot downloade installationsprogrammets exe-fil fra projektsiden på GitHub og køre den. Efter installationen har du både en konsolversion (inklusive en SSH-klient) og en standard grafisk.

5.1.2 Koncept

Git er et distribueret versionskontrolsystem. I den kan filer være i en af ​​tre tilstande: engageret, ændret og forberedt. "Committed" betyder, at filen allerede er gemt i din lokale database. Ændrede filer inkluderer filer, der er ændret, men som endnu ikke er blevet committet. Iscenesatte filer er ændrede filer, der er markeret til medtagelse i den næste commit.

Projekter, der bruger Git, har således tre dele: Git-mappen, arbejdsmappen og iscenesættelsesområdet.

Git-mappen er hvor Git gemmer dit projekts metadata og objektdatabase. Det er den vigtigste del af Git, og det er det, der kopieres, når du kloner et lager fra en anden computer.

Arbejdsbiblioteket er en kopi af en specifik version af projektet udtrukket fra databasen. Disse filer hentes fra en komprimeret database i Git-mappen og placeres på disken, så du kan se og redigere dem.

Staging-området er en almindelig fil, normalt gemt i Git-mappen, som indeholder information om, hvad der skal ind i den næste commit. Det kaldes nogle gange indekset, men for nylig er det blevet standard at kalde det staging-området ( staging area) .

En standard arbejdsgang, der bruger Git, ser sådan ud:

1. Du foretager ændringer i filer i din arbejdsmappe.

2.Forbered filer ved at tilføje deres snapshots til området for forberedte filer.

3. Foretag en commit, der tager de forberedte filer fra indekset og placerer dem i Git-mappen til permanent opbevaring.

Hvis arbejdsversionen af ​​filen matcher versionen i Git-mappen, betragtes filen som forpligtet. Hvis filen ændres, men tilføjes til det forberedte dataområde, forberedes den. Hvis filen ændres efter aflæsning fra databasen, men ikke var udarbejdet, så anses det for ændret.

5.1.3 Kom godt i gang

Alle arbejder i Git foregår inde i et lager, der indeholder alle værkets filer. Du kan oprette et lager på forskellige måder.

1. Via kontekstmenuen. For at gøre dette skal du blot højreklikke i den ønskede mappe og vælge Git Init Here.

Figur 5.1.1 Oprettelse af et lager ved hjælp af kontekstmenuen

2. Brug af kommandolinjen. For at gøre dette på samme måde skal du i den nødvendige mappe vælge Git Bash i kontekstmenuen. En kommandolinje åbnes, hvor vi opretter lageret ved hjælp af Git Init-kommandoen.

Figur 5.1.2 Oprettelse af et lager ved hjælp af kommandolinjen

Hvis du aldrig har brugt git før, skal du først indtaste dit navn og din e-mail ved hjælp af henholdsvis følgende kommandoer:

git config --global bruger.navn "Dit navn"

git config --global bruger.e-mail [e-mail beskyttet]

Det oprettede lager vil indeholde en .git-mappe. For at tilføje en fil til depotet, skal du blot kopiere den til din arbejdsmappe. Lad os tilføje ex.txt-filen til depotet. Ved at bruge git status kommandoen vil vi sikre os, at Git har set filen.

Figur 5.1.3 Tilføjelse og kontrol af en fil i depotet

Dernæst, for at tilføje en fil under versionskontrol, skal du indeksere disse filer og udføre den første commit af ændringer. Dette kan gøres med et par git add-kommandoer, der specificerer de filer, der skal indekseres, og derefter git commit.

Figur 5.1.4 Tilføjelse af en fil under versionskontrol

Git status kommandoen er det vigtigste værktøj, der bruges til at bestemme, hvilke filer der er i hvilken tilstand.

For at begynde at spore (tilføj under versionskontrol) en ny fil, brug git add “filename” kommandoen. Denne kommando tager som parameter stien til en fil eller et bibliotek, hvis det er et bibliotek, tilføjer (indekserer) kommandoen rekursivt alle filer i den givne mappe.

Git commit -m “comment” er en kommando til at oprette en commit, rette en ændring.

Ved at bruge den grafiske grænseflade til Git Gui gentager vi den forrige operation. For at gøre dette skal du vælge punktet Git Gui i kontekstmenuen.

Figur 5.1.5

I det vindue, der åbnes, skal du vælge "Opret et nyt lager." Dernæst angiver vi den mappe, hvori vi ønsker at placere depotet.

Figur 5.1.6 Oprettelse af et lager i Git Gui

Tilføj Ex.txt-filen til mappen. Klik derefter på knappen "Genlæs". For at tilføje en fil til versionskontrol skal du klikke på knappen "Forbered alle". Ex.txt-filen skal flytte fra vinduet "Ændret" til vinduet "Forberedt". For at rette ændringen skal du bruge knappen "Gem".

5.1.5 Oprettelse af en kopi af depotet

I disse dage har du et stort antal hostingmuligheder at vælge imellem, alle med deres egne fordele og ulemper.

I dette afsnit gennemgår vi processen med at oprette en konto og et nyt projekt på GitHub. Dette vil give dig en ide om de ting, der er involveret.

GitHub er den største Git-hostingside for open source-projekter i dag, og en af ​​de få, der tilbyder både offentlig og privat hosting.

Den første ting du skal gøre er at oprette en konto og oprette dit lager på http://github.com/plans.

Indtast derefter de kommandoer, vi allerede kender på Git-kommandolinjen:

Git tilføje ex.txt

Git commit -m "kommentar"

Git remote tilføje oprindelse https://github.com/Arbuz-z-z/MyHomework.git

Git push -u origin master

Git remote add-kommandoen er til at tilføje remote repositories, og git push-kommandoen er til at pushe lokale ændringer til en ekstern server.

Figur 5.1.7

Indtast brugernavn og adgangskode, der blev angivet under registreringen:

Figur 5.1.8

Nu er vores projekt lagt ud på GitHub, i depotet - MyHomework med filen Tusur.txt og vi kan give et link til det til alle, som vi vil dele projektet med.

Figur 5.1.9 Repository på GitHub

5.2 TortoiseSVN

5.2.1 Systemkrav

TortoiseSVN kører på Windows XP (med Service Pack 3) eller højere og er tilgængelig i både 32-bit og 64-bit versioner. Installationsprogrammet til 64-bit Windows inkluderer også en 32-bit del.

5.2.2 Installation

TortoiseSVN kommer som en nem at bruge installationsfil.

5.2.3 Grundkoncept

Opbevaring. Subversion bruger en central database, der indeholder alle versionerede filer med deres fuld historie. Denne database kaldes et repository. Lageret er normalt placeret kl filserver, hvor Subversion er installeret, leverer data til Subversion-klienter (for eksempel TortoiseSVN) efter anmodning. Hvis du gør backup, og kopier derefter dit lager, da det er originalen af ​​alle dine data.

Arbejdskopi. Det er præcis her, du arbejder. Hver udvikler har deres egen arbejdskopi, nogle gange kaldet en sandkasse, på deres lokale computer. Du kan få det fra depotet nyeste version filer, arbejde på det lokalt uden at interagere med nogen andre, og når du er sikker på ændringerne, kan du overføre disse filer tilbage til lageret. Arbejdskopien indeholder ikke historien om projektet, men indeholder en kopi af alle de filer, der var i lageret, før du begyndte at foretage ændringer.

TortoiseSVN er en Windows Stifinder-udvidelse, så først skal du starte Stifinder.

Figur 5.2.1 Visning i Stifinder

5.2.4 Oprettelse af et lager

Til dette projekt har vi brug for et lager oprettet på en sikker placering og en Subversion-server til at administrere det. Vi bruger Subversions lokale lagerfunktion, som giver direkte adgang til lager oprettet på din harddisk og ikke kræver en server.

Lad os først oprette en ny tom mappe på pc'en. Det kunne være hvor som helst, men til denne tutorial vil vi kalde det s:\svn_repos. Højreklik nu på den nye mappe og vælg TortoiseSVN fra kontekstmenuen > Opret lager her... Depotet, der er oprettet inde i mappen, er klar til brug. Vi vil også oprette en intern mappestruktur ved at klikke på knappen "Create Directory Structure".

Figur 5.2.2 Oprettelse af et lager

Figur 5.2.3 Gennemse lager

5.2.5 Import af et projekt

Vi har i øjeblikket lager, men det er helt tomt i øjeblikket. Lad os antage, at vi har et sæt filer i E:\\TortoiseSVN, som vi gerne vil tilføje. Lad os gå til TortoiseSVN-mappen i Stifinder og højreklikke på den. Vælg nu TortoiseSVN > Importer..., som åbner en dialogboks.

Figur 5.2.4 Importvindue

Subversion-depotet tilgås af en URL, som giver os mulighed for at pege på depotet hvor som helst på internettet. I I dette tilfælde vi skal pege på vores lokale depot, som har URL-filen:///s:/svn_repos, og som vi tilføjer navnet på vores TortoiseSVN-projekt til.

En anden vigtig funktion i denne dialog er vinduet Importer besked, hvor vi kan tilføje en besked om, hvad vi laver. Når vi skal gennemgå et projekts historie, vil disse beskeder være en værdifuld hjælp til at se, hvilke ændringer der blev foretaget, og hvornår.

5.2.6 Tjek en arbejdskopi

Nu har vi et projekt i vores repository, og vi skal lave en arbejdskopi til det daglige arbejde. Det er værd at bemærke, at import af en mappe ikke automatisk gør den mappe til en arbejdskopi. For at skabe en frisk arbejdskopi bruger Subversion udtrykket "Check Out". Vi vil udpakke TortoiseSVN-mappen fra vores lager til en udviklingsmappe kaldet e:\\TortoiseSVN\svn_repos. Lad os oprette denne mappe, højreklik derefter på den og vælg TortoiseSVN > Udpak... Indtast den URL, der skal udpakkes, i dette tilfælde file:///s:/svn_repos/TortoiseSVN, og klik på OK. Vores udviklingsmappe vil blive fyldt med filer fra depotet.

Udseendet af denne mappe er anderledes end en almindelig mappe. Hver fil har nu et grønt flag i venstre hjørne. Disse er TortoiseSVN-statusikoner, der kun er til stede i arbejdskopien. Grøn status betyder, at filen ikke adskiller sig fra versionen af ​​filen i depotet.

5.2.7 Foretage ændringer

Du kan begynde at arbejde. I mappe TortoiseSVN vi begynder at ændre filer - lad os sige, at vi laver ændringer til TortoiseSVN.docx filerne. Bemærk, at ikonerne på disse filer nu er røde og indikerer, at der er foretaget ændringer lokalt.

Højreklik på en af ​​de ændrede filer og vælg TortoiseSVN > Forskelle. TortoiseSVN-filsammenligningsværktøjet starter og viser dig præcis, hvilke linjer i filerne der blev ændret.

Figur 5.2.5 Filsammenligning

Lad os nu opdatere lageret. Denne handling kaldes "Commit Changes". Lad os klikke Højreklik på TortoiseSVN-mappen og vælg kommandoen TortoiseSVN > Commit. En forpligtelsesdialog vises med en liste over ændrede filer, og der vil være et flueben ud for hver enkelt. Vi kan kun vælge nogle få filer fra listen til at begå.

Figur 5.2.6 Committing filer

5.2.8 Tilføjelse af nye filer

Mens vi arbejder på projektet, skal vi bruge tilføje nye filer, antag at vi har tilføjet nye funktioner i en fil og tilføjet hjælp i en eksisterende fil. Højreklik på mappen og vælg TortoiseSVN > Tilføj. Tilføj dialogen viser alle uversionerede filer, og vi kan vælge de filer, vi vil tilføje. En anden måde at tilføje filer på er at højreklikke på selve filen og vælge TortoiseSVN > Tilføj.

Hvis vi nu åbner commit-mappen, vil den nye fil blive vist som "Tilføjet" og den eksisterende fil som "Ændret".

5.2.9 Annuller ændringer

Et fællestræk ved alle revisionsstyringssystemer er den funktion, der giver os mulighed for at fortryde ændringer, som vi tidligere har foretaget.

Hvis vi ønsker at slippe af med ændringer, som vi endnu ikke har formået at registrere og gendanne påkrævet fil i den form, den var i før ændringerne begyndte, og vælg derefter kommandoen TortoiseSVN > Fjern ændringer. Denne handling vil fortryde vores ændringer og returnere den faste version af den fil, vi startede med. Hvis vi kun ønsker at fjerne nogle ændringer, så kan vi bruge TortoiseMerge-værktøjet til at se ændringerne og selektiv sletningændrede linjer.

Hvis vi ønsker at fortryde en specifik revision, starter vi med log-dialogen og finder den problematiske revision. Vælg kommandoen Kontekstmenu > Kassér ændringer fra denne revision, og disse ændringer vil blive kasseret.

5.2.10 TortoiseSVN funktioner. Shell integration

TortoiseSVN integreres direkte i Windows-skallen (dvs. Explorer). Det betyder, at du kan arbejde med de værktøjer, du allerede er bekendt med, og ikke behøver at skifte til en anden applikation, hver gang du har brug for versionskontrolfunktioner!

Og du behøver ikke engang bruge Explorer. TortoiseSVNs kontekstmenuer fungerer i mange andre filhåndteringer, og i filen åbner dialoger, der bruges i de fleste standard Windows-applikationer. Du skal dog være opmærksom på, at TortoiseSVN oprindeligt er designet som en udvidelse til Windows Stifinder, og andre applikationer har muligvis ikke fuld integration, såsom ikonoverlejringer, der muligvis ikke vises.

Status for hver version af fil og mappe er angivet med et lille mærke øverst på hovedikonet. På denne måde kan du se status for din arbejdskopi med et øjeblik.

5.2.11 Grafisk brugergrænseflade

Når du ser en liste over ændringer til en fil eller mappe, kan du klikke på en revision for at se kommentarerne til den forpligtelse. En liste over ændrede filer er også tilgængelig - bare dobbeltklik på en fil for at se, hvilke specifikke ændringer der er foretaget.

Forpligtelsesdialogen er en liste, der viser alle de filer og mapper, der vil blive inkluderet i forpligtelsen. Hvert listeelement har et afkrydsningsfelt, så du kan vælge præcis, hvad du vil inkludere i commit. Uversionerede filer kan også være til stede på denne liste, så du ikke glemmer at tilføje en ny fil eller mappe til commit.

Alle Subversion-kommandoer er tilgængelige fra Explorer-kontekstmenuen. TortoiseSVN tilføjer sin egen undermenu der.

5.3 Mercurial

5.3.1 Systemkrav

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

Den bedste version af Mercurial til Windows er TortoiseHg, som kan findes på http://tortoisehg.org. Denne pakke tillader kommandolinje og grafisk brugergrænseflade.

5.3.2 Koncept

Mercurial er et distribueret (decentraliseret) versionskontrolsystem. Det betyder, at arbejdsgangen typisk ser sådan ud:

1. Til personlig computer et nyt lager oprettes (ved at klone et eksisterende lager, oprette et nyt osv.);

2. Filer ændres/tilføjes/slettes i arbejdsbiblioteket i dette lager;

3. Ændringer er forpligtet til dette lager (det vil sige til et lokalt lager på en personlig computer);

4. Trin 2 og 3 gentages så mange gange som nødvendigt;

5. Om nødvendigt synkroniseres ændringer med andre arkiver: andres ændringssæt trækkes og/eller deres egne skubbes.

Det vil sige, at alt det daglige arbejde foregår i det lokale depot, og når behovet opstår, sendes resultaterne af deres arbejde til et eller flere andre depoter. Antallet af trin, når du arbejder med eksterne lagre kan reduceres ved at indstille Mercurial til automatisk afsendelseændringer til andre depoter ved commit.

5.3.3 Kom godt i gang

Du kan arbejde i Mercurial gennem Explorer-kontekstmenuen, arbejdsområdevinduet TortoiseHg Workbench (programmet opretter en tilsvarende genvej under installationen) eller kommandolinjen ved hjælp af hg-kommandoen.

5.3.4 Oprettelse af et lager og arbejde med filer

I Mercurial sker alt inde i depotet. Projektlageret indeholder alle de filer, der er "relateret" til projektet, samt ændringshistorikken for disse filer. Der er tre forskellige måder at oprette et lager på.

For at oprette et arkiv gennem Stifinder-kontekstmenuen skal du blot højreklikke på den ønskede mappe og vælge det relevante element.

Figur 5.3.1 Oprettelse af et lager

I det vindue, der vises, kan du bekræfte placeringen af ​​depotmappen og åbne det oprettede depot i produktionsmiljøet.

Figur 5.3.2 Placering af arkivmappe

Depotet oprettes på lignende måde direkte i TortoiseHg Workbench-vinduet: sekvensen File\New Repository kalder ovenstående vindue frem med samme navn. På kommandolinjen skal du bruge hg init-kommandoen til at oprette et lager i den aktuelle mappe<имя хранилища>. Det oprettede lager vil indeholde en .hg-mappe.

Figur 5.3.3 Oprettelse af en depotmappe via kommandolinjen

Hvis vi ønsker at tilføje eksisterende filer til depotet, kopierer vi dem inde i arbejdsmappen og bruger hg add-kommandoen til at fortælle Mercurial om at begynde at overvåge dem. Lad os tilføje filen til depotet og oprette en ny revision.

Figur 5.3.4 Tilføjelse af en fil til depotet og oprettelse af en ny revision

Lad os sikre os, at Mercurial ser den gemte fil. Statuskommandoen viser status for arbejdskopien sammenlignet med status for det lokale lager. Mercurial viser, at den ser filen example.txt, men den fil er endnu ikke under versionskontrol (tegnet "?" til venstre for filnavnet). For at fortælle Mercurial, at det skal versioneres, kører vi hg add. Symbolet "A" vises til venstre for filnavnet, hvilket betyder, at readme.txt-filen vil blive tilføjet til versionskontrolsystemet under næste commit (når der oprettes en ny revision), som udføres med hg commit-kommandoen .

hg commit-kommandoen kan mislykkes første gang. Mercurial registrerer dit navn og din adresse ved hver revision, så du eller andre brugere kan kontakte forfatteren af ​​hver ændring. For at indstille brugernavnet skal du foretage ændringer i hgrc-filen, der findes i .hg-mappen inde i arbejdsmappen. Det oprindelige indhold af denne fil skulle se nogenlunde sådan ud:

# Dette er en Mercurial-konfigurationsfil.

brugernavn = Fornavn Efternavn [e-mail beskyttet]

Linjen "" erklærer en sektion af konfigurationsfilen. Du kan læse "brugernavn =..." som "indstil værdien af ​​brugernavnsvariablen i ui-sektionen". Afsnit fortsætter, indtil nye afsnit begynder. Blanke linjer og linjer, der starter med "#", ignoreres. Du kan bruge en hvilken som helst tekst som brugernavnsværdi, da denne information er beregnet til at andre mennesker kan bruge og ikke for Mercurial at fortolke. Eksemplet ovenfor brugte en fælles konvention for dette: en kombination af navn og e-mailadresse.

Når vi foretager ændringer, tager Mercurial os til en teksteditor for at indtaste en kommentar, der beskriver de ændringer, vi har foretaget i det ændringssæt. En sådan beskrivelse kaldes en ændringsmeddelelse (beskrivelse af ændringer, beskrivelse af revision). Dette vil være en rekord for læsere af, hvad vi gjorde og hvorfor, og vil blive udlæst, når vi kører hg-log, efter vi er færdige med at udgive revisionen.

Den editor, der åbner, når du kører hg commit, vil indeholde en tom linje og flere linjer, der starter med "HG:".

HG: Indtast commit besked. Linjer, der begynder med "HG:", fjernes.

HG: Lad beskeden være tom for at afbryde commit.

HG: --

HG: bruger: bruger

HG: branch "default"

HG: ændret eksempel.txt

Mercurial ignorerer linjer, der starter med "HG:". Den bruger dem kun til at fortælle os, hvilke filer den vil skrive ændringer til. Redigering eller sletning af disse linjer vil ikke påvirke noget. Hvis du ændrer mening om at udgive ændringer, mens du redigerer en kommentar, skal du blot afslutte editoren uden at gemme fil bliver ændret. Dette vil ikke forårsage ændringer i hverken depotet eller arbejdsmappen.

Kommandoen hg log udskriver som standard kun den første linje i ændringsbeskrivelsen. Derfor er det bedre at skrive kommentaren, så den første linje er adskilt. Der er ingen faste regler for resten af ​​revisionsbeskrivelsen. Mercurial selv behandler eller bekymrer sig ikke om indholdet af ændringsmeddelelser, selvom dit projekt kan have regler, der dikterer bestemt formatering.

Lad os gentage disse operationer ved at bruge TortoiseHg Workbench GUI. Før du tilføjer filen til arbejdsmappen, ser vinduet sådan ud.

Figur 5.3.5 Tilføjelse af en fil til arbejdsmappen

Lad os overføre filen til depotet og opdatere vinduet ved at klikke på knappen til venstre på værktøjslinjen. Lad os tilføje filen til versionskontrolsystemet ved hjælp af den passende kontekstmenukommando (svarende til hg add).

Figur 5.3.6 Kommando i kontekstmenuen

Figur 5.3.7 Tilføjelse af en fil

Efter at filen er tilføjet, skrives en beskrivelse af revisionen i øverste højre vindue, og en ny revision oprettes ved at klikke på knappen "Bekræft". En registrering af de foretagne ændringer vises i nederste højre vindue. Du vil bemærke, at ændringerne er repræsenteret i form af grafer.

Figur 5.3.8 Ændring af grafer

Du kan også foretage ændringer ved at bruge Hg Commit-kommandoen i kontekstmenuen for en fil, der er placeret i depotet, uden at starte Workbench.

Figur 5.3.9 Forpligtelse til ændringer

Kommandoen hg log eller hg diff svarer her til "Sammenlign filrevisioner" (højreklik på filnavnet).

Figur 5.3.10 Sammenligning af filrevisioner

I samme vindue kan du vende tilbage til en af ​​de tidligere revisioner ved at bruge kommandoen "Return to revision..." eller "Revert changes..." i hovedvinduet. Lad os demonstrere med et eksempel, efter først at have registreret nogle flere ændringer i example.txt-filen. Linjen fremhævet med rødt er omvendte ændringer.

Figur 5.3.11 Annuller ændringer

5.3.5 Oprettelse af en kopi af depotet

Selvom du kan kopiere depotet som en normal mappe, er det bedre at bruge Mercurials indbyggede kommando. Det kaldes hg clone, fordi det skaber en identisk kopi af et eksisterende depot. En af fordelene ved at bruge hg clone er, at det giver dig mulighed for at klone repositories over netværket. En anden er, at den husker, hvor vi klonede den fra.

Hvert Mercurial-lager er komplet, selvstændigt og uafhængigt. Den indeholder sin egen kopi af projektfilerne og deres historie. Et klonet depot husker, hvor det blev klonet fra, men kommunikerer ikke med det depot eller noget andet, før du fortæller det. Derfor er du fri til at eksperimentere med dit lager. Dette er sikkert, fordi dit lager er en "lukket sandkasse", som ændringer ikke vil påvirke andet end sig selv.

Lad os oprette en fjernkopi af vores lager (vi bruger Google Drive-mappen, som i sig selv er en skytjeneste), for hvilken vi udfører sekvensen af ​​kommandoer File\Clone storage i TortoiseHg Workbench. Resultatet er vist i følgende figur.

Figur 5.3.12 Oprettelse af en fjernkopi af lageret

Mercurial giver os mulighed for at skubbe ændringer til et andet lager fra det lager, vi er i dette øjeblik vi er. Lad os tilføje en ny revision (under den lokale ændringskommentar) til kildelageret og udføre kommandoen Storage\Synchronization\Push. Interface Arbejdsmiljø giver dig mulighed for kun at vælge de revisioner, der skal skubbes. Bemærk venligst, at en ny filial blev oprettet i remote-vault repository til den modtagne revision.

...

Lignende dokumenter

Muligheder for et versionskontrolsystem - et program designet til at arbejde med skiftende dokumenter. Dets egenskaber og brugspraksis. Lagerets indre struktur. Arbejdskopi af versionerede dokumenter. Centraliseret og distribueret VCS.

præsentation, tilføjet 01/05/2014


Analyse af metoder og midler til adgangskontrol til filer. Sikkerhedsproblemer ved arbejde med filer, adgangskontrolværktøjer. Ideologi for interfacekonstruktion, arkitektoniske krav. Drift af systemklasser. Estimering af omkostningerne ved et softwareprodukt.

afhandling, tilføjet 21-12-2012


Analyse af Windows 8 OS-arkitekturen. Sammenligning med tidligere versioner (Moderne brugergrænseflade, arbejde med konti, sikkerhedsmodel, opgavehåndtering, filhistorik, systemgendannelse, lagerpladser). Funktioner i forskellige versioner af Windows 8.

kursusarbejde, tilføjet 25.01.2016


Udviklingsstadier automatiseret system modtage og bestille bordbestillinger i virksomheder. Analyse af Android Development Tools udviklingsmiljø. generelle karakteristika komponentdiagrammer iOS-applikationer. Overvejelse af serverversionskontrolsystemet.

kursusarbejde, tilføjet 14/05/2014


Grafiske grænseflader og udvidelser til DOS. Historien om udviklingen af ​​Microsoft Windows-operativsystemet. Innovationer af dets moderne versioner: brugergrænseflade, sprogintegration, sikkerhedssystemer. Kronologi for udvikling og arkitektur af GNU/Linux-systemet.

abstrakt, tilføjet 25/10/2010


DirectX-udviklingssæt til Microsoft Windows, karakteristika for sæt af COM-kompatible objekter i dets sammensætning. Nøglefunktioner i versioner, shader-sprog. Beskrivelse af de vigtigste anvendte funktioner. Programmets kildekode, eksempler på dets drift.

kursusarbejde, tilføjet 16/02/2015


Windows som en mellemmand mellem brugeren og operativsystemet, der letter kommunikationsprocessen mellem dem, historien om dannelsen og udviklingen af ​​dens første versioner. Funktionelle funktioner Og Windows forskelle 95/98/ME og Windows NT/2000/XP/Vista/7, deres arkitektoniske løsninger.

præsentation, tilføjet 23.10.2013


Reduktion af omkostningerne ved reparationsarbejde for at eliminere defekter, opnået ved at bruge et informationssystem til at kontrollere dem. Analyse emneområde og software. Beregning af besparelser på grund af øget brugerproduktivitet.

afhandling, tilføjet 19/01/2017


Koncept, essens, struktur og typer af operativsystemer. Operationsstuens egenskaber Windows-systemer XP, krav til dets installation, sammenlignende analyse af versioner, konfigurationsfunktioner, versionsopdateringer, installation af enhedsdrivere og tilføjelse af nye.

abstrakt, tilføjet 20/10/2009


Udseendet af de første versioner af Windows grafiske grænseflader og udvidelser til DOS. Windows familier 3.x og Windows 9.x, deres funktioner og hovedfunktioner. Udviklingen af ​​Plug and Play-teknologi. De væsentligste forbedringer i moderne versioner Windows.

Jeg er overrasket over, hvor mange elektronikingeniører, der ikke bruger versionskontrolsystemer i deres design. Sådan var jeg selv, indtil jeg prøvede det. Nu starter jeg hvert projekt ved at oprette et lager.

Hvad er det?

Så versionskontrolsystemer (VCS) er et program, der giver dig mulighed for at gemme hele udviklingshistorien for et projekt.

Hvorfor er dette nødvendigt?

Dette er et meget, virkelig mega-praktisk udviklingsværktøj. Det sker, at du skrev og skrev et program og til sidst brød noget. Hvis programmet var i versionskontrol, kan du nemt rulle tilbage til en tidligere version af projektet og se hvad der ændrede sig, det har reddet mig mange gange.

For eksempel begyndte jeg for nylig at opleve hastighedsbegrænsninger i et FPGA-projekt. På bogstaveligt talt 5 minutter fandt jeg en version, hvor de ikke var gået ned endnu og fandt årsagen

Hvis flere personer arbejder på et projekt, er det næsten umuligt at arbejde uden et kontrolsystem - kaos begynder, alle gør noget forskelligt, og det er ikke klart, hvem der gjorde hvad. Med en SUV kan du nemt se, hvem der gjorde hvad, ændringer foretaget af andre bliver meget mindre uventede.

Derudover er der mere eksotiske anvendelser. For eksempel sender jeg ændringer til dette websted til serveren ved hjælp af et versionskontrolsystem.

Hvilken skal man vælge?

Der er et stort udvalg af versionskontrolsystemer. Personligt valgte jeg Mercurial for mig selv. Fantastisk system, som jeg anbefaler til alle - hurtigt, på tværs af platforme, med en fremragende grafisk klient. Eksistensen af ​​webstedet viste sig at være et meget stærkt argument til fordel for det. Jeg har aldrig fortrudt mit valg.

Udover Mercurial er git og svn ret almindelige nu. Git er mere almindeligt i Linux-mængden, svn er mere almindeligt i et virksomhedsmiljø. Jeg prøvede at bruge dem (dog ikke ret længe), men jeg så ikke noget, der ville gøre det værd at stoppe med mercurial.

Der er en hjemmeside, hvor du kan gemme dine projekter. Det er bemærkelsesværdigt for det faktum, at du i modsætning til github kan oprette lukkede repositories gratis (et repository er et sted, hvor projekter er gemt). Du skal kun betale for de projekter, der er lukkede, og hvor der arbejder mere end 5 personer. Samtidig kan grænsen udvides til 8 ved at udsende invitationer. Jeg har endnu ikke overskredet denne grænse. Derudover er der en wiki og en bug tracker, generelt alt hvad du behøver for at udvikle projekter.

Da jeg begyndte at arbejde med det, understøttede siden kun Mercurial (delvis på grund af dette valgte jeg Mercurial), men nu kan du oprette git-repositories der. Derudover kan du linke dit domæne til bitbucket. Her er for eksempel min version: hg.bsvi.ru

Hvordan starter man?

Først skal du downloade klienten. Jeg bruger skildpaddeHg. Jeg tror, ​​der ikke vil være nogen problemer med installationen.

Efter installationen er det en god idé at indstille et standardbrugernavn. For at gøre dette skal du redigere filen C:/Users/BSVi/mercurial.ini, du skal tilføje linjen der

Brugernavn = bsvi

Naturligvis skal bsvi erstattes med dit navn.

Nu er vi klar til at lave et projekt og begynde at lave noget. For at gøre dette skal du klikke på "Opret lager":

Der udfylder vi navn, beskrivelse, vælger sprog. Du kan tilføje en wiki og en fejlsporing.

Klik nu på knappen "klon" og kopier det, der vises der:

Yderligere handlinger afhænger af, hvilken filhåndtering du bruger. Personligt bruger jeg langt. Jeg indsætter bare den kopierede linje i kommandolinjen:

Hvis du bruger explorer (um), total commander eller noget lignende, så skal du højreklikke og vælge:


Der, i kildefeltet, skal du naturligvis indsætte stien uden hg klon:

Du bliver bedt om din adgangskode, og test-repo-biblioteket vil dukke op, hvor projektet faktisk vil være placeret.

Lad os tilføje nogle filer

Hvis du allerede har udviklinger til projektet, kan du blot kopiere dem til en mappe. Til undervisningsformål opretter vi en fil main.c med følgende indhold:

#omfatte int main() ( returner 0; )

Lad os nu forpligte os. En commit er at foretage ændringer i et projekt. For at gøre dette skal du starte hg workbench. Jeg skriver bare thg på kommandolinjen, for opdagelsesrejsende filadministratorer du skal trykke på RMB->Hg Workbench.

Der vil være et spørgsmålstegn ved siden af ​​vores fil (det betyder, at den ikke er blevet tilføjet til projektet). Lad os sætte et flueben ud for det og skrive en beskrivelse af, hvad der blev gjort:


Herefter skal du naturligvis klikke på knappen "forpligte".

Det er det, der er lavet ændringer i projektet. Her skal du være opmærksom på, at ændringerne kun blev foretaget på den lokale computer (det vil sige, at de endnu ikke er på serveren). For at overføre ændringer til serveren skal du klikke på "push" knappen, her er den:

For at skubbe ændringer til serveren skal du naturligvis bruge en adgangskode.

Lad os ændre filen

Lad os nu se på en af ​​de meget vigtige funktioner ved versionskontrolsystemer - filversionssporing. Lad os tilføje skærmoutput til vores program:

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

Lad os gå til hg arbejdsbænk. Når jeg arbejder på et projekt, lukker jeg det ikke engang (mere om det senere), tryk på f5 for at opdatere listen over filer. Nu kan du se, hvad der har ændret sig siden sidste commit:

Og dette er et meget kraftfuldt værktøj. Normalt, under debugging, vises en masse forskelligt affald i filerne. Så at se på, hvad du vil begå, renser projektet meget godt for skrald.

Hvad skal man gøre med affald?

Når du arbejder på et projekt, dukker der en masse affald op - for eksempel objektfiler, filer genereret af IDE, nogle midlertidige filer, og så videre. Det ville være rart at fjerne alt, der ikke vedrører selve projektet, fra depotet. Der er en fil til this.hgignore (ja, med en prik i begyndelsen af ​​navnet).

Lad os tilføje en skraldefil til projektet. For eksempel oprettede jeg main.obj:

Hvis du nu opdaterer listen over filer, så vil hg workbench naturligvis tilbyde at tilføje denne fil til projektet:

Lad os nu oprette en file.hgigonre og skrive der, at vi vil ignorere alle filer med filtypen obj:
syntaks:glob *.obj

Hvis du opdaterer listen over filer, forsvinder obj-filerne, men .hgignore-filen vises, som kan begås:

Hvordan kan jeg rulle ændringer tilbage?

Lad os gendanne vores program til den tilstand, det havde, før det blev vist på skærmen. For at gøre dette skal du blot vælge den commit, du vil rulle tilbage til, og klikke på denne knap:

Du kan rulle en separat fil tilbage på næsten samme måde.

Konklusion

Det er alt, dette er minimumsviden om versionskontrolsystemer, der giver dig mulighed for at gemme historien om projektudvikling. Der er naturligvis mange andre muligheder, som jeg vil tale om senere.

Mange tror, ​​at versionskontrolsystemer kun skal bruges, hvis man udvikler noget i en stor skare, men det er ikke sandt :) Selv når man arbejder på et projekt alene, er versionskontrolsystemer en stor hjælp.

For eksempel, her er et skærmbillede af min UTC (som jeg selv udvikler) på det sværeste sted i hg workbench:

Misha Radionov

Hvad er versionskontrolsystemer, og hvorfor har du brug for dem?

Vende tilbage til

Forestil dig situationen: du hyrede en udvikler til at tilføje f.eks. en hurtig ordrefunktion til din onlinebutik. Da siden skal fungere og generere indtægter hele tiden, beslutter udvikleren at udføre arbejde på sin lokale server.

Mens det virker, sendte designeren nyt logo, som du straks erstattede i skabelonen på webstedets hovedversion. Samtidig reducerede du skrifttypen i produktnavnene, så alt passer på skærmen på netbooken hos en af ​​dine kunder. Så har du opdateret et par produktbilleder. På dette tidspunkt besluttede udvikleren at gøre dig en tjeneste - at rense den helt ærligt unødvendige funktionalitet i sin version af dit websted, som den tidligere udvikler skrev. Som det ofte sker, tror I begge, at I ikke gjorde noget alvorligt. Men du tager fejl.

Når udviklerens version er uploadet til siden, holder alle udviklingsdeltagere sig i hovedet. Dine arbejdsresultater slettes, fejl vises. Det er ikke klart, hvad problemet er. Forhåbentlig vil du på dette tidspunkt i det mindste have en fungerende backup ved hånden, og i værste fald vil du bruge flere dage på manuelt at fange problemer. Hvordan undgår man at komme i sådan en situation? Lad os tale.

Hvad er VCS?

Versionskontrolsystem (fra det engelske Version Control System, VCS eller Revision Control System) - software til at gøre det nemmere at arbejde med at ændre information Wikipedia

Og nu på en enkel måde

Et versionskontrolsystem giver dig mulighed for at gemme flere versioner af det samme dokument, vende tilbage til tidligere versioner, hvis det er nødvendigt, bestemme, hvem der har foretaget en bestemt ændring og hvornår, og meget mere.

Med andre ord giver VCS flere udviklere mulighed for at ændre de samme filer samtidigt og uden at oprette lokale kopier på deres computere. I dette tilfælde gemmes alle ændringsmuligheder separat, og du kan foretage forskellige varianter den samme fil, under hensyntagen til forskellige redigeringer fra forskellige mennesker. Hvis flere ændringer påvirker det samme fragment af dokumentet, vil systemet bede dig om at vælge den ønskede indstilling.

For at arbejde med et versionskontrolsystem bruges typisk en separat computer (server) eller en internettjeneste, som giver mulighed for at leje en sådan server.

Simpelt eksempel

Hvis flere personer arbejder på et Excel-dokument, kan kun én person redigere filen, resten har skrivebeskyttet adgang. Ved hjælp af VCS får du mulighed for at redigere en fil på én gang og af alle. Den eneste betingelse er, at efter ændringer skal filen gemmes på serveren og ikke til lokal computer. Men som nævnt ovenfor giver værktøjerne dig mulighed for at udføre sådanne handlinger nemt og enkelt.

Versionsstyringssystem i Flag studio

I vores arbejde bruger vi Git versionskontrolsystemet. Dette system er et af de mest almindelige VCS. Dette resulterer i en masse støtte fra Git-fællesskabet. En anden fordel er, at det er nemt at mestre systemet, fordi... der er et bredt spektrum software produkter udviklet specielt til dette system.

Vi bruger et kodeudviklingsprogram kaldet IntelliJ IDEA. Det giver en IDE, det vil sige en stor funktionel base for udviklere, herunder brugervenlig grænseflade om at arbejde med versionskontrol. Så uden at forlade programmet kan vi se, hvilke ændringer der blev foretaget af en eller anden udvikler på det websted, vi har brug for. Eller, uden frygt for at miste dine ændringer, få ændringer foretaget af en anden udvikler. IDEA-grænsefladen ser nogenlunde sådan ud:

Vi bruger Bitbucket-skytjenesten til at gemme versioner. Denne service har en praktisk grænseflade og giver dig udover tjenester til lagring af dine versioner mulighed for at administrere adgangsregler til dine produkter forskellige brugere. Fordelen ved at bruge cloud storage er, at der ikke stilles krav til kendskab til serveropsætning og administration. Du får alt ud af æsken og kan begynde at bruge det med det samme. Alt hvad du uploader til bitbucket er privat, dvs. uden din tilladelse kan ingen andre endda se, hvad du gemmer. Bitbucket-grænseflade:

Hvad giver det os at bruge VCS?

• Fuld tillid til, at de filer, vi modtager fra systemet, altid er up-to-date til enhver tid.
• Evnen til at få den nødvendige version fra enhver computer, der giver dig mulighed for at oprette forbindelse til serveren.
• Når du gemmer en fil i VCS, behøver du ikke tænke på, at nogen, der arbejder med den samme fil, vil gemme og overskrive ændringerne igen.
• For softwareudviklere giver brug af systemet dig også mulighed for at acceptere/afvise ændringer foretaget af en af ​​udviklerne.

Hvad giver det vores kunder?

Lad os vende tilbage til den situation, der blev diskuteret i begyndelsen. Som det ville være med VCS. Udvikleren uploader sin kode til en separat filial. Du gennemgår ændringerne og anvender dem kun, hvis du kan se, at alt er i orden. Alt er opbevaret ét sted, sikkert, hurtigt og bekvemt. Og når der er flere udviklere, vil du slet ikke kunne undvære VCS.

Aktiver venligst JavaScript for at se

Grundlæggende om VCS

Introduktion

Før du taler om et specifikt versionskontrolsystem, skal du forstå, hvad det er, hvad de er, og hvorfor de dukkede op i første omgang. Dette foredrag har til formål at give en indledende introduktion til versionskontrol og versionskontrolsystemer, og først vil jeg tale om oprindelsen af ​​versionskontrolværktøjer, hvilke versionskontrolsystemer der er populære i øjeblikket, og hvad de vigtigste forskelle er mellem dem.

Om versionskontrol

Hvad er versionskontrol, og hvorfor har du brug for det?

Det er nok værd at starte med definitionen af ​​et versionskontrolsystem (VCS) – dette er et system, der registrerer ændringer i en eller flere filer, så det i fremtiden er muligt at vende tilbage til visse gamle versioner af disse filer.

På det seneste er filer slutresultatet for mange erhverv (for eksempel skrivning, videnskabeligt arbejde og selvfølgelig softwareudvikling). Der bruges meget tid og kræfter på at udvikle og vedligeholde disse filer, og ingen ønsker at skulle bruge endnu mere tid og kræfter på at gendanne data, der er tabt som følge af ændringer.

Lad os forestille os, at en programmør udvikler et projekt, der består af en lille fil (eksemplet er i øvrigt ret virkeligt, ikke syntetisk og er blevet stødt på i det virkelige liv). Efter at have frigivet den første version af projektet, står han over for et vanskeligt valg: det er nødvendigt at løse de problemer, der er rapporteret af brugere af den første version og samtidig udvikle noget nyt til den anden. Selvom du blot skal løse problemer, der opstår, er der stor sandsynlighed for, at projektet efter nogle ændringer holder op med at fungere, og du skal finde ud af, hvad der er ændret for at gøre det lettere at lokalisere problemet. Det er også tilrådeligt at føre en form for log over ændringer og rettelser, der er foretaget, for ikke at udføre det samme arbejde flere gange.

I det enkleste tilfælde kan ovenstående problem løses ved at gemme flere kopier af filerne, for eksempel en til at rette fejl i den første version af projektet og en anden til nye ændringer. Da ændringerne normalt ikke er særlig store i forhold til filstørrelsen, er det muligt kun at gemme de ændrede linjer ved hjælp af diff-værktøjet og senere flette dem ved hjælp af patch-værktøjet. Men hvad nu hvis projektet består af flere tusinde filer og hundrede mennesker arbejder på det? Hvis vi i dette tilfælde bruger metoden med opbevaring separate kopier filer (eller endda bare ændringer), så vil projektet gå i stå meget hurtigt. I de efterfølgende forelæsninger vil jeg bruge programmets kildekoder til eksempler, men faktisk kan næsten enhver filtype lægges under versionskontrol.

Hvis du er grafiker eller webdesigner og gerne vil gemme alle versioner af et billede eller layout - og det ville du sandsynligvis - så er det en meget klog beslutning at bruge et versionskontrolsystem. VCS gør det muligt at returnere individuelle filer til som før, vende tilbage til tidligere tilstand hele projektet, se ændringer, der sker over tid, afgøre, hvem der var den sidste til at lave ændringer i et modul, der pludselig holdt op med at fungere, hvem og hvornår der introducerede en form for fejl i koden og meget mere. Generelt, hvis du, mens du bruger VCS, ødelægger alt eller mister filer, kan alt nemt gendannes. Plus, overhead for alt, hvad du får, vil være meget lille.

Lokale versionskontrolsystemer

Som nævnt tidligere er et eksempel på en lokal SUV ekstremt simpelt: mange mennesker foretrækker at kontrollere versioner ved blot at kopiere filer til en anden mappe (normalt tilføjer nuværende dato til katalognavnet). Denne tilgang er meget almindelig, fordi den er enkel, men den fejler også oftere. Det er meget nemt at glemme, at du er i den forkerte mappe og ved et uheld ændrer den forkerte fil, eller kopierer filer til det forkerte sted og overskriver de filer, du har brug for. For at løse dette problem har programmører længe udviklet lokal VCS med en simpel database, der gemmer alle ændringer til de nødvendige filer

En af de mest populære VCS'er af denne type er RCS (Revision Control System), som stadig er installeret på mange computere. Selv på det moderne Mac OS X-operativsystem er rcs-værktøjet installeret sammen med udviklerværktøjer. RCS blev udviklet i begyndelsen af ​​1980'erne af Walter F. Tichy. Systemet giver dig mulighed for at gemme versioner af kun én fil, så du skal håndtere flere filer manuelt. For hver fil under systemkontrol gemmes versionsoplysninger i speciel fil med navnet på den originale fil, hvortil tegnene ",v" tilføjes til sidst. For eksempel for filen file.txt vil versionerne blive gemt i filen file.txt,v. Dette værktøj er baseret på at arbejde med sæt patches mellem par af versioner (en patch er en fil, der beskriver forskellen mellem filerne). Dette giver dig mulighed for at genskabe enhver fil på et hvilket som helst tidspunkt og anvende patches sekventielt. Systemet bruger diff-værktøjet til at gemme versioner. Selvom RCS opfylder minimumskravene til et versionskontrolsystem, har det følgende hovedulemper, som også tjente som drivkraften til oprettelsen af ​​følgende system under overvejelse:

• Arbejd med kun én fil, hver fil skal styres separat;
• Upraktisk mekanisme samtidig arbejde flere brugere med systemet, er lageret blot blokeret, indtil brugeren, der blokerede det, låser det op;
• Ingen befrier dig fra sikkerhedskopier; du risikerer at miste alt.

Centraliserede versionskontrolsystemer

Den næste store udfordring var behovet for at samarbejde med udviklere på andre computere. For at løse dette blev der skabt centraliserede versionskontrolsystemer (CVCS). Sådanne systemer, såsom CVS, Subversion og Perforce, har en central server, der gemmer alle filer under versionskontrol, og en række klienter, der modtager kopier af filerne fra den. Dette har været standarden for versionskontrolsystemer i mange år.

Denne tilgang har mange fordele, især i forhold til lokal SLE. For eksempel ved alle, hvem der laver hvad i projektet. Administratorer har klar kontrol over, hvem der kan gøre hvad, og selvfølgelig er CSKB meget nemmere at administrere end lokale databaser på hver klient. Der er dog flere alvorlige ulemper ved denne tilgang. Den mest åbenlyse er, at den centraliserede server er det svage punkt i hele systemet. Hvis serveren går ned i en time, kan udviklere ikke interagere i en time, og ingen kan gemme en ny version af deres arbejde. Hvis disken med den centrale database er beskadiget, og der ikke er nogen sikkerhedskopi, mister du absolut alt - hele projektets historie, med mulig undtagelse af flere fungerende versioner gemt på brugernes arbejdsmaskiner.

CVS

CVS (Concurrent Versions System) er stadig det mest udbredte system, men mister hurtigt sin popularitet på grund af mangler, som jeg vil diskutere nedenfor. Dick Grune udviklede CVS i midten af ​​1980'erne. For at gemme individuelle filer bruger CVS (såvel som RCS) filer i RCS-formatet, men giver dig mulighed for at administrere grupper af filer, der er placeret i mapper. CVS bruger også en klient-server-arkitektur, hvor al versionsinformation er gemt på serveren. Ved at bruge en klient-server-arkitektur kan CVS bruges selv af geografisk distribuerede teams af brugere, hvor hver bruger har deres egen arbejdsmappe med en kopi af projektet. Som navnet antyder, kan brugere dele systemet.

Mulige konflikter ved ændring af den samme fil løses ved, at systemet kun tillader ændringer til den seneste version af filen. Derfor anbefales det altid at opdatere din arbejdskopi af filerne, før du uploader dine ændringer i tilfælde af mulige modstridende ændringer. Ved opdatering foretager systemet automatisk ændringer i arbejdskopien og kun i tilfælde af modstridende ændringer i en af ​​filplaceringerne kræves manuel rettelse af konfliktplaceringen.

CVS giver dig også mulighed for at opretholde flere udviklingslinjer på et projekt ved hjælp af udviklingsgrene. Som nævnt ovenfor kan du således rette fejl i den første version af projektet og samtidig udvikle ny funktionalitet.

CVS blev brugt af en lang række projekter, men det var selvfølgelig ikke uden mangler, hvilket senere førte til fremkomsten af ​​det næste system under overvejelse. Lad os se på de vigtigste ulemper:

• Da versioner er gemt i RCS-filer, er der ingen måde at gemme mappeversioner på. Standard metode at komme uden om denne forhindring er at gemme en fil (for eksempel README.txt) i en mappe;
• Flytning eller omdøbning af filer er ikke underlagt versionskontrol. Standardmåden at gøre dette på er først at kopiere filen, fjerne den gamle ved hjælp af cvs remove-kommandoen og derefter tilføje den med sit nye navn ved hjælp af cvs add-kommandoen;

Subversion

Subversion (SVN) blev udviklet i 2000 på initiativ af CollabNet. SVN blev oprindeligt udviklet som et "bedre CVS", og udviklernes hovedmål var at rette fejl i CVS-designet og samtidig bevare en lignende grænseflade. SVN bruger ligesom CVS en klient-server-arkitektur. De mest markante ændringer sammenlignet med CVS omfatter:

• Atomændringer (commit). Hvis commit-behandlingen afbrydes, vil der ikke blive foretaget ændringer.
• Omdøbning, kopiering og flytning af filer bevarer hele historikken for ændringer.
• Mapper, symbolske links og metadata er underlagt versionskontrol.
• Effektiv ændringslagring til binære filer.

Distribuerede versionskontrolsystemer

Og i denne situation kommer distribuerede versionskontrolsystemer (DVCS) i spil. I systemer som Git, Mercurial, Bazaar eller Darcs tjekker klienter ikke blot de seneste versioner af filer, men kopierer hele lageret. Derfor, i tilfælde af at serveren, som arbejdet gik igennem, "dør", kan ethvert klientlager kopieres tilbage til serveren for at gendanne databasen. Hver gang en klient henter en ny version af filer, opretter han til sig selv fuld kopi alle data.

Derudover giver de fleste af disse systemer dig mulighed for at arbejde med flere fjerndepoter, så du kan arbejde forskelligt med forskellige grupper af mennesker på det samme projekt på samme tid. Således kan du i ét projekt udføre flere typer arbejdsprocesser samtidigt, hvilket er umuligt i centraliserede systemer.

Hvorfor er der behov for distribuerede systemer?

Som navnet antyder, er en af ​​hovedideerne ved distribuerede systemer fraværet af et klart udpeget centralt versionslager - et lager. I tilfælde af distribuerede systemer kan et sæt versioner distribueres helt eller delvist mellem forskellige lagre, inklusive fjerntliggende. Denne model passer perfekt ind i arbejdet i distribuerede teams, for eksempel et team af udviklere fordelt rundt om i verden, der arbejder på ét open source-projekt. kildekode. Udvikleren af ​​et sådant team kan downloade alle versionsoplysningerne og derefter kun arbejde på den lokale maskine. Så snart resultatet af et af arbejdsstadierne er opnået, kan ændringerne uploades til et af de centrale arkiver eller publiceres til visning på udviklerens websted eller i postliste. Andre projektdeltagere vil til gengæld være i stand til at opdatere deres kopi af versionslagret med nye ændringer eller prøve de offentliggjorte ændringer på en separat testudviklingsgren. Desværre, uden en god projektorganisation, kan manglen på ét centralt lager være en ulempe ved distribuerede systemer. Hvis der i tilfælde af centraliserede systemer altid er ét fælles lager, hvorfra du kan hente den seneste version af projektet, så skal du i tilfælde af distribuerede systemer organisatorisk beslutte, hvilken af ​​projektgrenene der skal være den vigtigste. Hvorfor distribueret system versionskontrol kan være interessant for nogen, der allerede bruger et centraliseret system - såsom Subversion? Alt arbejde involverer at træffe beslutninger, og i de fleste tilfælde skal du prøve forskellige muligheder: Når du arbejder med versionskontrolsystemer, bruges udviklingsgrene til at overveje forskellige muligheder og arbejde med store ændringer. Selvom dette er et ret naturligt koncept, er det ikke nemt at bruge i Subversion. Desuden bliver alt mere kompliceret i tilfælde af flere sekventielle fusioner fra en gren til en anden - i dette tilfælde skal du præcist angive de indledende og endelige versioner af hver ændring for at undgå konflikter og fejl. For distribuerede versionskontrolsystemer er udviklingsgrene et af de grundlæggende koncepter - i de fleste tilfælde er hver kopi af et versionslager en udviklingsgren. Således er mekanismen til at flette ændringer fra en gren til en anden i tilfælde af distribuerede systemer en af ​​de vigtigste, hvilket giver brugerne mulighed for at lægge mindre indsats, når de bruger systemet.

Kort beskrivelse af populære distribuerede SUV'er

• Git er et distribueret versionskontrolsystem udviklet af Linus Torvalds. Git var oprindeligt beregnet til brug i udviklingsprocessen Linux kerner, men begyndte senere at blive brugt i mange andre projekter - som for eksempel X.org og Ruby on Rails, Drupal. Git er i øjeblikket det hurtigst distribuerede system, der bruger den mindste revisionsbutik. Men samtidig, for brugere, der migrerer, for eksempel fra Subversion, kan Git-grænsefladen virke kompliceret;
• Mercurial er et distribueret system skrevet i Python sprog med flere udvidelser i C. Projekter, der bruger Mercurial, omfatter Mozilla og MoinMoin.
• Bazaar er et system udviklet af Canonical, kendt for sin Ubuntu-distribution og hjemmeside https://launchpad.net/. Systemet er hovedsageligt skrevet i Python og bruges af projekter som MySQL.
• Codeville er et distribueret system skrevet i Python, der bruger en innovativ algoritme til at kombinere ændringer (fletning). Systemet bruges for eksempel i udviklingen af ​​den originale BitTorrent-klient.
• Darcs er et distribueret versionskontrolsystem skrevet i Haskell, som f.eks. bruges af Buildbot-projektet.
• Monotone er et system skrevet i C++ og bruger SQLite som revisionslagring.

Spørgsmålet ville have været passende for 25 år siden. I omkring 10 år nu har brugen af ​​et versionskontrolsystem været et must for ethvert hold. Fælles, bekvem, sikker opbevaring af kildekoder med en historik over ændringer, kollektivt ejerskab af koden, opgavefordeling og applikationsfunktionalitet i teamet. Samt automatisering af builds, udrulninger og kontinuerlig integration generelt.

Ivan Nemytchenko, GitLab
Gør dit liv lettere, når du udvikler softwareprodukter sammen.

Alexander Makarchuk, qb
Optimering af teamudvikling.

Petr Urvaev, SimbirSoft
Under udviklingen ændres projektkoden aktivt. Samtidig er det nødvendigt at føre optegnelser over, hvad der allerede er blevet gjort, og koordinere de enkelte deltageres handlinger for samtidig at ændre koden, så forbedringer fra projektdeltagere tager højde for alle tidligere foretagede redigeringer af andre deltagere. Et versionskontrolsystem giver dig mulighed for at automatisere denne proces.

2. Hvilke faktorer påvirker valget af et versionskontrolsystem?

Nikolay Fetyukhin,MST
Understøtter kernen af ​​versionskontrolsystemet og dets specifikke implementering, gør teamet bekendt med det. Oftest bruges ét system til alle projekter. Undtagelser kan for eksempel være kundekrav.

Ivan Nemytchenko, GitLab
Populariteten af ​​et bestemt system, hvorfra alt andet følger: support i applikationer og tjenester, mængde og kvalitet af dokumentation, tilgængelighed af en ekspert "i nærheden" osv.

Alexander Makarchuk, qb
I vores tilfælde er valget baseret på populariteten af ​​versionskontrolsystemet og udviklernes færdighedsniveau med det.

Petr Urvaev, SimbirSoft
Først og fremmest svarer versionskontrolsystemets muligheder til den udviklingsproces, som teamet har vedtaget. For det andet, hvilket versionskontrolsystem er mere almindeligt for projektdeltagere at arbejde med?

3. Hvordan implementerer man brugen af ​​versionskontrol i et team?

Nikolay Fetyukhin,MST
I dag dimitteres selv moderne studerende med en generel forståelse af, hvorfor der er brug for versionskontrolsystemer, så spørgsmålet om implementering er ikke helt korrekt. Normalt starter alle projekter bare med at oprette et lager som standard. Hvis i det generelle tilfælde, så bør du tale med teamet, finde ud af, hvorfor der ikke er noget versionskontrolsystem på projektet (indimellem er der forskellige meget specifikke tilfælde), og hvis problemerne kan overvindes, så hold et par seminarer inden for teamet på et specifikt versionskontrolsystem (hvis påkrævet) og kør.

Ivan Nemytchenko, GitLab
Giv dem mulighed for at arbejde uden et versionskontrolsystem, så de mærker al smerten. Så "slip" dem et Git-cheatsheet, og de vil lære og implementere alt selv. Men sådan kan man arbejde med skolebørn og elever. Modne udviklere har normalt ikke dette spørgsmål.

Alexander Makarchuk, qb
Langsomt men sikkert kommer alle til dette på egen hånd.

Petr Urvaev, SimbirSoft
I de fleste moderne projekter behovet for at bruge et versionskontrolsystem rejser ingen spørgsmål. Når man lærer at arbejde med det, er det nok at konfigurere det til behageligt arbejde og læs et kort foredrag om de vigtigste funktioner i det anvendte versionskontrolsystem, med eksempler på brug.

4. Hvad gjorde Git til standarden i verden af ​​versionskontrolsystemer? Vil nogen være i stand til at fortrænge ham fra hans ledende stilling?

Nikolay Fetyukhin,MST
Git introducerede oprindeligt nogle nyttige ting, såsom lokale commits, og løste også en masse branchefusionsproblemer, der plagede den tidligere trendsætter, Subversion (SVN). Helt fra begyndelsen kæmpede den for popularitet med Mercurial (Hg), som er enklere i nogle aspekter, men tog til sidst føringen.

Ivan Nemytchenko, GitLab
Takket være det faktum, at Linus Torvalds angreb problemet med distribueret udvikling fra højre side under hensyntagen til manglerne ved forgængersystemer. Bevæge sig? Hvorfor?

Alexander Makarchuk, qb
Takket være det faktum, at Git er fantastisk. Ingen vil fortrænge ham i meget lang tid.

Petr Urvaev, SimbirSoft
Den største fordel ved Git er udviklingen af ​​værktøjer til at arbejde med det og evnen til at gemme resultaterne af arbejdet med flere parallelle åbne opgaver i det, så mellemresultaterne ikke påvirker hinanden, og samtidig kan de endelige resultater ganske let kombineres til en endelig version af applikationen. En vigtig rolle i Gits universelle popularitet i CVS-verdenen blev også spillet af GitHub-ressourcen, som er vært for tusindvis af repositories på forskellige sprog.

5. Hvad kan udviklere ikke lide ved Git? Hvorfor vælger nogle mennesker andre mindre populære løsninger?

Nikolay Fetyukhin,MST
Den eneste væsentlige ulempe ved Git for os er nogle problemer med at spore ændringer: filialer kan slettes, og kun en merge-commit kan forblive. Dette skyldes i høj grad, at Git har filialer knyttet til commits. Git har også en stejlere indlæringskurve end førnævnte Mercurial eller Subversion.

Alexander Makarchuk, qb
Inden for rammerne af vores opgaver er alle tilfredse.

Petr Urvaev, SimbirSoft
Git er ret praktisk, men kræver læring (for dem, der ikke allerede ved det) og aktive trin for at skifte til det, så nogle hold foretrækker at blive med de versionskontrolsystemer, de bruger. Også valget af versionskontrolsystem kan bestemmes af de anvendte udviklingsværktøjer.

6. Hvor almindeligt er det at bruge versionskontrolsystemer til at håndtere andre filer end blot kode?

Nikolay Fetyukhin,MST
I øjeblikket overalt. De samme cloud-systemer som One Drive, Yandex.Disk, Dropbox og Google Drive er baseret på en ideologi, der replikerer versionskontrolsystemer.

I praksis er brugen af ​​konventionelle versionskontrolsystemer til lagring af dokumenter almindelig, men ikke for almindelig; finesser opstår ved beregning af ændringer, da de fleste af nutidens almindelige dokumentformater er binære, og deres ændringssæt ikke er læselige af mennesker.

Alexander Makarchuk, qb
Bruges konstant.

Petr Urvaev, SimbirSoft
Versionsstyringssystemer er primært rettet mod at arbejde med et stort antal små filer, som hovedsageligt bruges i udvikling. Brug lignende systemer for filer af ikke-tekstformater (binære) er det som regel ineffektivt, og i nogle tilfælde er det fuldstændig umuligt. For at gemme andre filer bruges derfor sædvanligvis specialiserede systemer, tilpasset til at arbejde med bestemte dataformater.