| subversion | |
|---|---|
| Type | centraliseret versionskontrolsystem [d] , Apache Foundation-projekt [d] ogopen source-software |
| Forfatter | CollabNet [d] |
| Udvikler | Apache Software Foundation |
| Skrevet i | C [4] [5] , Python [4] , C++ [6] [7] og Java [6] [7] |
| Operativ system | GNU/Linux [8] , Microsoft Windows [8] , macOS [8] og BSD [8] |
| Første udgave | 20. oktober 2000 [1] |
| nyeste version | |
| Læsbare filformater | SVN dump format (v1) [d] , SVN dump format (v2) [d] , SVN dump format (v3) [d] og SVN dump format (generisk) [d] |
| Genererede filformater | SVN dump format (v1) [d] , SVN dump format (v2) [d] , SVN dump format (v3) [d] og SVN dump format (generisk) [d] |
| Licens | Apache-licens 2.0 [9] |
| Internet side | subversion.apache.org _ |
| Mediefiler på Wikimedia Commons | |
Subversion [10] (også kendt som " SVN " [11] ) er et gratis centraliseret versionskontrolsystem, officielt udgivet i 2004 af CollabNet . Siden 2010 har Subversion været et projekt under Apache Software Foundation og hedder officielt Apache Subversion (registreret varemærke [12] ).
Målet med projektet i begyndelsen af udviklingen var at erstatte [13] [14] det dengang udbredte Concurrent Versions System (CVS), som nu anses for at være forældet [15] [16] [17] . Subversion implementerer alle hovedfunktionerne i CVS og er fri for nogle af sidstnævntes mangler.
Subversion bruges stadig af nogle open source -fællesskaber (inklusive dem, der brugte CVS før ), men næsten alle større projekter er flyttet til DVCS . Blandt de sidste brugere af Subversion blandt åbne projekter er FreeBSD , men de annoncerede også en overgang til Git [18] , og for eksempel Free Pascal . Subversion er blevet brugt i ret lang tid af så velkendte projekter som Apache , GCC , FFmpeg , LLVM . Subversion bruges også i private projekter og i erhvervslivet, men det er svært at måle, hvor bredt. Subversion- hosting , herunder til open source-projekter, leveres også af populære hostingprojekter SourceForge.net , Tigris.org , Google Code og BountySource .
I 2007 vurderede Forrester , et analysefirma , Subversion som "den eneste førende i kategorien Standalone Software Configuration Management (SCM) og en stærk bidragyder i kategorien Software Configuration and Change Management (SCCM)" , når man sammenlignede fordele og ulemper ved forskellige systemer . [19]
Ifølge statistikker om brugen af Linux -pakker - Debian [20] og Ubuntu [21] distributioner toppede antallet af aktive brugere af Subversion omkring 2010 og er begyndt at falde siden 2016. Der er dog stadig flere projekter, der bruger Subversion end ved hjælp af CVS , Mercurial og Bazaar (fra august 2019 ).
Den officielle dokumentation er placeret [22] af bogen udgivet af O'Reilly Media , som er frit tilgængelig [23] og tilføjet af forfatterne efterhånden som nye versioner af SVN udgives. Den udgiver også sine oversættelser til en række sprog, herunder russisk, men på trods af at de engelske versioner af bogen nu beskriver version 1.8 og 1.7, er der kun bøger på russisk, der beskriver versioner op til 1.4 inklusive [24] .
Udviklingen af Subversion begyndte i 2000 på initiativ og med økonomisk støtte fra CollabNet. Initiativtagerne til projektet ønskede at skabe et gratis versionskontrolsystem, der grundlæggende ligner CVS, men uden dets fejl og besvær . På det tidspunkt var der ingen bedste programmer i denne klasse med en gratis licens, CVS var de facto standarden blandt gratis softwareudviklere. Ved at vælge det som en baseline håbede Subversion-udviklerne at forenkle udviklingen ved at udnytte allerede gennemprøvede koncepter, samtidig med at det blev lettere for mange CVS-brugere at migrere til det nye system. [25]
Store begivenheder i Subversions udviklingshistorie.
Subversion er et centraliseret system (i modsætning til distribuerede systemer som Git eller Mercurial ), hvilket betyder, at data gemmes i et enkelt lager. Depotet kan være placeret på en lokal disk eller på en netværksserver .
At arbejde i Subversion er ikke meget anderledes end at arbejde i andre centraliserede versionskontrolsystemer. Klienter kopierer filer fra boksen for at oprette lokale arbejdskopier, foretager derefter ændringer i arbejdskopierne og overfører disse ændringer til boksen. Flere klienter kan få adgang til lageret på samme tid. Subversion bruger primært copy-modify-merge- modellen til at samarbejde om filer . For filer, der ikke kan flettes (forskellige binære filformater), kan du også bruge lock-modify-unlock- modellen .
Når du gemmer nye versioner, bruges delta-komprimering : systemet finder forskelle mellem den nye version og den tidligere og skriver kun dem, hvilket undgår dataduplikering.
Ved brug af WebDAV-adgang understøttes også transparent versionering - hvis en WebDAV-klient åbner for skrivning og derefter gemmer en fil, der er gemt på en netværksshare, oprettes en ny version automatisk.
Subversion tilbyder to muligheder for at organisere repositories [40] . Repositories af den første type bruges til at gemme en database baseret på Berkeley DB , repositories af den anden type er almindelige filer af et specielt format (dataadgang organiseres ved hjælp af deres egne biblioteker uden brug af tredjepartsdatabaser). Subversion-udviklerne refererer ofte til storage som et "filsystem", hvorfor den anden type kaldes FSFS, hvilket betyder et (versioneret) filsystem ( engelsk filsystem ) oven på et (almindeligt) filsystem.
Begge typer arkiver giver tilstrækkelig pålidelighed, når de er korrekt organiseret [41] (Berkeley DB bruger fillåse, så det kan ikke bruges på nogle netværksfilsystemer, der ikke understøtter låse), hver af dem har sine egne fordele og ulemper. Det menes, at FSFS er lettere at konfigurere korrekt, det kræver mindre opmærksomhed fra administratoren. Derudover kunne depoter, der bruger Berkeley DB, forud for release 1.4 under visse betingelser ende i en såkaldt wedged state ; administratorindgreb var påkrævet for at genoprette dens funktionalitet.
Fra og med version 1.2 bruges FSFS som standard til nye lager. Med udgivelse 1.8 blev brugen af Berkeley DB forældet [37] . Nye funktioner, der vil blive tilføjet i fremtidige udgivelser, virker muligvis ikke på servere, der bruger Berkeley DB. Support til Berkeley DB kan blive afbrudt i fremtiden.
Subversion giver følgende måder at få adgang til et lager:
Alle disse metoder kan bruges til at arbejde med begge typer repositories (FSFS og Berkeley DB). Forskellige metoder kan bruges på samme tid for at få adgang til det samme lager.
Fra brugerens perspektiv er Subversion-depotet et "todimensionelt" filsystem . Objekter i et lager ( filer og mapper ) er identificeret med to " koordinater ": et navn og et revisionsnummer . Med andre ord er depotet en række snapshots (revisioner) af et træ af filer og mapper, indekseret efter revisionsnummeret. Hvert sådant snapshot er et regulært (endimensionelt) filsystem.
Hvis det er nødvendigt at angive en specifik revision af et objekt, bruges en indtastning af formularen: имя@ревизияf.eks. /main.c@29 filen /main.c i revision 29. En sådan indikation af revisionen, der bruges til at tydeliggøre navnet , kaldes peg revision .
På fig. 1 viser en grafisk repræsentation af filsystemet: den lodrette akse svarer til sættet af navne, den vandrette akse svarer til sættet af revisioner.
FilnavneNavnet på et filsystemobjekt i Subversion er dannet efter de samme regler som i UNIX-lignende operativsystemer: der er kun én rodmappe, stielementer er adskilt af en skråstreg ("/"). Filsystemobjekter er filer og mapper (såvel som symbolske links , som emuleres fra almindelige filer ved at indstille attributten svn:special).
RevisionsnumreRevisionsnummeret i Subversion er et naturligt tal (eller 0 for den allerførste revision), der adresserer depotets tilstandsnummer, efterhånden som de data, det indeholder, ændres. Hver succesfuld commit genererer præcis én ny revision af repository, så den N. revision er tilstanden af repository efter N. commit.
I Subversion karakteriserer en revision ikke tilstanden for en enkelt fil, men for hele depotet som helhed. For eksempel er revision 32 (punkteret i figuren) tilstanden af fire filer og to mapper, der eksisterede i depotet på det tidspunkt.
Revisionsnummeret er analogt med tid i den forstand, at lavere revisionsnumre svarer til tidligere tilstande af depotet, og højere revisionsnumre svarer til senere.
Revisionsnummeret kan opfattes som en slags tidsstempel i depotets historie. Desuden har hvert revisionsnummer en absolut værdi forbundet med det tidspunkt, hvor revisionen blev foretaget ( egenskab svn:date ). Det er dog mere bekvemt at angive revisionsnummeret end at angive tidspunktet, da der ikke er nogen forveksling med tidszoner, nummerindtastningen er kortere, og revisionsnummeret kan ikke ændres.
Drifts- og kernerevisionerRevisionsnummeret bruges i to forskellige sammenhænge :
En revision kaldes operationel, hvis den specificerer revisionen eller rækken af revisioner, som operationen skal anvendes på , for eksempel:
svn log -r 199:230 http://some.pathI dette eksempel udføres kommandoen svn logfor en række revisioner 199:230, som er rækken af onlinerevisioner .
Angivelse af kun filnavnet og onlinerevision kan dog nogle gange tvetydigt pege på depotobjekterne. For eksempel i situationen vist i fig. 2, er der en tvetydighed, når du kører følgende kommando:
svn log -r 29:33 http://some.path/bar.txtKommandoen specificerer en række online-revisioner ( 29:33), men de områder, der er fremhævet med blåt og grønt i figuren, kan ligeledes betragtes som historien for filen /bar.txti revisionsområdet 29:33. I sådanne tilfælde er det også nødvendigt at specificere pivotrevisionen for at løse tvetydigheden. Kernerevisionen er det revisionsnummer, der er angivet ud over URL'en for filsystemobjektet (ved brug af " URL@ревизия"-notationen). Navnet kommer fra det engelske ord peg , som kan oversættes til "stang" eller "peg". Pivotrevisionen markerer kæden af tilstande, som det angivne par tilhører URL@ревизия, og identificerer således entydigt det repository-objekt, som kommandoen skal anvendes til. I eksemplet nedenfor vil den første kommando udskrive historien fremhævet med blåt i figuren, og den anden kommando vil udskrive historien fremhævet med grønt:
svn log -r 29:33 http://some.path/file.txt@32 svn log -r 29:33 http://some.path/bar.txt@34Den seneste tilstand for genstanden af interesse bør angives som kernerevisionen. Grunden til dette er, at statskæden er entydigt sporet "tilbage", men ikke "frem". For eksempel hører URL'en med pivotrevisionen http://some.path/foo.txt@31 til to tilstandskæder (fremhævet med henholdsvis grønt og gråt). Af disse to kæder adresserer den angivne URL den grå kæde, det vil sige, at når man bevæger sig "frem" fra kernerevisionen, ignoreres kopioperationer.
Operationer på filsystemetFølgende operationer kan udføres på filsystemobjekter i Subversion-depotet [42] (se figur 1). Klammerne angiver den korte navngivning af operationen i notationen af kommandoen svn status.
En arbejdskopi er en lokal kopi af et stykke data fra depotet, der er oprettet af Subversion-klientprogrammet, der udover selve dataene indeholder nogle serviceoplysninger (skjulte mapper med navnet .svn). Serviceoplysningerne er nødvendige for, at arbejdskopien fungerer korrekt; intet kan ændres i servicedataene. Den mindste enhed af data, der kan hentes fra et lager som en arbejdskopi, er en mappe. Indholdet af en mappe kan muligvis ikke udpakkes fuldstændigt: for eksempel kan individuelle filer eller undermapper udelukkes. Det er dog ikke muligt at tjekke en enkelt fil fra boksen som en arbejdskopi.
Enhver undermappe til en Subversion 1.6 og tidligere arbejdskopi er også en fuld arbejdskopi, fordi hver mappe indeholder dens husholdningsdata (mapper .svn). Siden version 1.7 har hver arbejdskopi kun én mappe .svni roden af dens mappe.
Arbejdskopien er selvstændig i den forstand, at Subversion ikke gemmer nogen data relateret til arbejdskopien uden for den. Hvis du har én arbejdskopi, kan du derfor lave flere kopier ved simpel kopiering uden at bruge netværkstrafik.
I arbejdskopiens servicemapper gemmes blandt andet den såkaldte rene kopi ( eng. pristine copy ) - arbejdskopiens filer i umodificeret form, som de blev udtrukket fra depotet (for svn er dette en revision ved navn BASE). At have en ren kopi giver dig mulighed for hurtigt at se og rulle tilbage lokale ændringer uden at få adgang til depotet. Størrelsen af arbejdskopien på disken er dog cirka dobbelt så stor (data + ren kopi af data) som størrelsen af selve dataene. Denne tilgang skyldes det faktum, at diskressourcer er billigere og mere tilgængelige end datanetværksressourcer .
Oprettelse af en arbejdskopi er typisk det første og nødvendige trin for at begå lokale ændringer, fordi det kun er ændringer, der er foretaget i arbejdskopien, der kan committeres til depotet. Undtagelsen er operationer, der kan udføres direkte på boksen uden at oprette en arbejdskopi.
TransaktionerOpbevaring i Subversion er organiseret i form af transaktioner med atomicitets- og isolationsegenskaber fra ACID - egenskabssættet . Således garanterer versionskontrolsystemet integriteten, konsistensen og tilgængeligheden af depotet til enhver tid.
Disse egenskaber er ikke garanteret for en Subversion- arbejdskopi - i modsætning til et lager kan det være i en mellemliggende eller låst tilstand, hvis det går ned eller afbrydes (det vil sige, at det skal gendannes med en kommando svn cleanupeller genskabes, før det fortsætter).
Lokale og eksterne kommandoformularerAlle Subversion-klientkommandoer kan opdeles i følgende grupper:
Formelt set lægger Subversion ingen begrænsninger på projektets filstruktur – det kan være hvad som helst inden for rammerne af reglerne for navngivning af objekter i filsystemet. Der er dog retningslinjer for at gøre det nemmere at arbejde med grene og tags. I det enkleste tilfælde anbefales det at oprette mindst tre undermapper i depotets rodmappe:
/. trunk branches tagsHele projektets filstruktur (hovedudviklingslinjen) skal være indeholdt i undermappen trunk, undermappen branchesskal indeholde grenenetags af projektet og tags . For eksempel følgende lagerbiblioteksstruktur:
/. trunk branches branch_1 tags tag_1 tag_2
antager, at projektet ( trunk) har én gren “ branch_1” og to etiketter “ tag_1” og “ tag_2”. Hver af disse mapper ( trunk, branch_1, tag_1og tag_2) indeholder en kopi af den tilsvarende version af projektet.
Hvis der er flere (under)projekter i depotet, oprettes følgende undermappestruktur for hvert (under)projekt:
/. project1 trunk branches tags project2 trunk branches tagsDet vil sige, at rodmappen indeholder projektmapper, og hver af dem har sine egne trunk, branches, tags, kun relateret til dette projekt. De beskrevne lagerkatalogstrukturer er kun eksempler, i praksis kan lageret organiseres på en måde, der er bedst egnet til en given sag. [43] [44]
En anden måde at gemme flere projekter på er at oprette flere repositories. Projekter, der ikke er relaterede på nogen måde, bør placeres i forskellige arkiver, da kopiering, flytning og fletning ikke kan udføres mellem arkiver. Flere arkiver kan flettes til ét, hvis det er nødvendigt, med historikken for revisioner bevaret (ved at importere med kommandoen svnadmin loadmed parameteren --parent-dir).
FilialerSubversion bruger en "fil"-model (samme som Perforce [45] ) til at implementere grene og tags, dvs. en gren er bare en mappe (du kan også lave en gren fra en enkelt fil i stedet for en mappe). En ny gren oprettes af kommandoen svn copy. En filial kan oprettes i ethvert lagerbibliotek, men det giver mening at følge konventionerne beskrevet ovenfor om, hvor man skal oprette nye filialer. For mere information om filialer, se Forgrening og fletning .
TagsOprettelse af en etiket udføres også ved kommandoen svn copy, det vil sige, at det teknisk set er det samme som at oprette en gren. Den eneste forskel er i brugsmetoden: det antages, at ingen vil ændre dataene i etiketten (forpligte ændringer til den). I fig. 1 tag oprettet i revision 29: bibliotek /trunkfra revision 27 kopieret under navnet /tags/R1. Nu, hvis du ikke ændrer dataene i biblioteket /tags/R1, så vil det for altid forblive en nøjagtig kopi af biblioteket /trunk@27, det vil sige, det vil være en etiket .
Konceptet med tags brugt i Subversion er forskelligt fra konceptet tags i andre versionskontrolsystemer. En etiket er typisk et symbolsk navn, der adresserer et sæt filer og deres tilstand. I Subversion kopierer en etiket et sæt filer og deres tilstand. Kopietiketter i Subversion har deres fordele og ulemper.
Fordele:
Fejl:
En af de vigtige funktioner i Subversion er understøttelsen af egenskaber, det vil sige navn = værdi tekstpar , der kan indstilles på objekter i butikken. Egenskaber bruges i to forskellige sammenhænge: til filsystemobjekter og til revisioner.
Egenskaber for filsystemobjekterHver fil eller mappe i en boks kan tildeles et sæt egenskaber. Egenskabsændringer gemmes i historikken på samme måde som ændringer i filsystemet. Brugere kan indstille egenskaber med et hvilket som helst navn; der er også et foruddefineret sæt hjælpeegenskaber, som bruges af Subversion-klientprogrammet (navnene på hjælpeegenskaberne er præfikset med "svn: ").
Filegenskaber svn:executable Gør filen eksekverbar (til arbejdskopier under operativsystemer i UNIX -familien ). svn:mime-type Gemmer filens MIME -type. Påvirker den måde, kommandoer, der viser filforskelle og fletteændringer (fletning) fungerer. svn:keywords Liste over søgeord ( eng. nøgleord ), som vil blive erstattet i filen med de tilsvarende værdier. For at substitutionen kan finde sted, skal nøgleordet være til stede i filen som en $keyword$. Bruges til automatisk at opdatere værdier i en fil, der skifter fra version til version (for eksempel revisionsnummeret). svn:eol-style Angiver reglen for konvertering af end-of-line ( EOL ) -tegn i en tekstfil . Anvendes i tilfælde, hvor filen skal have en specifik EOL-tegntype. Normalt bruges "native" - i dette tilfælde svarer typen af end-of-line-tegn til den, der er vedtaget i det operativsystem, hvor arbejdskopien oprettes. svn:needs-lock Angiver, at filen vil være skrivebeskyttet, når den hentes fra lageret. Denne egenskab er beregnet til at blive brugt sammen med blokeringsmekanismen . At nægte at skrive til en fil er en påmindelse om at anskaffe en lås på filen, før den redigeres: Når en lås er anskaffet, gør Subversion-klientprogrammet automatisk filen skrivbar (hvis låsen slippes igen, kan filen ikke ændres). Låse kan bruges uden at indstille denne egenskab. Dette frarådes dog, da der er risiko for, at en anden bruger kan begynde at redigere den låste fil, og dette vil først blive opdaget, når ændringerne er begået. svn:special Ejendommen er ikke beregnet til at blive indstillet eller ændret af brugere. Bruges i øjeblikket til at gemme symbolske links i lageret. Når et symbolsk link tilføjes til et lager, oprettes en fil i lageret med svn:special. Når denne fil er tjekket ud på et UNIX -lignende system, konverterer Subversion-klientprogrammet den tilbage til et link. svn:mergeinfo Gemmer information om, hvilke stier der blev flettet ind i denne fil. Egenskaben blev introduceret i version 1.5, den bruges til flettesporing . Det er et sæt strenge med formen file_name: revision_range . Her er filnavnet det fulde (med stien fra roden af depotets filsystem) navn på filen eller mappen, hvorfra det angivne udvalg af revisioner blev flettet. Rækker opdateres automatisk under fletteoperationer; ved efterfølgende fletninger tager Subversion hensyn til tidligere tilføjede linjer og undgår derved gentagne fletninger af de samme ændringer. Det anbefales ikke at ændre egenskaben manuelt - dette kan bryde flettesporingsmekanismen.svn:mergeinfo Katalogegenskaber svn:ignore En liste over fil- og mappenavnsmønstre, som Subversion-klientprogrammet vil ignorere i denne mappe. Denne egenskab ligner en fil .cvsignorei CVS . Egenskaben er som regel konfigureret på en sådan måde, at klientprogrammet "ikke ser" filer og mapper, der automatisk oprettes af forskellige programmer og ikke bør versioneres (f.eks. objektfiler , midlertidige filer osv.). Denne egenskab gælder ikke for undermapper. svn:externals Giver dig mulighed for automatisk at udtrække et sæt mapper til en arbejdskopi ved at angive deres URL (du kan endda fra et andet lager). svn:mergeinfo Samme som for filer . RevisionsegenskaberDen anden type objekt, som der findes egenskaber for, er selve revisionerne. I dette tilfælde kan ejendomsnavnene også være hvad som helst; nogle egenskaber præfikset med "svn: " har en særlig betydning. Forskellen mellem egenskaberne for revisioner og egenskaberne for filsystemobjekter er, at for førstnævnte er konceptet versionshistorik ikke anvendeligt (da en specifik egenskabsværdi er tildelt en revision). Med andre ord kan revisionsegenskaber ændres, men den gamle værdi går tabt. Som standard er ændringer til revisionsegenskaber deaktiveret; for at tillade administratoren at oprette et script ( eng. hook ), der håndterer hændelsen pre-revprop-change.
svn:date Datoen og tidspunktet, da revisionen blev oprettet. svn:author Navnet på den bruger, der foretog ændringerne inkluderet i denne revision. svn:log En beskrivelse af de ændringer, der er foretaget i denne revision (den tekst, som brugeren indtastede, da ændringerne blev udført).Som regel ændres revisionsegenskaber kun af lageradministratoren for at rette forkerte data. For eksempel, hvis brugeren glemte at angive en tekstbeskrivelse, da han forpligtede sine ændringer, kan administratoren oprette denne beskrivelse ved at redigere svn:log.
En typisk workflow-iteration med Subversion inkluderer følgende trin.
Forgrening er et vigtigt aspekt af, hvordan versionskontrolsystemer fungerer, fordi typiske versionsstyringsteknikker [47] (i det mindste i softwareudvikling ) involverer brugen af filialer. Subversion har ret avancerede forgrenings- og fletningsfunktioner ( den understøtter dog ikke fletning af omdøbte filer og mapper).
På fig. Figur 3 viser konventionelt et eksempel på udviklingen af grene i depotet. Den grønne farve viser hovedlinjen for projektudvikling ( eng. mainline, trunk ), gul - grene, blå - tags, magenta - en gren, hvis udvikling er afbrudt. Røde pile viser fletningsændringer.
Oprettelse af greneEn ny gren (såvel som et tag ) oprettes af kommandoen svn copy, som opretter en kopi i depotet med nedarvning af kildens revisionshistorik ( A+ operation ). Du bør altid bruge "fjern"-formen af kommandoen til at oprette filialer svn copy, for eksempel:
svn kopi http://.../trunk/dir http://.../branches/branch_name -m "Oprettelse af en gren af dir"Den resulterende kopi vil være en gren (eller et tag, afhængigt af hvordan du arbejder med det). I fremtiden kan ændringer foretaget på en gren foretages til den kilde, hvorfra denne gren blev oprettet, en sådan udbredelse af ændringer kaldes en fletning .
Kopioperationer i Subversion er billige ( eng. cheap copy ), det vil sige, de kræver en lille fast mængde tid og diskplads. Lagringen er designet på en sådan måde [48] , at der under enhver kopiering ikke duplikeres data, men der oprettes et link til kilden (svarende til et hårdt link ), dog er denne mekanisme rent intern - fra brugerens synspunkt visning, er det skabelsen af en kopi, der sker. Takket være den høje effektivitet af forgrening kan forgreninger oprettes så ofte som nødvendigt (men sammenlægning - en nødvendig tilføjelse til forgrening - er langsommere i Subversion end i andre moderne versionskontrolsystemer).
Arbejde med greneGenerelt er arbejdet på en gren ikke anderledes end at arbejde på hovedudviklingslinjen ( stammen ). Specifikke kommandoer er kun nødvendige for aktiviteter, der involverer mere end én gren. Disse kommandoer inkluderer (ud over kommandoen create branch svn copy):
Som regel inkluderer den fulde cyklus af arbejde med grene følgende trin:
En fletning i Subversion er applikationen til en gren af et sæt ændringer foretaget på en anden (eller den samme) gren. For at implementere en fletning skal du bruge en kommando svn merge - den anvender et sæt ændringer til en arbejdskopi; så skal du foretage ændringerne ( svn commit).
Sammenlægning af terminologi er noget forvirrende. Udtrykket fusion er ikke helt præcist, da der ikke er tale om sammenlægning af filialer som sådan . Derudover bør du ikke sætte lighedstegn mellem fletningen og kommandoen svn merge: For det første skal du for fletningen udføre (udover svn merge) konfliktløsning og commit, og for det andet er applikationen svn mergeikke begrænset til fletningen.
Andre anvendelser af kommandoen svn mergeKommandoen svn mergekan bruges til mere end blot at flette. Faktisk foretager kommandoen ændringer i arbejdskopien svarende til forskellen mellem to mapper eller filer i depotet , derfor svn mergeer det et universelt værktøj til at overføre ændringer. Her er nogle eksempler på, hvordan man bruger kommandoen svn merge:
Kommandoen bruges til at oprette en boks svnadmin create. Denne handling vil oprette et tomt lager i den angivne mappe.
Nedenfor er en sammenligning af parametrene for Subversion- og CVS-systemerne, da Subversion netop er positioneret som en forbedring af CVS. Der foretages kun en sammenligning for de parametre, hvor disse systemer er forskellige. Samlet set overgår Subversion CVS på alle måder undtagen etiketter i konventionel forstand (det vil sige etiketter, der adresserer filsystemobjekter).
| Parameter | subversion | CVS |
|---|---|---|
| Evner | ||
| Kataloger | Sporer versioner ikke kun af filer, men også af mapper. | Katalogversioner spores ikke, det vil sige, at mappestrukturen er den samme (den der findes i lageret i øjeblikket) for alle revisioner og alle grene. Hvis du ændrer mappestrukturen, får vi, når vi udpakker de gamle tilstande, de korrekte (gamle) revisioner af filerne, men i den forkerte (eksisterende på udpakningstidspunktet) mappestruktur. |
| Transaktioner | Atomicitet af multi-fil commits. | Atomicitet er kun på niveau med enkelt-fil commits. I realiteten er commit ændringer til flere filer opdelt i en sekvens af commits til individuelle filer. Hvis en sådan sekvens af commits afbrydes, forbliver nogle af filerne committede, mens andre forbliver ucommiterede. |
| Ændringssæt | Ændringssæt understøttes . _ | Ændringssæt understøttes ikke. |
| Ændringer af filnavne | Understøtter kopiering, flytning og omdøbning af filer og mapper uden at miste ændringshistorikken. | Ved kopiering, flytning og omdøbning af filer har filen med det nye navn ingen historik, det vil sige, at forbindelsen med det gamle navn og dets versionshistorik er helt tabt. Det samme for filer inde i en mappe, når du ændrer dens navn [49] . |
| ejendomme | Hver fil og mappe kan have et vilkårligt sæt egenskaber tilknyttet, bestående af et navn og en værdi. Egenskaber er også under versionskontrol. | Egenskaber understøttes ikke. |
| Låse | Valgfri fillåsning er understøttet (siden version 1.2). | Låse understøttes ikke, men der er en lignende mekanisme kaldet sporing . |
| grene | Forgreninger ( gren , se ordliste ) implementeres i stirummet. Det betyder, at for at oprette en filial, kopieres mappen (kopien vil være filialen). Oprettelse af sådanne kopier er en hurtig og ikke ressourcekrævende operation, fordi dataene ikke duplikeres , i stedet er en ny version rettet, som kun adskiller sig fra den forrige i placeringen af filerne. | Grenene implementeres i den "tredje dimension". Det betyder, at en fil på en filial adresseres med tre parametre: sti i filsystemet, revision (eller anden måde at angive revisionen på, såsom tid), filialnavn . |
| Tags | Der er ingen tags ( tag , se ordbog ) som sådan. I stedet bruges et bibliotekshierarki - der oprettes en separat mappe for etiketten (samt for grenen). Et tag er en gren, hvor der efter konvention ikke foretages yderligere ændringer. En etiket er en kopi af den mærkede tilstand af filer og mapper. | Tags er understøttet. Etiketten adresserer filernes mærkede tilstand. |
| Effektivitet | ||
| Klient-server udveksling | Eventuelle versionsopdateringer mellem klienten og serveren overfører kun filforskelle, hvilket kan reducere netværkstrafikken betydeligt. | Forskelle overføres fra serveren til klienten, og hele objektet overføres fra klienten til serveren. |
| Binære | Fungerer lige effektivt med både tekst og binære filer . | Arbejdet med binære filer er mindre effektivt: hver ny version er gemt i repository i sin helhed. |
| Oprettelse af grene og etiketter | Kræver en lille fast mængde tid og diskplads. | Tidsomkostningerne er høje (afhængigt af antallet af involverede filer). Filial- og tagnavne gemmes redundant (i alle involverede filer). |
| Overhead i arbejdskopi | Arbejdskopiens servicemapper gemmer en ren kopi. Derfor er det hurtigt at gennemse og rulle lokale ændringer tilbage (uden at gå til lagring), men størrelsen af arbejdskopien på disken er cirka dobbelt så stor som størrelsen af selve dataene. | En ren kopi gemmes ikke, størrelsen af arbejdskopien er omtrent lig med størrelsen af dataene. Som følge heraf kræver visning og tilbagerulning af lokale ændringer adgang til lageret og er langsomme. |
| Hukommelsesforbrug på serveren | Mindre [50] . | Mere. |
Der er et cvs2svn-program designet til at konvertere et CVS-depot til et færdiglavet Subversion-depot (eller et git -depot ) eller til et tekstdump, som derefter kan importeres til depotet ved hjælp af svnadmin. Samtidig gemmer cvs2svn al information indeholdt i CVS-lageret: grene, tags, ændringsbeskrivelser, forfatternavne, commit-datoer. Derudover konverteres ændringer i forskellige filer, der er begået sammen, til én revision.
Forskelle i brug FilhåndteringsforskelleI CVS sker flytning (omdøbning) og kopiering af filer og mapper ved at tilføje et objekt igen med et nyt navn og (ved flytning og omdøbning) slette det gamle objekt. Med dette arbejde bliver filer og mapper i depotet oprettet på ny og mister deres historik over ændringer. Subversion skal bruge kommandoerne flyt ( moveeller mv) og kopi ( copy) for at udføre disse operationer. Deres brug bevarer historikken for ændringer og giver dig mulighed for at undgå unødvendige operationer (især når du har at gøre med mapper eller endda filsystemgrene).
I modsætning til CVS håndteres nogle arbejdskopioperationer (såsom sletning og flytning af en fil) af Subversion selv. De beskrevne og andre forskelle ved arbejde med arbejdskopifiler er opsummeret i følgende tabel (handlingen commit, hvor det er nødvendigt i begge tilfælde, er udeladt):
| Operation | CVS | subversion | Noter |
|---|---|---|---|
| Sletning af en fil | rm fil cvs rm fil |
svn rm file | filen behøver ikke at blive slettet manuelt først |
| Sletning af filer med maske | rm * cvs rm fil1 fil2 ... |
svn rm * | filer behøver ikke at blive slettet manuelt på forhånd , ingen grund til at opregne alle filer |
| Omdøb/Flyt | mv fil1 fil2 cvs rm fil1 cvs tilføj fil2 |
svn mv file1 file2 | filen skal ikke flyttes manuelt , filhistorikken bevares |
| kopiering | cp fil1 fil2 cvs tilføje fil2 |
svn copy file1 file2 | filen behøver ikke at blive kopieret manuelt filhistorikken bevares (forked) |
| Tilføjelse (oprettelse) af en mappe | mkdir dir cvs tilføje dir |
svn mkdir dir svn commit |
mappen kan ikke oprettes manuelt efter tilføjelse af mappen er nødvendigcommit |
| Tilføjelse af en mappe med filer | cvs add dir cd dir cvs add file1 file2 |
svn add dir | mappen tilføjes med de filer, den indeholder |
| Omdøbning af en mappe med filer (ingen undermapper) |
mkdir dir2 cvs add dir2 mv dir1/* dir2 cvs rm dir1/file1 dir1/file2 ... cvs add dir2/* |
svn mv dir1 dir2 | ingen grund til at oprette og tilføje mapper ingen grund til manuelt at flytte filer ingen grund til at liste alle filer filhistorik gemmes |
| Omdøbning af en gren af filsystemet (mapper med filer og undermapper) |
gentag kommandoerne ovenfor for hvert indlejringsniveau eller hver undermappe [51] |
svn mv dir1 dir2 | se ovenfor afhænger ikke af antallet af niveauer og mapper |
I Subversion er det ikke nødvendigt at oprette tags eller bruge en dato/tid til at adressere depottilstanden, i simple tilfælde (for eksempel for at få en version efter en bestemt commit), vil det være lettere at angive det nødvendige revisionsnummer .
Subversion er designet som et sæt biblioteker opdelt i flere niveauer. Hver af dem udfører en specifik opgave og giver udviklere mulighed for at skabe deres egne værktøjer, afhængigt af kompleksiteten og opgaven.
fs Det laveste niveau; implementerer et versioneret filsystem, der gemmer data. Repos Lagerniveauet implementeret på filsystemet. På dette niveau er mange hjælpefunktioner implementeret, og det understøtter også lanceringen af handlere ( English hooks ), det vil sige scripts, der lanceres, når en hændelse opstår. Tilsammen udgør Fs- og Repos-niveauerne filsystemgrænsefladen . mod_dav_svn Giver WebDAV / Delta-V- adgang via Apache 2. Ra Implementerer lageradgang (både lokalt og eksternt). Fra dette niveau kan depotet refereres ved URL, dvs.Subversions standardklientværktøj, SVN, er konfigureret af miljøvariabler og INI-filer, der er oprettet i brugerens hjemmebibliotek i en undermappe .subversion(placeringen af konfigurationen på Windows-systemer, i filer eller registreringsdatabasen afhænger af systemindstillinger). I konfigurationen cacher SVN også SSL-certifikater, logins, adgangskoder osv. (medmindre det er deaktiveret i konfigurationen) for at få adgang til Subversion-servere.
Katalogindhold .subversion:
Subversion håndterer muligvis ikke altid filomdøbninger korrekt, hvis indholdet af filen ændres samtidig med omdøbningen. Der kan også opstå problemer, hvis en fil omdøbt i den lokale kopi ændres af en anden i depotet. Nogle af disse problemer er rettet i version 1.5, men denne løsning er endnu ikke færdig. [53]
Branchefusionsoperationer betragtes også som et svagt punkt ved Subversion. Før version 1.5 skulle alle sådanne operationer spores manuelt af brugere ved hjælp af detaljerede ændringslogposter. Siden version 1.5 er grundlæggende understøttelse af automatisk flettesporing blevet introduceret, som udviklerne planlægger at forbedre i efterfølgende udgivelser [54] . Subversion understøtter i øjeblikket almindelige flettescenarier ret godt; i mere komplekse sager er problemer mulige. Det anbefales [55] at organisere arbejdsgangen på en sådan måde, at man undgår problematiske scenarier. Sammenlægning af omdøbte filer og mapper understøttes ikke.
Oplysninger, når de først er placeret i Subversion-depotet, forbliver der for evigt: en fil kan slettes ved den aktuelle revision, men det er altid muligt at hente en af de tidligere revisioner, hvor filen eksisterede, fra depotet. Selvom det faktisk er formålet med at bruge versionskontrolsystemer at beholde tidligere revisioner, er det nogle gange nødvendigt fuldstændigt at fjerne information fra et lager, der ved en fejl blev placeret der. Subversion giver ikke nogen naturlig måde at gøre dette på [56] ; den eneste mulighed er at oprette et lagerdump, behandle det med standardværktøjet svndumpfilter og derefter gendanne lageret fra dumpet. Der er også tredjepartsprogrammer til at automatisere denne proces, men under alle omstændigheder kræver denne handling en midlertidig suspension af adgangen til lageret og indgreb fra en administrator med privilegier, der er høje nok til fuldstændigt at slette det gamle lager og erstatte det med et nyt en.
|
Navn |
Beskrivelse |
Sprog |
DB |
Licens |
Internet side |
Opdatering |
Version |
|
et værktøj baseret på Wiki-teknologi |
Python |
SQLite, PostgreSQL, MySQL og MariaDB |
trac.edgewall.org Arkiveret 8. april 2013 på Wayback Machine |
21/06/2017 |
1.2.2 | ||
|
yderligere fejlsporing |
rubin |
MySQL, PostgreSQL, SQLite, Oracle. |
redmine.org Arkiveret 27. april 2011 på Wayback Machine |
09.12.2018 |
4.0.0 | ||
|
værktøj til at oprette og administrere adgang til arkiver, specialiseret til SVN |
PHP |
MySQL, SQLlite |
CeCill (GPL-kompatibel licens). |
www.usvn.info Arkiveret 12. maj 2011 på Wayback Machine |
13/01/2012 |
1.0.6 | |
|
ViewVC |
uden brugerstyring, kræver ikke DAV-understøttelse af webserveren. |
Python |
MySQL |
To-klausul Berkeley-stil |
www.viewvc.org Arkiveret 4. maj 2011 på Wayback Machine |
02.12.2010 |
1.1.8 |
|
WebSVN |
browsing interface til SVN |
PHP |
XML |
websvn.tigris.org Arkiveret 12. juni 2006 på Wayback Machine |
10/12/2010 |
2.3.2 | |
|
værktøj til styring af repositories (oprettelse, sletning, indlæsning og aflæsning; styring af brugere og grupper) |
PHP |
MySQL eller SQLite |
svnmanager.sourceforge.net Arkiveret 30. april 2011 på Wayback Machine |
28/01/2012 |
1.09 | ||
|
Submin (MIT) |
værktøj til styring af arkiver og brugere, herunder styring af adgangskontrol for individuelle kataloger i et arkiv |
Python |
MIT/X Arkiveret 6. juni 2011 på Wayback Machine |
24.12.2012 |
2.1 | ||
|
cSvn |
webgrænseflade til visning af Subversion-depoter |
C |
csvn.radix.pro Arkiveret 16. marts 2022 på Wayback Machine |
17/11/2020 |
0.1.3 |
| Versionskontrolsystemer ( kategori ) | |
|---|---|
| Kun lokalt | |
| Klient-server | |
| Uddelt | |
| URI- ordninger | |
|---|---|
| Officiel | |
| uofficiel | |