• hjem
  •  > 
  • Multimedier
  •  > 
  • Versionsstyring i softwareprojekter. Forpligtelsesdialogen er en liste, der viser alle de filer og mapper, der vil blive inkluderet i forpligtelsen

Versionsstyring i softwareprojekter. Forpligtelsesdialogen er en liste, der viser alle de filer og mapper, der vil blive inkluderet i forpligtelsen

Hej, Habr. Jeg besluttede at berøre et emne, der er blevet udtømt i mange artikler, mere specifikt for at beskrive den stort set ikke-standardiserede (jeg vil sige usorterede) brug af versionskontrolsystemer (herefter benævnt VCS). Med programmører, lad os gemme de rådne tomater og gå forbi, fordi denne artikel- ikke for dig. Ja, I har alle allerede lært alle forviklingerne ved Git, SVN, CVS og kender mange andre buzzwords. Lad os, blotte dødelige, blive bekendt med alle fordelene ved at bruge hård valuta.
Jeg inviterer alle, der har lyst til at stifte bekendtskab med hårdvalutasystemet, samt alle dem, der på den ene eller anden måde beskæftiger sig med hurtigt skiftende data.

Hvorfor er dette nødvendigt?

Jeg er selv studerende på et teknisk universitet og arbejder næsten konstant med dokumenter (tekster, tegninger, tegninger) og ændrer dem tre (ti, hundrede) gange om dagen. Nogle gange viser det sig, at ændringer foretaget i løbet af den sidste uge skal fortrydes, og dokumenterne skal returneres til den tilstand, de var for en uge siden. Det er godt, hvis der kun blev foretaget nogle få redigeringer, i dette tilfælde kan halvtreds hits på Ctrl+Z hjælpe. Men hvis der i løbet af denne uge var mere eller mindre aktivt arbejde med et dokument vil det ikke være muligt blot at gendanne status "til en vigtig redigering foretaget for en uge siden." For at gøre dette skal du bruge en kopi af dokumentet på tidspunktet "før en vigtig redigering", samt et dusin flere kopier "før en anden vigtig redigering", "før en tvivlsom redigering" og "før en redigering, der vil mest skal sandsynligvis fortrydes." I princippet er denne tilgang mulig og praktiseres af mange. Indtil for nylig beholdt jeg selv vigtige versioner af filer, gemte dem med "dato_tid"-præfikser, og det så ud til, at jeg var glad. Fordelen ved denne metode er dens enkelhed, ulempen er, at arbejdsmapperne "svulmer" og er ubelejlige at bruge. Og hvis du på en eller anden måde kan bekæmpe den første af dem (store harddiske og 7zip), så skulle der gøres noget ved ulejligheden.

Hvad kan man gøre ved dette, eller hvad er SLE

Lad os tage et afsnit fra Wikipedia: "Et versionskontrolsystem (fra det engelske Version Control System, VCS eller Revision Control System) er software til at lette arbejdet med at ændre 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, bestemme, hvem der har foretaget en bestemt ændring og hvornår, og meget mere." Det ligner den måde, Wikipedia selv fungerer på - alle versioner af artikler med alle redigeringer er tilgængelige for undersøgelse.
Brug af VCS i en situation, hvor du skal gemme mange versioner af filer, er således, hvad du har brug for. Fordelene ved denne tilgang omfatter brugervenlighed og besparelse af gratis diskplads takket være den såkaldte delta-komprimering (når ikke selve filerne gemmes i forskellige versioner, men skifter fra version til version, hvilket reducerer mængden af ​​lagrede data). Lad os prøve.

Hvilke typer hårdvalutavalutaer findes der?

Den samme Wikipedia foreslår, at hårdvalutavaluta kan centraliseres og distribueres, store som små, med eller uden klokker og fløjter. Vi er ikke specielt interesserede i dette, da vi vil bruge (af i det mindste, for det første) kun en del af funktionaliteten af ​​valutavekslingssystemet. Lad os overveje netop denne funktionalitet.
Næsten alle VCS'er er en form for lagring, hvor alle versioner af de filer, vi arbejder med, er gemt. Her er det nødvendigt at præcisere, at versionerne af lagrede filer oftest bestemmes af brugeren. Vi lavede f.eks. et dusin små ændringer og besluttede, at det var på tide at gemme resultaterne af vores aktiviteter i depotet. En analogi kommer til at tænke på med periodisk at trykke på Ctrl+S, med den eneste forskel, at denne version af filen kan tilgås i fremtiden. Naturligvis kan du med ét hug tilføje versioner af så mange filer, du vil, til depotet. Denne handling kaldes "forpligte" eller "forpligte ændringer" på en enkel måde.
Du kan til enhver tid tilføje eller slette en ny til depotet (det er hvad depotet smart kaldes). eksisterende fil, og VCS vil "huske", hvornår og hvad vi tilføjede/slettede. Og takket være kommentarerne under commits, kan du også beskrive, hvorfor netop denne commit bliver udført ("tilføjede en kugle der"/"fjernede et muligvis nødvendigt stykke derfra").
Når vi endelig indser, at det er tid for os at vende tilbage til versionen fra en uge siden, har vi hele historien om ændringer. Og her kan vi vælge, hvad vi skal gøre. Hvis du har brug for at kopiere det nødvendige stykke fra en gammel fil og indsætte det i den aktuelle version, skal du blot udpakke det fra lageret gammel fil og kopiere, hvad der er brug for fra den. Hvis du skal rulle helt tilbage og arbejde videre med gammel version SKB kommer os til hjælp igen - du kan vende tilbage til en tidligere version og oprette en såkaldt ny filial ("filial"), mens du bibeholder alt, hvad vi "opgav" ved at rulle versionerne tilbage for en uge siden. Historien om projektversioner kan således repræsenteres grafisk som et træ - fra "rødderne" (begyndelsen af ​​projektet) til "grenene" (vellykkede og mislykkede redigeringer). Derudover kan en "gren" også oprettes kunstigt, f.eks. i det tilfælde, hvor en af ​​de kildefiler vi vil beslutte at udvikle to forskellige versioner– i den første arbejder vi på nogle kugler, i den anden arbejder vi på andre. Desuden, hvis arbejdsfilerne er tekstdokumenter (og i nogle andre), er det muligt at kombinere forskellige grene til en - den såkaldte fletning. Lad os nu forestille os, at flere mennesker arbejder på projektet, og alle arbejder på deres egen "bauble". At have et fælles lager i dette tilfælde forenkler udviklingen i høj grad.

Fra teori til praksis, eller begynder at bruge SLE

Så jeg håber, jeg har overbevist dig om, at det er en god ting at bruge SLE. Det eneste, der er tilbage, er at lære at bruge VCS. Det er, hvad vi vil gøre.
Der er forskellige versionskontrolsystemer, der adskiller sig fra hinanden i forskellige anvendelsesaspekter. Da vi ikke er interesserede (i hvert fald i starten) i arbejdets finesser forskellige systemer, lad os fokusere på de enkleste og venligste af dem. Efter min ydmyge mening er sådan et system mærkeligt nok Mercurial - "et tværplatform distribueret versionskontrolsystem designet til effektivt arbejde med meget store kodelagre" med grafisk skal SkildpaddeHg. Systemet kan bruges under Windows, Linux og Mac OS X.
Lad mig tage en reservation med det samme, som jeg vil beskrive arbejdet med systemet i Windows. For dem, der har mestret Linux, vil det ikke være svært at lære alt analogt.
Derudover vil vi samtidig lære at arbejde med den gratis hosting af Mercurial repositories - bitbucket.org, hvilket er nødvendigt, hvis du ikke arbejder på et projekt alene eller, hvilket er meget praktisk, du vil have adgang til alle versioner af projektet via internettet. Grundlæggende er det en praktisk dropbox-erstatning, hvis du har brugt den før.
Først skal du installere Mercurial + TortoiseHg herfra: tortoisehg.bitbucket.org.
Dette system fungerer i konsollen, så for at lette brugen senere vil vi skrive flere *.bat filer til typiske operationer.
Alle handlinger udføres af hg-kommandoen. Kaldet uden parametre viser den en liste over grundlæggende kommandoer.
Depotet er enhver mappe, vi vælger (jeg vil bruge mappen "C:\project\"), hvori alle filerne i vores fremtidige projekt skal gemmes. Selvfølgelig er der ingen, der forbyder at have flere depoter på én computer.
For at systemet skal "forstå", at vi vil oprette et lager, kører vi kommandoen:
hg init c:\project
hvorefter mappen "c:\project\" oprettes, hvis den ikke er oprettet tidligere, og mappen "c:\project\.hg\", hvor Mercurial gemmer alle serviceoplysninger.
Vi husker straks, at vi ikke kun vil have et lokalt lager på vores computer, men også et fjernlager, hvortil vi vil sende alle vores ændringer (eller, som de kloge fyre siger, "skubbe" ændringer til et fjernlager, fra engelsk "push"). For at gøre dette skal du gå til bitbucket.org, registrere dig og oprette dit første depot (Repositories - Opret nyt depot). Giv lageret et navn (jeg vil kalde det remote_project for at være specifik) og klik på Opret lager.
Nu har vi to arkiver - et lokalt, placeret i mappen "c:\project\" og et eksternt, placeret på "bitbucket.org/dit_kontonavn/remote_project/", hvor dit_kontonavn er det navn, der blev angivet ved registrering på bitbucket, remote_project er navnet på lageret, valgt da det blev oprettet.
For at fortsætte med at udforske er vi nødt til at skubbe noget ind i vores lokale depot. Bare opret i det (i mit tilfælde i mappen "c:\project\") enhver fil af dit fremtidige projekt eller kopier dit nuværende projekt der.
Nu skal vi strengt taget fortælle Mercurial: "vi tilføjede sådanne og sådanne filer og et par nye mapper til projektmappen", kommandoen "hg add" er tilvejebragt til dette. En anden tilgang er dog mere praktisk - ved næste commit vil vi bede Mercurial om at hente alle de nyoprettede filer fra projektmappen og glemme alt om de slettede, dette er meget nemmere end at gøre "hg add c:\project\new_document .doc" hver gang du opretter et nyt dokument"
Så lad os gå videre til vores første forpligtelse. Det udføres med følgende kommando:
hg commit –A –m “kommentere at begå”
Lad os se på alt i rækkefølge. Kommandoen skal indtastes, når vi er i repository (det vil sige, at vi først skal udføre “cd c:\project”). "-A"-indstillingen er nødvendig for, at Mercurial kan "hente" nyoprettede filer (se ovenfor), "-m"-indstillingen giver dig mulighed for at tilføje en kommentar til forpligtelsen. Disse kommentarer vil blive vist, når du ser versioner (eller ændringssæt - lister over ændringer) i TortoiseHg og på projektsiden i bitbucket.org. Det er meget vigtigt at give meningsfulde kommentarer for ikke at lide senere, og huske hvornår denne eller hin redigering blev foretaget.
Nu er vores depotbutikker oprindelige version vores projekt. Alle yderligere commits udføres på samme måde, efter vi har besluttet, at det er tid til at gemme den aktuelle version.
Den afsluttede commit kan "skubbes" ind i fjernlageret med kommandoen:
hg push https://bitbucket.org/dit_konto_navn/remote_project
I dette tilfælde skal du også være i den mappe, der svarer til depotet. Efter at have indtastet kommandoen, vil du blive bedt om navn og adgangskode til vores konto på bitbucket.org, for ikke at indtaste dem med hvert tryk, kan kommandoen erstattes med følgende:
hg push hg push https://din_konto_navn:[email protected]/dit_konto_navn/remote_project
Da vi vil skrive alle kommandoerne ind i en *.bat fil, vil adgangskoden i dette tilfælde blive gemt i åben form, hvilket er lidt af en sikkerhedsrisiko, men er acceptabelt for mig.
Så for nemheds skyld opretter vi commit.bat, push.bat og commit&push.bat filer i området med direkte rækkevidde med følgende indhold:
[indhold af commit.bat fil]
HVIS !%1==! gå til udgang 1
cd C:\projekt
hg commit -A -m "%*"
gå til exit0
: exit1
ekko "INGEN KOMMANDO-LINE ARG!"
: exit0
Denne fil, kaldet med argumenter, vil forpligte projektet med de argumenter, der er inkluderet i kommentarerne til forpligtelsen. Eksempel: udfør “commit.bat my first commit” og få commit med kommentaren “my first commit”. I FAR er det praktisk at bruge kombinationen Ctrl+Enter til dette.
[indhold af push.bat fil]
cd C:\projekt
hg push https://din_konto_navn:[email protected]/dit_konto_navn/remote_project
Denne fil vil skubbe til fjernlageret.
[indhold af fil commit&push.bat]
HVIS !%1==! gå til udgang 1
cd C:\projekt
hg commit -A -m "%*"
gå til exit0
: exit1
ekko "INGEN KOMMANDO-LINE ARG!"
: exit0
ring til ./push.bat
Denne fil, kaldet med argumenter, vil udføre sekventiel commit og push af projektet med de argumenter, der er indtastet i kommentarerne til commit.
For små mellemliggende commits anbefaler jeg desuden at oprette en commit_date_time.bat-fil:
[indhold af filen commit_date_time.bat]
cd C:\projekt
hg commit -A -m "%DATE% %TIME%"
Denne fil vil forpligte sig med den aktuelle dato og klokkeslæt som en kommentar, hvilket ofte er praktisk.
Alle beslutter sig for hyppigheden af ​​commits og pusher individuelt, afhængigt af intensiteten og kompleksiteten af ​​de ændringer, der foretages. Selvom det anbefales at følge reglen "oftere er bedre."
Ved at højreklikke på arkivfilen/mappen kan du starte Repository Explorer (TortoiseHg - Repository Explorer), som præsenterer alle vores commits med kommentarer til dem. Dette vindue viser træstrukturen af ​​vores lager, herfra kan du udføre commits, push, rollbacks til tidligere versioner (backouts) og andre operationer.
På bitbucket.org/your_account_name/remote_project er der et lignende sæt ændringssæt, og du kan downloade enhver version af projektet i ét arkiv, hvilket nogle gange også er meget praktisk.
Generelt betragter jeg dette som afslutningen på mit første bekendtskab med Mercurial. For mere detaljeret information kan tilgås på: translated.by/you/mercurial-the-definitive-guide/into-ru/trans/

Hvem er denne artikel til?

Jeg skal nok slutte med det, jeg skulle have startet med - hvem er denne artikel til? Svaret er enkelt - for dem, der ønsker at lære at bruge hård valuta. Det lykkedes mig at få flere designere, ingeniører og endda en forfatter til at blive hooked på VCS. Prøv det også - det vil sandsynligvis gøre dit arbejde meget lettere.

P.S. Flyttet til bloggen "Version Control Systems".

Tags: Tilføj tags

Versionsstyringssystem

Versionsstyringssystem(fra engelsk Versionskontrolsystem, VCS eller Revision Control System) - software til at lette arbejdet med at ændre 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, bestemme, hvem der har foretaget en bestemt ændring og hvornår, og meget mere.

Sådanne systemer er mest udbredt i softwareudvikling til lagring af kildekoderne for det program, der udvikles. De kan dog med succes anvendes på andre områder, hvor der arbejdes med et stort antal løbende skiftende elektroniske dokumenter. Især versionskontrolsystemer bruges i CAD, normalt som en del af produktdatastyringssystemer (PDM). Versionering bruges i konfigurationsstyringsværktøjer ( Softwarekonfigurationsstyringsværktøjer).

Ved afgørelsen af, om det er tilladt at sammenlægge ændringer inden for samme tekstfil en typisk mekanisme til linje-for-linje sammenligning af tekstværker (et eksempel på dens implementering er systemværktøj GNU diff), som sammenligner de flettede versioner med basisversionen og opbygger en liste over ændringer, det vil sige rækkesæt tilføjet, fjernet og erstattet. Minimum enhed Dataene for denne algoritme er en streng; selv den mindste forskel gør strengene anderledes. I betragtning af at afgrænsningstegn i de fleste tilfælde ikke bærer nogen semantisk belastning, kan flettemekanismen ignorere disse tegn ved sammenligning af strenge.

De sæt af ændrede strenge fundet, som 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.

Konflikter og deres løsning

Situationen, når de ændringer, der er foretaget i dem, krydser hinanden ved sammenlægning af flere versioner, kaldes 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. Nogle systemer (f.eks. Subversion) forsøger ikke engang at løse konflikter på commit- eller branch-trunk-stadiet; Hvis sådanne konflikter opstår, annulleres handlingen fuldstændigt, og udvikleren bliver bedt om at udføre opdateringen først arbejdskopi(selvfølgelig vil de samme konflikter opstå), løs konflikterne, og først derefter flette dine ændringer ind i basisgrenen.

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 at flette ændringer (i dette tilfælde vises de flettede muligheder og den kombinerede version af filen, der dynamisk ændrer sig afhængigt af brugerens kommandoer), eller de er simpelthen markeret med speciel markup direkte i teksten i den flettede fil (så skal udvikleren selv generere den ønskede tekst i omstridte områder og bevare den).

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.

Låse

Låsemekanismen giver en af ​​udviklerne mulighed for udelukkende at bruge en fil eller en gruppe af filer for at foretage ændringer i dem. 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. Typisk for moderne systemer er følgende mekanisme.

Den massive brug af låse, når alle eller de fleste af filerne i et projekt er låsbare, og for eventuelle ændringer er det nødvendigt at låse det tilsvarende sæt filer, kaldes også strategien "låst kasse". Tidlige versionskontrolsystemer understøttede udelukkende denne strategi og forhindrede dermed konflikter i at opstå i første omgang. I moderne VCS foretrækkes brugen af ​​ikke-blokerende hentning, mens blokering betragtes som mere et nødvendigt onde, der bør begrænses, når det er muligt. Ulemperne ved at bruge låse er indlysende:

  • Blokering er bare i vejen produktivt arbejde, da de tvinger dig til at vente på frigivelsen af ​​låste filer, selvom i de fleste tilfælde selv fælles ændringer af de samme filer, der er lavet i løbet af arbejdet med forskellige betydninger, ikke krydser hinanden og kombineres automatisk, når de flettes.
  • Hyppigheden af ​​konflikter og kompleksiteten af ​​deres løsning er i de fleste tilfælde ikke så stor, at de skaber alvorlige vanskeligheder. Fremkomsten af ​​en alvorlig konflikt af ændringer signalerer oftest enten en betydelig meningsforskel forskellige udviklere vedrørende udformningen af ​​det samme fragment, eller om forkert organisering af arbejdet (når to eller flere udviklere gør det samme).
  • Blokeringer skaber administrative problemer. Et typisk eksempel: en udvikler kan glemme at låse op for filer, han har travlt med, mens han tager på ferie. For tilladelse lignende problemer det er nødvendigt at anvende administrative foranstaltninger, herunder også i systemet tekniske midler at nulstille forkerte låse, men selvom de findes, går der tid med at sætte systemet i stand.

På den anden side er brugen af ​​låse i nogle tilfælde ganske berettiget. Et oplagt eksempel er tilrettelæggelsen af ​​arbejdet med binære filer, hvor der ikke er nogen værktøjer til at flette ændringer eller en sådan fletning er fundamentalt umulig (som f.eks. for billedfiler). Hvis automatisk fletning ikke er mulig, vil eventuelle parallelle ændringer af lignende filer under normale driftsforhold føre til en konflikt. I I dette tilfælde Det er meget mere bekvemt at gøre en sådan fil låsbar for at sikre, at eventuelle ændringer af den kun vil blive foretaget sekventielt.

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 versionering filer. Det betyder, at enhver fil, der vises i projektet, modtager eget nummer version (normalt nummer 1, den betingede "nul" version af filen anses for at være en tom fil med samme navn). Hver gang 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. Da commits typisk kun påvirker en del af filerne i depotet, afviger versionsnumrene for filer, der er tilgængelige på samme tidspunkt, over tid, og projektet som helhed (det vil sige hele sættet af filer i depotet) gør det. faktisk ikke have noget "versionsnummer", fordi det består af mange filer med forskellige versionsnumre. For eksempel fungerer CVS versionskontrolsystemet på lignende måde.

For andre systemer refererer begrebet "version" ikke til en individuel fil, men til depot helt. Et nyoprettet tomt lager har version 1 eller 0, enhver commitment af ændringer fører til en stigning i dette antal (det vil sige, selvom en fil ændres med en byte, betragtes hele depotet som ændret og modtager nyt nummer versioner). Sådan fortolkes versionsnumre for eksempel af Subversion-systemet. Versionsnummeret for en individuel fil her eksisterer faktisk ikke; vi kan betinget betragte det nuværende versionsnummer af depotet for at være et sådant (det vil sige, antag, at med hver ændring, der foretages i depotet, ændrer alle dets filer versionen nummer, også dem, der ikke er ændret). Nogle gange, når man taler om en "filversion" i sådanne systemer, mener de den version af depotet, hvor filen var sidste gang(indtil det øjeblik, vi er interesseret i) ændret.

Af praktiske årsager er det normalt ikke den enkelte fil, der betyder noget, men hele projektet. I systemer, der understøtter versionering af individuelle filer, kan dato og klokkeslæt bruges til at identificere en specifik version af projektet - så vil projektversionen bestå af de versioner af de filer, der er inkluderet i det, som var i depotet på det angivne tidspunkt . Hvis versionering af depotet som helhed er understøttet, kan projektets versionsnummer være lagerets versionsnummer. Begge muligheder er dog ikke særlig bekvemme, da hverken datoen eller versionsnummeret på depotet normalt indeholder oplysninger om væsentlige ændringer i projektet, om hvor længe og intensivt de arbejdede på det. For mere bekvemt at markere versioner af et projekt (eller dets dele), understøtter versionskontrolsystemer konceptet tags.

Tag er en symbolsk etiket, der kan knyttes til en specifik version af en fil og/eller et bibliotek i depotet. Ved at bruge den relevante kommando, alle eller en del af projektfilerne, der opfylder visse betingelser (f.eks. inkluderet i hovedversionen af ​​projektets hovedgren på bestemt øjeblik tid) kan tildeles en specificeret etiket. På denne måde kan du identificere versionen af ​​projektet (version "XX.XXX.XXX" er et sæt versioner af lagerfiler med tagget "XX.XXX.XXX"), og dermed fikse dets 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" af enhver tilfældigt. Fra en systembrugers perspektiv kan tagging se anderledes ud. I nogle systemer er det afbildet præcist som et mærke (et tag kan oprettes, påføres bestemte versioner af filer og mapper eller fjernes). I andre systemer (f.eks. Subversion) er et tag simpelthen en separat mappe i depotfiltræet, hvor der laves kopier fra stammen og grene af projektet ved hjælp af kopieringskommandoen nødvendige versioner filer. Så visuelt er et tag simpelthen en kopi af visse versioner af depotfilerne placeret i en separat mappe. Ifølge konventionen har bibliotekstræet, der svarer til et tag, ikke lov til at foretage ændringer (det vil sige, at den version af projektet, der repræsenteres af tagget, er uforanderlig).

Grundlæggende principper for softwareudvikling i VCS

Sådan bruger du versionskontrol i hver konkret sag bestemt af tekniske forskrifter og regler vedtaget af den specifikke virksomhed eller organisation, der udvikler projektet. Alligevel, generelle principper korrekt brug VCS er få og ensartede for alle udviklings- og versionskontrolsystemer.

  1. Alle arbejds-, test- eller demoversioner af projektet indsamles kun fra systemlageret. "Personlige" builds, som inkluderer ændringer, der endnu ikke er blevet forpligtet, kan kun udføres af udviklere til midlertidige testformål. Dette sikrer, at depotet indeholder alt det nødvendige for at skabe en fungerende version af projektet.
  2. Den aktuelle version af mastergrenen er altid korrekt. Det er ikke tilladt at binde sig til hovedgrenen ufuldstændig eller ikke bestået i det mindste foreløbig testændringer. Til enhver tid udføres projektsamlingen fra nuværende version, burde lykkes.
  3. Enhver væsentlig ændring skal dokumenteres som en særskilt gren. Foreløbige resultater af udviklerens arbejde registreres i denne gren. Når ændringen er gennemført, er grenen slået sammen med stammen. Undtagelser er kun tilladt for mindre ændringer, hvor arbejdet udføres af en udvikler inden for højst en arbejdsdag.
  4. Projektversioner er markeret med tags. Den fremhævede og taggede version ændres aldrig igen.

Distribuerede versionskontrolsystemer

afdeling En gren er en udviklingsretning, der er uafhængig af andre. En filial er en kopi af en del (normalt én mappe) af lageret, som du kan foretage dine egne ændringer til uden at påvirke andre filialer. Dokumenter i forskellige afdelinger har den samme historie før forgreningspunktet og forskellige efter det. ændringssæt, aktivitet Sæt af ændringer. Repræsenterer et navngivet sæt redigeringer, der er lavet til en lokal kopi til et fælles formål. I systemer, der understøtter redigeringssæt, kan udvikleren gruppere lokale redigeringer og foretage logisk relaterede ændringer med en enkelt kommando, og angive det nødvendige redigeringssæt som en parameter. Andre redigeringer vil dog forblive ufixede. Et typisk eksempel: arbejdet er i gang med at tilføje ny funktionalitet, og i dette øjeblik er det opdaget kritisk fejl som skal rettes med det samme. Udvikleren opretter et ændringssæt til allerede udført arbejde og et nyt sæt til rettelser. Efter fuldførelse af fejlkorrektionen gives en kommando om kun at udføre det andet sæt redigeringer. check-in, begå, Indsend Opretter en ny version, begår ændringer. Udbred ændringer foretaget i arbejdskopien til dokumentlageret. Samtidig oprettes en ny version af de ændrede dokumenter i depotet. check-out, klon Hentning af et dokument fra lageret og oprettelse af en arbejdskopi. konflikt En konflikt er en situation, hvor flere brugere har foretaget ændringer i den samme del af et dokument. En konflikt detekteres, når en bruger begår sine ændringer, og den anden forsøger at begå dem, og systemet selv kan ikke korrekt flette de modstridende ændringer. Da programmet måske ikke er intelligent nok til at afgøre, hvilken ændring der er "korrekt", skal den anden bruger selv løse konflikten ( beslutte). hoved Hovedversionen er den mest nyeste version for en filial/stamme placeret på lager. Der er lige så mange hovedversioner, som der er grene. fusionere, integration Flet - kombinerer uafhængige ændringer til en enkelt version af et dokument. Opstår, når to personer har ændret den samme fil, eller når der skubbes ændringer fra en gren til en anden. rebase Flytning af grenpunktet (den version, hvorfra grenen begynder) til en senere version af hovedgrenen. For eksempel, efter udgivelsen af ​​version 1.0 af et projekt, fortsætter forbedringer i trunk (fejlrettelser, forbedringer af eksisterende funktionalitet), og samtidig begynder arbejdet med ny funktionalitet i en ny gren. Efter noget tid frigives version 1.1 (med rettelser) i hovedgrenen; Det er nu ønskeligt, at udviklingsgrenen af ​​ny funktionalitet inkluderer de ændringer, der er sket i stammen. Generelt kan dette gøres ved hjælp af grundlæggende værktøjer, ved at bruge flette, vælge et sæt ændringer mellem version 1.0 og 1.1 og flette det til en gren. Men hvis systemet understøtter branch rebasing, udføres denne operation nemmere med én kommando: ved at bruge rebase-kommandoen (med parametre: branch og new grundlæggende version) Systemet bestemmer uafhængigt de nødvendige sæt ændringer og sammenlægger dem, hvorefter version 1.1 bliver basisversionen for grenen; Når en filial efterfølgende bliver flettet ind i stammen, genovervejer systemet ikke ændringer foretaget mellem version 1.0 og 1.1, da filialen logisk anses for at være allokeret efter version 1.1. depot, depot Dokumentlagring er et sted, hvor versionskontrolsystemet gemmer alle dokumenter sammen med deres ændringshistorik og andre serviceoplysninger. revision Dokumentversion. Versionskontrolsystemer skelner versioner ved numre, der tildeles automatisk. reoler Udsættelse af ændringer. Nogle systemer giver mulighed for at oprette et ændringssæt og gemme det på serveren uden at begå det. Et udskudt sæt ændringer er tilgængeligt for læsning af andre projektdeltagere, men før særligt hold er ikke en del af hovedgrenen. Understøttelse af udsættelse af ændringer giver brugerne mulighed for at gemme ufærdigt arbejde på serveren uden at oprette separate grene til dette. tag, etiket En etiket, der kan tildeles en specifik version af et dokument. En etiket er et symbolsk navn for en gruppe af dokumenter, hvor etiketten ikke kun beskriver et sæt filnavne, men også versionen af ​​hver fil. Versioner af dokumenter inkluderet i tagget kan tilhøre forskellige tidspunkter. bagagerum, hovedlinje, mestre Stammen er hovedgrenen af ​​projektudvikling. Trunkpolitikken kan variere fra projekt til projekt, men generelt er det som følger: De fleste ændringer foretages på stammen; hvis der kræves en større ændring, der kan føre til ustabilitet, skabes en gren, der går sammen med stammen, når innovationen er tilstrækkeligt afprøvet; Før udgivelsen af ​​den næste version oprettes en "release"-gren, hvori der kun foretages rettelser. opdatering, synkronisere Synkronisering af arbejdskopien til en bestemt lagringstilstand. Oftest betyder denne handling at opdatere arbejdskopien til den seneste tilstand af lageret. Om nødvendigt kan du dog synkronisere arbejdskopien til en ældre tilstand end den nuværende. arbejdskopi Arbejds (lokal) kopi af dokumenter.

se også

  • Konfigurationsstyring (Software Configuration Management), konfigurationsstyringsværktøjer (Software Configuration Management Tools)
  • Softwareprodukter med gennemsigtig versionskontrol
    • Nogle implementeringer

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 tidligere version projekt og se, hvad der ændrede sig, dette reddede 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. Et fremragende 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 kommandant eller sådan noget, så skal du klikke Højreklik mus og vælg:


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 til kommandolinje thg, for explorer-lignende filhåndteringer skal du 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:

Versionskontrolsystem ( Versionskontrolsystem, VCS) er software, der giver dig mulighed for at spore ændringer i dokumenter, rulle dem tilbage om nødvendigt, bestemme, hvem der har foretaget rettelserne og hvornår osv. Artiklen diskuterer typerne VCS, principper for deres drift, samt eksempler software produkter.

Hvad er et versionskontrolsystem?

Sandsynligvis er alle bekendt med situationen, når der, når der arbejdes på et projekt, er behov for at foretage ændringer, men samtidig skal du gemme en brugbar version, i dette tilfælde oprettes der som regel en ny mappe, hvis navn højst sandsynligt vil være "Ny mappe" med tilføjelse af en dato eller en lille note, kopieres den ind i fungerende version projekt, og arbejdet er allerede i gang med det. Over tid kan antallet af sådanne mapper stige betydeligt, hvilket skaber vanskeligheder med at rulle tilbage til tidligere versioner, spore ændringer osv. Denne situation bliver meget værre, når der er flere mennesker, der arbejder på et projekt.

For at løse sådanne problemer bruges et versionskontrolsystem, som giver dig mulighed for komfortabelt at arbejde på et projekt både individuelt og i et team. VCS sporer ændringer i filer, giver mulighed for at oprette nye og flette eksisterende grene af projektet, kontrollerer brugeradgang til projektet, giver dig mulighed for at rulle rettelser tilbage og bestemme, hvem, hvornår og hvilke ændringer der blev foretaget i projektet. Hovedkonceptet VCS er depotet ( depot) – et særligt lager af projektfiler og mapper, hvor ændringer spores. Udvikleren har til sin rådighed en såkaldt "arbejdskopi" ( arbejdskopi) af det projekt, han arbejder direkte med. Arbejdskopien skal periodisk synkroniseres med lageret; denne operation involverer at sende ændringer, som brugeren har foretaget i sin arbejdskopi til det (denne handling kaldes begå) og opdatering af arbejdskopien, hvor den seneste version fra lageret downloades til brugeren (denne proces kaldes opdatering).

Centraliserede og distribuerede versionskontrolsystemer

Versionskontrolsystemer kan opdeles i to grupper: distribueret og centraliseret.

Centraliserede versionskontrolsystemer

CentraliseretVersionskontrolsystemer er klient-server-applikationer, hvor projektlageret eksisterer i en enkelt kopi og er gemt på serveren. Den blev tilgået gennem en speciel klientapplikation.Eksempler på sådanne softwareprodukter omfatter: CVS, Subversion.

CVS (System med samtidige versioner, Systemet med simultane versioner) er et af de første systemer, der blev udbredt blandt udviklere; det opstod i slutningen af ​​80'erne af forrige århundrede. I øjeblikket er dette produkt ikke under udvikling, dette skyldes primært en række centrale svagheder, såsom manglende evne til at omdøbe filer, ineffektiv lagring og næsten fuldstændig mangel på integritetskontrol.

Subversion (SVN) – versionskontrolsystem oprettet til at erstatte CVS. SVN blev udviklet i 2004 og er stadig i brug i dag. På trods af mange fordele ift CVS på SVN Alligevel er der ulemper, såsom problemer med at omdøbe, manglende mulighed for at slette data fra depotet, problemer med driften af ​​sammenlægning af filialer mv. Generelt SVN var (og er fortsat) et væsentligt fremskridt i forhold til CVS.

Distribuerede versionskontrolsystemer

Distribuerede versionskontrolsystemer ( Distribueret versionskontrolsystem, DVCS) giver dig mulighed for at gemme et lager (en kopi af det) for hver udvikler, der arbejder med dette system. I dette tilfælde kan du vælge et centralt arkiv (betinget), hvortil ændringer fra lokale vil blive sendt, og med det vil disse lokale arkiver blive synkroniseret. Når man arbejder med et sådant system, synkroniserer brugere med jævne mellemrum deres lokale depoter med det centrale og arbejder direkte med deres lokale kopi. Efter at have foretaget nok ændringer i den lokale kopi, sendes de (ændringerne) til serveren. I dette tilfælde vælges serveren oftest betinget, fordi i de fleste DVCS der er ikke sådan noget som en "dedikeret server med et centralt lager."

Den store fordel ved denne tilgang er udviklerens autonomi, når de arbejder på projektet, fleksibilitet fælles system og øget pålidelighed ved at sikre, at hver udvikler har en lokal kopi af det centrale lager. De to mest kendte DVCS- Det her Git Og Mercurial.

Lad os starte med Mercurial, dette system er en gratis DVCS, som er opbygget sådan, at der ikke er et koncept om et centralt depot til at arbejde med dette VCS et konsolværktøj bruges (normalt) hg. Mercurial har alle mulighederne for et versionskontrolsystem, såsom forgrening, fletning, synkronisering med andre lagre. Dette projekt brug og støtte et stort antal af store udviklere, blandt dem Mozilla, OpenOffice, OpenJDK og mange andre. Selve produktet er skrevet ind Python og er tilgængelig på de fleste moderne operativsystemer ( Windows, MacOS, Linux), er der også et betydeligt antal forsyningsselskaber med grafisk grænseflade at arbejde med Mercurial. Hovedkonkurrent Mercurial På markedet distribuerede systemer versionskontrol er Git, der til dato har vundet lederkapløbet.

Git– distribueret versionskontrolsystem udviklet af Linus Torvalds til arbejde med operativsystemkernen Linux. Blandt større projekter, hvori det bruges git, kan vi vælge kernen Linux, Qt, Android. Git gratis og distribueret under licens GNU GPL 2 og samt Mercurial, tilgængelig på næsten alle operativsystemer. Ifølge deres egne grundlæggende evner git svarende til Mercurial(og andre DVCS), men takket være en række fordele (høj hastighed, evne til at integrere med andre VCS, brugervenlig grænseflade) og det meget aktive samfund, der har dannet sig omkring dette system, git blev markedsleder inden for distribuerede versionskontrolsystemer.Det skal bemærkes, at på trods af den store popularitet af sådanne systemer som git, store virksomheder, lignende Google, bruge deres VCS.

Dette var et introduktionsforedrag om versionskontrolsystemer. I det følgende vil al præsentation kun vedrøre git.

Hvis du foretrækker det lære af videoforelæsninger, så anbefaler vi et godt kursus på git fra GeekBrains , gå til link og find kurset i afsnittet "Kurser". “Git. Hurtig start". Han gratis, du skal blot registrere dig på siden. Vi anbefaler, at du ser nærmere på denne ressource; der er meget mere interessant på den!

Hvad er versionskontrol, og hvorfor har du brug for det? Et versionskontrolsystem (VCS) er et system, der registrerer ændringer i en eller flere filer, så det i fremtiden er muligt at vende tilbage til visse ældre versioner af disse filer. Vi vil bruge kildekode til eksemplerne i denne bog, men i virkeligheden kan du sætte næsten enhver type fil 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

Mange mennesker foretrækker at kontrollere versioner ved blot at kopiere filer til en anden mappe (normalt tilføje 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 lokale VCS'er med en simpel database, hvor alle ændringer er gemt nødvendige filer(Se figur 1-1).

Figur 1-1. Ordning for lokal SLE.

En af de mest populære VCS'er af denne type er rcs, som stadig er installeret på mange computere. Selv på en moderne operationsstue Mac system OS X rcs-værktøjet er installeret sammen med udviklerværktøjer. Dette værktøj er baseret på at arbejde med sæt af patches mellem par af versioner (en patch er en fil, der beskriver forskellen mellem filer), som er gemt i et specielt format på disken. Dette giver dig mulighed for at genskabe enhver fil på et hvilket som helst tidspunkt og anvende patches sekventielt.

Centraliserede versionskontrolsystemer

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


Figur 1-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. 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 arbejdsversioner gemt på brugernes arbejdsmaskiner. Lokale systemer Versionskontrolsystemer er underlagt det samme problem: Hvis hele historikken for et projekt er gemt ét sted, risikerer du at miste alt.

Distribuerede versionskontrolsystemer

Og i denne situation kommer distribuerede versionskontrolsystemer (DVCS) i spil. I systemer som Git, Mercurial, Bazaar eller Darcs uploader klienter ikke bare seneste versioner filer, men kopiere hele depotet fuldstændigt. 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 klienten tjekker den seneste version af filerne, opretter den en komplet kopi af alle data til sig selv (se figur 1-3).


Figur 1-3. Diagram over et distribueret versionskontrolsystem.

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.