Omstörtning

omstörtning
Sorts centraliserat versionskontrollsystem [d] , Apache Foundation-projekt [d] ochöppen källkod
Författare CollabNet [d]
Utvecklaren Apache Software Foundation
Skrivet i C [4] [5] , Python [4] , C++ [6] [7] och Java [6] [7]
Operativ system GNU/Linux [8] , Microsoft Windows [8] , macOS [8] och BSD [8]
Första upplagan 20 oktober 2000 [1]
senaste versionen
Läsbara filformat SVN-dumpformat (v1) [d] , SVN-dumpformat (v2) [d] , SVN-dumpformat (v3) [d] och SVN-dumpformat (generiskt) [d]
Genererade filformat SVN-dumpformat (v1) [d] , SVN-dumpformat (v2) [d] , SVN-dumpformat (v3) [d] och SVN-dumpformat (generiskt) [d]
Licens Apache License 2.0 [9]
Hemsida subversion.apache.org _ 
 Mediafiler på Wikimedia Commons

Subversion [10] (även känd som " SVN " [11] ) är ett gratis centraliserat versionskontrollsystem som officiellt släpptes 2004 av CollabNet . Sedan 2010 har Subversion varit ett projekt av Apache Software Foundation och heter officiellt Apache Subversion (registrerat varumärke [12] ).

Målet med projektet i början av utvecklingen var att ersätta [13] [14] det då utbredda Concurrent Versions System (CVS), som nu anses föråldrat [15] [16] [17] . Subversion implementerar alla huvudfunktionerna i CVS och är fri från några av de senares brister.

Subversion används fortfarande av vissa open source -gemenskaper (inklusive de som använde CVS tidigare ), men nästan alla större projekt har flyttat till DVCS . Bland de sista användarna av Subversion bland öppna projekt återstår FreeBSD , men de tillkännagav också en övergång till Git [18] , och till exempel Free Pascal . Subversion har använts under ganska lång tid av så välkända projekt som Apache , GCC , FFmpeg , LLVM . Subversion används också i privata projekt och företagsvärlden, men det är svårt att bedöma hur brett. Subversion- värd , inklusive för projekt med öppen källkod, tillhandahålls också av populära värdprojekt SourceForge.net , Tigris.org , Google Code och BountySource .

År 2007 bedömde Forrester , ett analysföretag , Subversion som "den enda ledaren i kategorin Fristående Software Configuration Management (SCM) och en stark bidragsgivare i kategorin Software Configuration and Change Management (SCCM)" när man jämförde fördelarna och nackdelarna med olika system . [19]

Enligt statistik om användningen av Linux- paket - Debian [20] och Ubuntu [21] distributioner , nådde antalet aktiva användare av Subversion en topp runt 2010 och har börjat minska sedan 2016. Det finns dock fortfarande fler projekt som använder Subversion än att använda CVS , Mercurial och Bazaar (från och med augusti 2019 ).

Den officiella dokumentationen placeras [22] av boken publicerad av O'Reilly Media , som är fritt tillgänglig [23] och läggs till av författarna när nya versioner av SVN släpps. Den publicerar också sina översättningar till ett antal språk, inklusive ryska, men trots att de engelska versionerna av boken nu beskriver versionerna 1.8 och 1.7, finns det bara böcker på ryska som beskriver versioner upp till 1.4 inklusive [24] .

Historik

Utvecklingen av Subversion började år 2000 på initiativ och med ekonomiskt stöd från CollabNet. Initiativtagarna till projektet ville skapa ett gratis versionskontrollsystem, i princip likt CVS, men utan dess buggar och olägenheter . På den tiden fanns det inga bästa program av denna klass med gratis licens, CVS var de facto standarden bland fri mjukvaruutvecklare. Genom att välja det som baslinje hoppades Subversion-utvecklarna kunna förenkla utvecklingen genom att utnyttja redan beprövade koncept, samtidigt som det skulle göra det lättare för många CVS-användare att migrera till det nya systemet. [25]

Viktiga händelser i Subversions utvecklingshistoria.

Allmän information

Funktioner

Modell av arbete

Subversion är ett centraliserat system (till skillnad från distribuerade system som Git eller Mercurial ), vilket innebär att data lagras i ett enda arkiv. Lagret kan finnas på en lokal disk eller på en nätverksserver .

Att arbeta i Subversion skiljer sig inte mycket från att arbeta i andra centraliserade versionskontrollsystem. Klienter kopierar filer från valvet för att skapa lokala arbetskopior, gör sedan ändringar i arbetskopiorna och överför dessa ändringar till valvet. Flera klienter kan komma åt lagringen samtidigt. Subversion använder i första hand kopiera-modifiera-sammanfogningsmodellen för att samarbeta med filer . För filer som inte går att sammanfoga (olika binära filformat) kan du också använda lock-modify-unlock- modellen .

När nya versioner sparas används deltakomprimering : systemet hittar skillnader mellan den nya versionen och den tidigare och skriver bara dem, vilket undviker dataduplicering.

När du använder WebDAV-åtkomst stöds också transparent versionshantering - om någon WebDAV-klient öppnas för skrivning och sedan sparar en fil som är lagrad på en nätverksresurs skapas en ny version automatiskt.

Förvarstyper

Subversion erbjuder två alternativ för att organisera förråd [40] . Förråd av den första typen används för att lagra en databas baserad på Berkeley DB , förråd av den andra typen är vanliga filer av ett speciellt format (dataåtkomst organiseras med hjälp av deras egna bibliotek, utan att använda tredjepartsdatabaser). Subversion-utvecklarna refererar ofta till lagring som ett "filsystem", vilket är anledningen till att den andra typen kallas FSFS, vilket betyder ett (versionerat) filsystem ( engelsk  filsystem ) ovanpå ett (vanligt) filsystem.

Båda typerna av arkiv ger tillräcklig tillförlitlighet när de är korrekt organiserade [41] (Berkeley DB använder fillås, så det kan inte användas på vissa nätverksfilsystem som inte stöder lås), var och en av dem har sina egna fördelar och nackdelar. Man tror att FSFS är lättare att korrekt konfigurera, det kräver mindre uppmärksamhet från administratören. Dessutom, före release 1.4, kunde repositories som använder Berkeley DB, under vissa förhållanden, hamna i ett  så kallat wedged state ; administratörsingripande krävdes för att återställa dess funktionalitet.

Från och med version 1.2 används FSFS som standard för nya lagringar. Med version 1.8 fasades användningen av Berkeley DB ut [37] . Nya funktioner som kommer att läggas till i framtida versioner kanske inte fungerar på servrar som använder Berkeley DB. Stödet för Berkeley DB kan komma att upphöra i framtiden.

Repository Access

Subversion tillhandahåller följande sätt att komma åt ett arkiv:

Alla dessa metoder kan användas för att arbeta med båda typerna av arkiv (FSFS och Berkeley DB). Olika metoder kan användas samtidigt för att komma åt samma arkiv.

Grundläggande begrepp

Filsystem

Ur användarens perspektiv är Subversion-förrådet ett "tvådimensionellt" filsystem . Objekt i ett arkiv ( filer och kataloger ) identifieras av två " koordinater ": ett namn och ett revisionsnummer . Med andra ord, förvaret är en uppsättning ögonblicksbilder (revisioner) av ett träd av filer och kataloger, indexerade med revisionsnumret. Varje sådan ögonblicksbild är ett vanligt (endimensionellt) filsystem.

Om det är nödvändigt att ange en specifik revision av ett objekt, används en inmatning av formuläret: имя@ревизияt.ex. /main.c@29 filen /main.c i revision 29. En sådan indikation på revisionen som används för att förtydliga namnet kallas peg revision . 

På fig. 1 visar en grafisk representation av filsystemet: den vertikala axeln motsvarar uppsättningen namn, den horisontella axeln motsvarar uppsättningen av revisioner.

Filnamn

Namnet på ett filsystemobjekt i Subversion bildas enligt samma regler som i UNIX-liknande operativsystem: det finns bara en rotkatalog, sökvägselement separeras med ett snedstreck ("/"). Filsystemobjekt är filer och kataloger (liksom symboliska länkar , som emuleras från vanliga filer genom att ställa in attributet svn:special).

Revisionsnummer

Revisionsnumret i Subversion är ett naturligt tal (eller 0 för den allra första revisionen) som adresserar tillståndsnumret för förvaret i takt med att data den innehåller ändras. Varje framgångsrik commit genererar exakt en ny revision av förvaret, så den N: te revisionen är tillståndet för förvaret efter N: te commit.

I Subversion karaktäriserar en revision inte tillståndet för en enskild fil, utan för hela förvaret som helhet. Till exempel är revision 32 (prickad i figuren) tillståndet för fyra filer och två kataloger som fanns i förvaret vid den tiden.

Revisionsnumret är analogt med tiden i den meningen att lägre revisionsnummer motsvarar tidigare tillstånd i förvaret och högre revisionsnummer motsvarar senare.

  • Minsta revisionsnummer 0 (noll) motsvarar förvarets initiala tillstånd, när inga ändringar har genomförts ännu. I version noll innehåller förvaret endast en tom rotkatalog.
  • Det maximala revisionsnumret motsvarar det senaste tillståndet för förvaret, det vill säga tillståndet efter bekräftelsen av den senaste redigeringen. Istället för att ange det senaste revisionsnumret kan du använda nyckelordet HEAD(huvudrevision); detta är praktiskt eftersom huvudets revisionsnummer ökas med varje commit.

Revisionsnumret kan ses som ett slags tidsstämpel i förvarets historia. Dessutom har varje revisionsnummer ett absolut värde kopplat till den tidpunkt då revisionen gjordes ( property svn:date ). Det är dock bekvämare att ange revisionsnumret än att ange tiden, eftersom det inte finns någon förväxling med tidszoner, numret är kortare och revisionsnumret kan inte ändras.

Drifts- och kärnrevisioner

Revisionsnumret används i två olika sammanhang :

  • operational revision ( engelska  operativ revision );
  • kärnrevision ( eng.  peg revision ).

En revision kallas operationell om den anger revisionen eller omfattningen av revisioner som åtgärden ska tillämpas på , till exempel:

svn log -r 199:230 http://some.path

I det här exemplet körs kommandot svn logför en rad revisioner 199:230, vilket är intervallet för onlinerevisioner.

Men att endast specificera filnamnet och onlinerevision kan ibland på ett tvetydigt sätt peka på förvarsobjekten. Till exempel, i den situation som visas i fig. 2, det finns en tvetydighet när du kör följande kommando:

svn log -r 29:33 http://some.path/bar.txt

Kommandot specificerar ett antal onlinerevisioner ( 29:33), men de områden som är markerade i blått och grönt i figuren kan likaså betraktas som historiken för filen /bar.txti revisionsintervallet 29:33. I sådana fall är det också nödvändigt att specificera pivotrevisionen för att lösa tvetydigheten. Kärnrevisionen är revisionsnumret som anges utöver URL :en för filsystemobjektet (med " URL@ревизия"-notationen). Namnet kommer från det engelska ordet peg , som kan översättas med "stav" eller "peg". Pivotrevisionen markerar kedjan av tillstånd som det angivna paret tillhör URL@ревизияoch identifierar därmed unikt arkivobjektet som kommandot ska tillämpas på. I exemplet nedan kommer det första kommandot att skriva ut berättelsen markerad i blått i figuren, och det andra kommandot kommer att skriva ut berättelsen markerad i grönt:

svn log -r 29:33 http://some.path/file.txt@32 svn log -r 29:33 http://some.path/bar.txt@34

Det senaste tillståndet för föremålet av intresse bör anges som kärnrevisionen. Anledningen till detta är att delstatskedjan är unikt spårad "bakåt" men inte "framåt". Till exempel, URL:en med pivotversionen http://some.path/foo.txt@31 tillhör två tillståndskedjor (markerade i grönt respektive grått). Av dessa två kedjor adresserar den angivna URL:en den grå kedjan, det vill säga när man går "framåt" från kärnrevisionen ignoreras kopieringsoperationer.

Operationer på filsystemet

Följande operationer kan utföras på filsystemobjekt i Subversion-förvaret [42] (se figur 1). Hakparenteserna indikerar det korta namnet på operationen i kommandots notation svn status.

  • Bilaga (A). Lägga till ett objekt i filsystemet. Det tillagda objektet har ingen revisionshistorik. Exempel på bilden:
  • Filen /main.clades till i version 27.
  • Modifiering (M). Ändra ett objekt, till exempel att ändra innehållet i en fil eller ändra egenskaperna för en fil eller katalog. Exempel på bilden:
  • Filen /main.cändrades i version 28.
  • Borttagning (D). Ta bort en fil från huvudet och efterföljande revisioner. I det här fallet finns filen kvar i tidigare versioner. Exempel på bilden:
  • Filen /main.ctogs bort i version 30.
  • Tillägg med historik (A+). Representerar kopiering av ett objekt inuti lagringsfilsystemet, det vill säga objektet имя_источника@ревизия_источникаkopieras till имя_копии@HEAD. Det kopierade objektet ärver historiken för revisioner från källan till kopieringsögonblicket (historikarv visas i figuren med prickade länkar). Exempel i figuren:
  • i revision 29 /tags/R1kopierades katalogen från katalogen /trunk@27;
  • /main.ci revision 31 kopierades filen från /main.c@29, det vill säga från en tidigare revision av sig själv, sålunda återställdes den tidigare raderade (i revision 30) filen samtidigt som historiken för revisioner bibehölls.
  • Ersättning (R+). Förekommer i det fall då i en revision både borttagning av ett objekt (D) och tillägg med historik (A+) av ett objekt med samma namn gjordes. Även om namnet förblir oförändrat under ersättningsoperationen, behandlar Subversion objektet före och efter ersättningen som två olika objekt med olika revisionshistorik (historiken för det gamla slutar vid ersättningstillfället, historiken för det nya ärvs från kopiera källan och fortsätter vidare). Exempel på bilden:
  • i revision 30 ersattes filen /file.txtmed : den gamla filen /file.txtraderades och en ny fil med samma namn kopierades från /bar.txt@29.

Begår ändringar

Arbetskopia

En arbetskopia är en lokal kopia av en bit data från arkivet som skapats av Subversion-klientprogrammet som innehåller, förutom själva datan, viss tjänstinformation (dolda kataloger med namnet .svn). Serviceinformationen är nödvändig för att arbetskopian ska fungera korrekt; ingenting kan ändras i tjänstens data. Den minsta dataenheten som kan hämtas från ett arkiv som en arbetskopia är en katalog. Innehållet i en katalog kanske inte är helt extraherat: till exempel kan enskilda filer eller underkataloger uteslutas. Det är dock inte möjligt att checka ut en enda fil från valvet som en arbetskopia.

Varje underkatalog av en Subversion 1.6 och tidigare arbetskopior är också en fullständig arbetskopia, eftersom varje katalog innehåller sina hushållsdata (kataloger .svn). Sedan version 1.7 har varje arbetskopia endast en katalog .svni roten av sin katalog.

Arbetskopian är fristående i den meningen att Subversion inte lagrar någon data relaterad till arbetskopian utanför den. Med en arbetskopia kan du därför göra flera kopior till genom enkel kopiering utan att spendera nätverkstrafik.

I tjänstekatalogerna för arbetskopian lagras bland annat den så kallade rena kopian ( eng.  pristine copy ) - arbetskopians filer i oförändrad form, eftersom de extraherades från förvaret (för svn är detta en revision som heter BASE). Med en ren kopia kan du snabbt se och återställa lokala ändringar utan att behöva komma åt förvaret. Storleken på arbetskopian på disken är dock ungefär dubbelt så stor (data + ren kopia av data) som storleken på själva datan. Detta tillvägagångssätt beror på det faktum att diskresurser är billigare och mer tillgängliga än datanätverksresurser .

Vanligtvis är att skapa en arbetskopia det första och nödvändiga steget för att genomföra lokala ändringar, eftersom endast ändringar som görs i arbetskopian kan överföras till förvaret. Undantaget är operationer som kan utföras direkt på valvet utan att skapa en arbetskopia.

Transaktioner

Lagring i Subversion är organiserat i form av transaktioner med atomicitets- och isoleringsegenskaper från ACID- egenskapsuppsättningen . Således garanterar versionskontrollsystemet integriteten, konsistensen och tillgängligheten för förvaret när som helst.

  • Atomicity of commits ( eng.  atomic commits ) - ändringar i flera filer eller kataloger fixas i en enda transaktion, samtidigt som en revision genereras. I händelse av en misslyckad commit, i händelse av något misslyckande eller fel, garanterar systemet att förvaret inte kommer att hamna i ett delvis modifierat tillstånd - antingen kommer alla ändringar att hamna i förvaret, eller (i händelse av misslyckande) - inga.
  • Isolering säkerställer att mellanliggande lagringstillstånd inom en transaktion inte är synliga för andra transaktioner och användare. Till exempel, om en användare fixar ändringar i flera filer i en transaktion, kan andra användare inte se ett sådant lagringstillstånd där vissa av filerna redan har ändrats, och andra inte har.

Dessa egenskaper är inte garanterade för en Subversion- arbetskopia - till skillnad från ett arkiv kan det vara i ett mellanliggande eller låst tillstånd om det kraschar eller avbryts (det vill säga, det kommer att behöva återställas av ett kommando svn cleanupeller återskapas innan du fortsätter).

Lokala och fjärrkommandoformulär

Alla Subversion-klientkommandon kan delas in i följande grupper:

  • modifiera arbetskopian;
  • modifiering av lagring;
  • modifiera både arbetskopian och arkivet;
  • inte ändra något.

Lagringsstruktur

Projektstruktur i arkivet

Formellt sätter Subversion inga restriktioner på projektets filstruktur – det kan vara vad som helst inom ramen för reglerna för namngivning av objekt i filsystemet. Det finns dock riktlinjer för att göra det lättare att arbeta med grenar och taggar. I det enklaste fallet rekommenderas det att skapa minst tre underkataloger i förvarets rotkatalog:

/. trunk branches tags

Hela filstrukturen för projektet (huvudutvecklingsraden) måste finnas i underkatalogen trunk, underkatalogen branchesmåste innehålla projektets grenar ochtags  taggarna . Till exempel följande förvarskatalogstruktur:

/. trunk branches branch_1 tags tag_1 tag_2

antar att projektet ( trunk) har en gren " branch_1" och två etiketter " tag_1" och " tag_2". Var och en av dessa kataloger ( trunk, branch_1, tag_1och tag_2) innehåller en kopia av motsvarande version av projektet.

Om det finns flera (under)projekt i arkivet skapas följande underkatalogstruktur för varje (under)projekt:

/. project1 trunk branches tags project2 trunk branches tags

Det vill säga, rotkatalogen innehåller projektkataloger, och var och en av dem har sina egna trunk, branches, tags, relaterade endast till detta projekt. De beskrivna lagringskatalogstrukturerna är endast exempel, i praktiken kan lagringen organiseras på ett sätt som är bäst lämpat för ett givet särskilt fall. [43] [44]

Ett annat sätt att lagra flera projekt är att skapa flera arkiv. Projekt som inte är relaterade på något sätt bör placeras i olika arkiv, eftersom kopierings-, flytt- och sammanslagningsoperationer inte kan utföras mellan arkiv. Flera arkiv kan slås samman till ett, om det behövs, med historiken för revisioner bevarad (genom att importera med kommandot svnadmin loadmed parametern --parent-dir).

Filialer

Subversion använder en "fil"-modell (samma som Perforce [45] ) för att implementera grenar och taggar, dvs en gren är bara en katalog (du kan också göra en gren från en enda fil istället för en katalog). En ny gren skapas av kommandot svn copy. En filial kan skapas i vilken förvarskatalog som helst, men det är vettigt att följa konventionerna som beskrivs ovan om var man skapar nya filialer. För mer information om filialer, se Förgrening och sammanslagning .

Taggar

Att skapa en etikett görs också med kommandot svn copy, det vill säga det är tekniskt sett samma sak som att skapa en gren. Den enda skillnaden ligger i användningsmetoden: det antas att ingen kommer att ändra data i etiketten (begå ändringar av den). Till exempel, i fig. 1 tagg skapad i version 29: katalog /trunkfrån version 27 kopierad under namnet /tags/R1. Nu, om du inte ändrar data i katalogen /tags/R1, kommer det för alltid att förbli en exakt kopia av katalogen /trunk@27, det vill säga det kommer att vara en etikett .

Konceptet med taggar som används i Subversion skiljer sig från konceptet med taggar i andra versionskontrollsystem. En etikett är vanligtvis ett symboliskt namn som adresserar en uppsättning filer och deras tillstånd. I Subversion kopierar en etikett en uppsättning filer och deras tillstånd. Kopieringsetiketter i Subversion har sina fördelar och nackdelar.

Fördelar:

  • etiketten är synlig i katalogstrukturen, du kan göra en bekväm trädliknande organisation av etiketter.

Brister:

  • det är svårt att ta reda på vilka etiketter filen angav (samma för katalogen);
  • om åtkomsträttigheter ställs in individuellt [46] för kataloger, så ärver inte etiketten dessa rättigheter;
  • etikettens innehåll kan ändras;
  • om du skapar en arbetskopia från en etikett och gör ändringar från denna arbetskopia, kommer detta att ändra själva etiketten, och inte den data som markerades. Det korrekta sättet att arbeta "från etiketten" är att skapa en arbetskopia inte från etiketten, utan från det som är källan till denna etikett.

Egenskaper

En av de viktiga funktionerna i Subversion är stödet för egenskaper, det vill säga namn = värde textpar , som kan ställas in på objekt i butiken. Egenskaper används i två olika sammanhang: för filsystemobjekt och för revisioner.

Egenskaper för filsystemobjekt

Varje fil eller katalog i ett valv kan tilldelas en uppsättning egenskaper. Egenskapsändringar lagras i historiken på samma sätt som ändringar i filsystemet. Användare kan ställa in egenskaper med vilket namn som helst; det finns också en fördefinierad uppsättning verktygsegenskaper som används av Subversion-klientprogrammet (namnen på verktygsegenskapen har prefixet "svn: ").

Filegenskaper svn:executable Gör filen körbar (för arbetskopior under operativsystem i UNIX- familjen ). svn:mime-type Lagrar filens MIME -typ. Påverkar hur kommandon som visar filskillnader och sammanslagningsändringar (sammanslagning) fungerar. svn:keywords Lista över nyckelord ( eng.  nyckelord ), som kommer att ersättas i filen med motsvarande värden. För att ersättningen ska ske måste nyckelordet finnas i filen som en $keyword$. Används för att automatiskt uppdatera värden i en fil som ändras från version till version (till exempel versionsnumret). svn:eol-style Anger regeln för konvertering av radsluttecken ( EOL ) i en textfil .  Används i de fall där filen måste ha en specifik EOL-teckentyp. Vanligtvis används "native" - ​​i det här fallet motsvarar typen av radsluttecken den som används i operativsystemet där arbetskopian skapas. svn:needs-lock Indikerar att filen kommer att vara skrivskyddad när den hämtas från lagringen. Denna egenskap är avsedd att användas tillsammans med blockeringsmekanismen . Att neka skrivning till en fil är en påminnelse om att skaffa ett lås på filen innan du redigerar den: när ett lås förvärvas gör Subversion-klientprogrammet automatiskt filen skrivbar (om du släpper låset igen gör filen omöjlig att ändra). Lås kan användas utan att ställa in den här egenskapen. Detta rekommenderas dock inte, eftersom det finns en risk att en annan användare kan börja redigera den låsta filen, och detta upptäcks först när ändringarna är genomförda. svn:special Egenskapen är inte avsedd att ställas in eller ändras av användare. Används för närvarande för att lagra symboliska länkar i arkivet. När en symbolisk länk läggs till ett arkiv skapas en fil i arkivet med svn:special. När den här filen är utcheckad på ett UNIX -liknande system, konverterar Subversion-klientprogrammet den tillbaka till en länk. svn:mergeinfo Lagrar information om vilka sökvägar som slogs samman till den här filen. Egenskapen introducerades i version 1.5, den används för sammanslagningsspårning .  Det är en uppsättning strängar av formen filnamn: revisionsintervall . Här är filnamnet  det fullständiga (med sökvägen från roten till förvarets filsystem) namn på filen eller katalogen från vilken det angivna intervallet av revisioner slogs samman. Rader uppdateras automatiskt under sammanslagningsoperationer; vid efterföljande sammanslagningar tar Subversion hänsyn till tidigare tillagda rader, och undviker därigenom upprepad sammanslagning av samma ändringar. Det rekommenderas inte att ändra egenskapen manuellt - detta kan bryta sammanslagningsspårningsmekanismen.svn:mergeinfo Katalogegenskaper svn:ignore En lista över fil- och katalognamnsmönster som Subversion-klientprogrammet kommer att ignorera i den här katalogen. Den här egenskapen liknar en fil .cvsignorei CVS . Egenskapen är som regel konfigurerad på ett sådant sätt att klientprogrammet "inte ser" filer och kataloger som skapas automatiskt av olika program och inte bör versionsföras (till exempel objektfiler , temporära filer etc.). Den här egenskapen gäller inte underkataloger. svn:externals Låter dig automatiskt extrahera en uppsättning kataloger till en arbetskopia genom att ange deras URL (du kan till och med från ett annat arkiv). svn:mergeinfo Samma som för filer . Revisionsegenskaper

Den andra typen av objekt som det finns egenskaper för är själva revisionerna. I det här fallet kan egenskapsnamnen också vara vad som helst; vissa egenskaper med prefixet "svn: " har en speciell betydelse. Skillnaden mellan egenskaperna för revisioner och egenskaperna för filsystemobjekt är att för de förstnämnda är konceptet versionshistorik inte tillämpligt (eftersom ett specifikt egenskapsvärde tilldelas en revision). Med andra ord kan revisionsegenskaper ändras, men det gamla värdet går förlorat. Som standard är ändringar av revisionsegenskaper inaktiverade; för att tillåta administratören att skapa ett skript ( eng.  hook ) som hanterar händelsen pre-revprop-change.

svn:date Datum och tid då revisionen skapades. svn:author Namnet på användaren som utförde ändringarna som ingår i denna version. svn:log En beskrivning av ändringarna som genomförts i denna version (texten som användaren skrev in när ändringarna genomfördes).

Som regel ändras revisionsegenskaper endast av förvarsadministratören för att korrigera felaktiga data. Om användaren till exempel glömde att ange en textbeskrivning när han utförde sina ändringar, kan administratören skapa denna beskrivning genom att redigera svn:log.

Använda Subversion

Arbetscykel

En typisk arbetsflödesiteration med Subversion inkluderar följande steg.

  • Uppdatera en arbetskopia från arkivet ( svn update) eller skapa en ( svn checkout).
  • Ändra arbetskopian. Ändringar av kataloger och information om filer görs med hjälp av Subversion-verktyg, men Subversion är inte involverad i att ändra (innehållet) av filer på något sätt - ändringar görs av program som är designade för detta ( textredigerare , utvecklingsverktyg , etc.):
    • nya (ännu inte anslutna till arkivet) filer och kataloger måste läggas till (kommando svn add), det vill säga överföras under versionskontroll;
    • om en fil eller katalog i din arbetskopia behöver raderas , döpas om , flyttas eller kopieras måste du använda Subversion-funktionerna ( svn mkdir, svn delete, svn move, svn copy);
    • visa statusen för arbetskopian och lokala (ännu ej fastställda) ändringar ( svn info, svn status, svn diff);
    • alla lokala ändringar som misslyckas kan återställas ( svn revert).
  • Om det behövs, en ytterligare uppdatering för att ta emot ändringar som är anslutna till förvaret av andra användare och slå samman dessa ändringar med dina egna ( svn update).
  • Överför dina ändringar (och/eller slå samman resultat) till förvaret ( svn commit).

Förgrening

Förgrening är en viktig aspekt av hur versionskontrollsystem fungerar eftersom typiska versionstekniker [47] (åtminstone inom mjukvaruutveckling ) involverar användning av grenar. Subversion har ganska avancerade förgrenings- och sammanslagningsmöjligheter (dock stöder den inte sammanslagning av omdöpta filer och kataloger).

På fig. Figur 3 visar konventionellt ett exempel på utvecklingen av grenar i förvaret. Den gröna färgen visar huvudlinjen för projektutveckling ( eng.  mainline, trunk ), gul - grenar, blå - taggar, magenta - en gren vars utveckling har avbrutits. Röda pilar visar sammanslagningsändringar.

Skapa grenar

En ny gren (liksom en tagg ) skapas av kommandot svn copy, som skapar en kopia i förvaret med arv av källans revisionshistorik ( A+ operation ). Du bör alltid använda "fjärr"-formen för kommandot för att skapa grenar svn copy, till exempel:

svn copy http://.../trunk/dir http://.../branches/branch_name -m "Skapa en gren av dir"

Den resulterande kopian blir en gren (eller en tagg, beroende på hur du arbetar med den). I framtiden kan ändringar som görs på en gren göras till källan från vilken denna gren skapades, sådan spridning av ändringar kallas en sammanslagning . 

Kopieringsoperationer i Subversion är billiga ( eng.  cheap copy ), det vill säga de kräver en liten fast mängd tid och diskutrymme. Lagringen är utformad på ett sådant sätt [48] att data inte dupliceras under all kopiering, utan en länk till källan skapas (liknande en hård länk ), dock är denna mekanism rent intern - från användarens håll. synen är det skapandet av en kopia som sker. Tack vare förgreningens höga effektivitet kan förgreningar skapas så ofta som behövs (men sammanslagning  - ett nödvändigt tillägg till förgrening - är långsammare i Subversion än i andra moderna versionskontrollsystem).

Arbeta med grenar

I allmänhet skiljer sig arbetet på en gren inte från att arbeta på huvudutvecklingslinjen ( stam ). Specifika kommandon krävs endast för aktiviteter som involverar mer än en gren. Dessa kommandon inkluderar (utöver kommandot create branch svn copy):

  • svn switch - byta en befintlig arbetskopia till en annan filial. En omställning ändrar arbetskopians overhead som om arbetskopian erhölls genom en operation svn checkoutfrån grenen till vilken den byttes. I det här fallet är mängden nätverkstrafik mindre än med svn checkout, eftersom endast skillnaden mellan data i arbetskopian och målgrenen överförs;
  • svn merge - kopiera ändringsuppsättning mellan grenar - används för sammanslagning.

Som regel inkluderar hela cykeln för att arbeta med grenar följande steg:

  • skapande av gren ( svn copy);
  • byta en befintlig arbetskopia till en gren ( svn switch) eller skapa en ny arbetskopia genom att ladda upp ( svn checkout);
  • ändra filer och kataloger i arbetskopian, begå dessa ändringar ( svn commit);
  • kopiera till grenen nya ändringar från den överordnade grenen gjorda efter grenen ( svn merge, svn commit);
  • kopiera ändringar från gren till överordnad gren ( svn merge, svn commit);
  • ta bort en gren ( svn delete) om dess livscykel är över.

Sammanslagning

Kopiera ändringar mellan grenar

En sammanslagning i Subversion är applikationen till en gren av en uppsättning ändringar som gjorts på en annan (eller samma) gren. För att implementera en sammanslagning måste du använda ett kommando svn merge - det tillämpar en uppsättning ändringar på en arbetskopia; sedan måste du genomföra ändringarna ( svn commit).

Att slå samman terminologi är något förvirrande. Termen sammanslagning är inte helt korrekt, eftersom det  inte finns någon sammanslagning av grenar som sådan . Dessutom bör du inte sätta likhetstecken mellan sammanfogningen och kommandot svn merge: för det första, för sammanslagningen måste du utföra (utöver svn merge) konfliktlösning och begå, och för det andra är applikationen svn mergeinte begränsad till sammanslagning.

Andra användningar av kommandot svn merge

Kommandot svn mergekan användas för mer än att bara slå samman. Faktum är att kommandot gör ändringar i arbetskopian lika med skillnaden mellan två kataloger eller filer i arkivet , därför svn mergeär det ett universellt verktyg för att överföra ändringar. Här är några exempel på hur man använder kommandot svn merge:

  • återställning av redan beslutade ändringar, inklusive en hel rad revisioner;
  • bekväm vy (i form av ändringar i arbetskopian) av skillnaden mellan de två tillstånden i förvaret.

Skapa ett valv

Kommandot används för att skapa ett valv svnadmin create. Denna operation skapar en tom butik i den angivna katalogen.

Subversion och CVS

Jämförelse

Nedan är en jämförelse av parametrarna för Subversion- och CVS-systemen, eftersom Subversion är positionerad just som en förbättring av CVS. En jämförelse görs endast för de parametrar där dessa system skiljer sig åt. Sammantaget överträffar Subversion CVS på alla sätt utom för etiketter i konventionell mening (det vill säga etiketter som adresserar filsystemobjekt).

Parameter omstörtning CVS
Förmågor
Kataloger Spårar versioner inte bara av filer utan också av kataloger. Katalogversioner spåras inte, det vill säga katalogstrukturen är densamma (den som finns i arkivet för tillfället) för alla revisioner och alla grenar. Om du ändrar katalogstrukturen får vi korrekta (gamla) versioner av filerna när vi extraherar de gamla tillstånden, men i fel (existerande vid utvinningstillfället) katalogstruktur.
Transaktioner Atomicitet av multi-fil commits. Atomicitet är bara på nivån för enfils commits. I själva verket delas commits till flera filer upp i en sekvens av commits till enskilda filer. Om en sådan sekvens av commits avbryts, förblir några av filerna committerade, medan andra förblir oengagerade.
Ändringar Ändringsuppsättningar stöds .  _ Ändringsuppsättningar stöds inte.
Ändringar av filnamn Stöder kopiering, flyttning och byte av filer och kataloger utan att förlora ändringshistoriken. När du kopierar, flyttar och byter namn på filer har filen med det nya namnet ingen historik, det vill säga kopplingen till det gamla namnet och dess versionshistorik försvinner helt. Samma sak för filer i en katalog när du ändrar dess namn [49] .
egenskaper Varje fil och katalog kan ha en godtycklig uppsättning egenskaper kopplade till sig, bestående av ett namn och ett värde. Egenskaper är också under versionskontroll. Egenskaper stöds inte.
Lås Valfri fillåsning stöds (sedan version 1.2). Lås stöds inte, men det finns en liknande mekanism som kallas spårning .
grenar Grenar ( gren , se ordlista ) implementeras i vägrymden. Detta innebär att för att skapa en filial kopieras katalogen (kopian blir filialen). Att skapa sådana kopior är en snabb och inte resurskrävande operation, eftersom data inte dupliceras , istället är en ny version fixad, som skiljer sig från den tidigare endast i platsen för filerna. Grenarna implementeras i den "tredje dimensionen". Det betyder att en fil på en filial adresseras med tre parametrar: sökväg i filsystemet, revision (eller något annat sätt att ange versionen, t.ex. tid), filialnamn .
Taggar Det finns inga taggar ( tagg , se ordbok ) som sådana. Istället används en kataloghierarki - en separat katalog skapas för etiketten (liksom för grenen). En tagg är en gren som, enligt konvention, inga ytterligare ändringar görs. En etikett är en kopia av det märkta tillståndet för filer och kataloger. Taggar stöds. Etiketten adresserar filernas märkta tillstånd.
Effektivitet
Utbyte mellan klient och server Eventuella versionsuppdateringar mellan klienten och servern överför bara filskillnader, vilket avsevärt kan minska nätverkstrafiken. Skillnader överförs från servern till klienten, och hela objektet överförs från klienten till servern.
Binärer Fungerar lika effektivt med både text och binära filer . Att arbeta med binära filer är mindre effektivt: varje ny version lagras i förvaret i sin helhet.
Skapa grenar och etiketter Kräver en liten fast mängd tid och diskutrymme. Tidskostnaderna är höga (beroende på antalet inblandade filer). Filial- och taggnamn lagras redundant (i alla inblandade filer).
Overhead i arbetsexemplar Arbetskopians servicekataloger lagrar en ren kopia. Därför går det snabbt att bläddra och återställa lokala ändringar (utan att gå till lagring), men storleken på arbetskopian på disken är ungefär dubbelt så stor som storleken på själva data. En ren kopia lagras inte, storleken på arbetskopian är ungefär lika med storleken på datan. Som ett resultat kräver visnings- och återställningsoperationer för lokala ändringar åtkomst till arkivet och är långsamma.
Minnesförbrukning på servern Mindre [50] . Mer.

Migrera från CVS till Subversion

Repository Conversion

Det finns ett cvs2svn-program utformat för att konvertera ett CVS-förråd till ett färdigt Subversion-förråd (eller ett git -förråd ) eller till en textdump, som sedan kan importeras till förvaret med hjälp av svnadmin. Samtidigt sparar cvs2svn all information som finns i CVS-förrådet: grenar, taggar, ändringsbeskrivningar, författarnamn, commit-datum. Dessutom konverteras ändringar i olika filer som committerats tillsammans till en revision.

Skillnader i användning Filhanteringsskillnader

I CVS, flyttas (döpa om) och kopiera filer och kataloger genom att lägga till ett objekt igen med ett nytt namn och (vid flytta och byta namn) ta bort det gamla objektet. Med detta arbete skapas filer och kataloger i arkivet på nytt och förlorar sin historik över ändringar. Subversion måste använda kommandona flytta ( moveeller mv) och kopiera ( copy) för att utföra dessa operationer. Deras användning bevarar historiken för ändringar och låter dig undvika onödiga operationer (särskilt när du har att göra med kataloger eller till och med filsystemsgrenar).

Till skillnad från CVS, hanteras vissa arbetskopieringsoperationer (som att ta bort och flytta en fil) av Subversion själv. De beskrivna och andra skillnaderna när man arbetar med arbetskopior sammanfattas i följande tabell (operationen commit, där den behövs i båda fallen, utelämnas):

Drift CVS omstörtning Anteckningar
Ta bort en fil rm-fil
cvs rm-fil 		svn rm file filen behöver inte raderas manuellt först
Ta bort filer med mask rm *
cvs rm fil1 fil2 ... 		svn rm * filer behöver inte raderas manuellt i förväg,
inget behov av att räkna upp alla filer
Byt namn/flytta mv fil1 fil2
cvs rm fil1
cvs lägg till fil2 		svn mv file1 file2 filen behöver inte flyttas manuellt,
filhistoriken bevaras
kopiering cp fil1 fil2
cvs lägg till fil2 		svn copy file1 file2 filen behöver inte kopieras manuellt,
filhistoriken bevaras (förklädd)
Lägga till (skapa) en katalog mkdir dir
cvs add dir 		svn mkdir dir
svn commit 		katalogen kan inte skapas manuellt
efter att det är nödvändigt att lägga till katalogencommit
Lägga till en katalog med filer cvs add dir
cd dir
cvs add file1 file2 		svn add dir katalogen läggs till med de filer den innehåller
Byta namn på en katalog med filer
(inga underkataloger) 		mkdir dir2
cvs add dir2
mv dir1/* dir2
cvs rm dir1/file1 dir1/file2 ...
cvs add dir2/* 		svn mv dir1 dir2 inget behov av att skapa och lägga till kataloger
inget behov av att manuellt flytta filer
inget behov av att lista alla filer filhistorik
sparas
Byta namn på en gren av filsystemet
(kataloger med filer och underkataloger) 		upprepa kommandon ovan
för varje kapslingsnivå
eller varje underkatalog [51] 		svn mv dir1 dir2 se ovan
beror inte på antalet nivåer och kataloger
Lagringsstatusadressering

I Subversion är det inte nödvändigt att skapa taggar eller använda ett datum/tid för att adressera arkivets tillstånd, i enkla fall (till exempel för att få en version efter en viss commit), blir det lättare att ange det nödvändiga revisionsnumret .

Intern struktur

Nivåer

Subversion är designad som en uppsättning bibliotek uppdelade i flera nivåer. Var och en av dem utför en specifik uppgift och låter utvecklare skapa sina egna verktyg, beroende på komplexiteten och uppgiften.

fs Den lägsta nivån; implementerar ett versionsformat filsystem som lagrar data. Repos Nivån av lagring implementerad på filsystemet. På den här nivån är många hjälpfunktioner implementerade, och den stöder även lansering av hanterare ( English  hooks ), det vill säga skript som startas när en händelse inträffar. Tillsammans utgör Fs- och Repos-nivåerna filsystemets gränssnitt . mod_dav_svn Ger WebDAV / Delta-V- åtkomst via Apache 2. Ra Implementerar lagringsåtkomst (både lokalt och fjärrstyrt). Med utgångspunkt från denna nivå kan förvaret refereras med URL, dvs.
  • file:///path/för lokal åtkomst,
  • http://host/path/ eller https://host/path/ för WebDAV-åtkomst, eller
  • svn://host/path/ eller för åtkomst via SVN-protokollet.svn+ssh://host/path/
Kund, WC Den högsta nivån. Abstrakterar lagringsåtkomst och utför typiska klientuppgifter som användarautentisering eller versionsjämförelse. Klienten använder Wc-biblioteket för att hantera den lokala arbetskopian.

Klientkonfiguration

Subversions standardklientverktyg, SVN, konfigureras av miljövariabler och INI-filer skapade i användarens hemkatalog i en underkatalog .subversion(platsen för konfigurationen på Windows-system, i filer eller registret, beror på systeminställningar). I konfigurationen cachar SVN även SSL-certifikat, inloggningar, lösenord etc. (såvida det inte är inaktiverat i konfigurationen) för åtkomst till Subversion-servrar.

Kataloginnehåll .subversion:

  • fil servers - innehåller information om nätverksanslutningsmetoder till ett fjärrlager;
  • fil config - innehåller annan konfigurationsinformation [52]
  • katalog auth - innehåller en cache med servrar, certifikat, inloggningar och lösenord
  • fil README.txt - SVN-konfigurationsdokumentation

Nackdelar

Problem med att byta namn på filer

Subversion kanske inte alltid hanterar filbyten korrekt om innehållet i filen ändras samtidigt som namnbytet. Problem kan också uppstå om en fil som bytt namn i den lokala kopian ändras av någon annan i förvaret. Vissa av dessa problem är åtgärdade i version 1.5, men den här lösningen är ännu inte komplett. [53]

Dåligt stöd för att slå samman grenar

Branschsammanslagningar anses också vara en svag punkt för Subversion. Före version 1.5 måste alla sådana operationer spåras manuellt av användare med hjälp av detaljerade ändringsloggposter. Sedan version 1.5 har grundläggande stöd för automatisk sammanslagningsspårning införts, vilket utvecklarna planerar att förbättra i efterföljande utgåvor [54] . Subversion stöder för närvarande vanliga sammanslagningsscenarier ganska bra; i mer komplexa fall är problem möjliga. Det rekommenderas [55] att organisera arbetsflödet på ett sådant sätt att problematiska scenarier undviks. Sammanfogning av omdöpta filer och kataloger stöds inte.

Det går inte att radera data från lagringen

Information som väl placerats i Subversion-förvaret förblir där för alltid: en fil kan raderas vid den aktuella versionen, men det är alltid möjligt att hämta en av de tidigare versionerna där filen fanns från förvaret. Även om det faktiskt är syftet med att använda versionskontrollsystem att behålla tidigare revisioner, är det ibland nödvändigt att helt ta bort information från ett arkiv som av misstag placerats där. Subversion tillhandahåller inte något naturligt sätt att göra detta [56] ; den enda möjligheten är att skapa en lagringsdump, bearbeta den med standardverktyget svndumpfilter och sedan återställa lagringen från dumpen. Det finns även tredjepartsprogram för att automatisera denna process, men i alla fall kräver den här operationen en tillfällig avstängning av åtkomst till lagringen och ingripande av en administratör med privilegier som är tillräckligt höga för att helt radera den gamla lagringen och ersätta den med en ny ett.

Ytterligare programvara

  • Kunder :
    • RapidSVN  är en plattformsoberoende Subversion C++- klient ;
    • SmartSVN  är en plattformsoberoende Subversion Java -klient ;
    • TortoiseSVN  är en Subversion-klient implementerad som en Windows Explorer- tillägg ;
    • RabbitVCS  är en Subversion-klient implementerad som en förlängning för Linux -filhanteraren (tidigare kallad NautilusSVN);
    • KDESvn är en grafisk Subversion-klient som en del av KDE Software Compilation Suite av applikationer;
    • VisualSVN  är ett tillägg för Microsoft Visual Studio .
  • Plugins :
  • Webbgränssnitt :
    • Trac  är ett verktyg baserat på Wiki-teknik,
    • Redmine  - spårar dessutom fel,
    • USVN  är ett verktyg för att skapa och hantera åtkomst till arkiv, specialiserat för SVN,
    • ViewVC ,
    • websvn ,
    • SVNManager  - PHP-verktyg för att hantera arkiv (skapa, ta bort, ladda och ladda ur; hantera användare och grupper),
    • Submin  är ett verktyg för att hantera arkiv och användare, inklusive hantering av åtkomstkontroll till enskilda kataloger i ett arkiv,
    • cSvn  är en plattformsoberoende Subversion C -klient .
  • Jämförelsetabell: webbgränssnitt:

namn

Beskrivning

Språk

DB

Licens

Hemsida

Uppdatering

Version

Trac

ett verktyg baserat på Wiki-teknik

Pytonorm

SQLite, PostgreSQL, MySQL och MariaDB

Ändrad BSD-licens

trac.edgewall.org Arkiverad 8 april 2013 på Wayback Machine

21/06/2017

1.2.2

Redmine

ytterligare felspårning

rubin

MySQL, PostgreSQL, SQLite, Oracle.

GNU General Public License

redmine.org Arkiverad 27 april 2011 på Wayback Machine

09.12.2018

4.0.0

USVN

verktyg för att skapa och hantera åtkomst till arkiv, specialiserat för SVN

PHP

MySQL, SQLlite

CeCill (GPL-kompatibel licens).

www.usvn.info Arkiverad 12 maj 2011 på Wayback Machine

2012-01-13

1.0.6

ViewVC

utan användarhantering, kräver inte DAV-stöd av webbservern.

Pytonorm

MySQL

Tvåklausul i Berkeley-stil

www.viewvc.org Arkiverad 4 maj 2011 på Wayback Machine

2010-12-02

1.1.8

WebSVN

webbläsargränssnitt till SVN

PHP

XML

GNU GPL

websvn.tigris.org Arkiverad 12 juni 2006 på Wayback Machine

2010-12-10

2.3.2

SVNManager

verktyg för att hantera förråd (skapa, ta bort, ladda och ta bort, hantera användare och grupper)

PHP

MySQL eller SQLite

svnmanager.sourceforge.net Arkiverad 30 april 2011 på Wayback Machine

2012-01-28

1.09

Submin (MIT)

verktyg för att hantera arkiv och användare, inklusive hantering av åtkomstkontroll för enskilda kataloger i ett arkiv

Pytonorm

MIT/X Arkiverad 6 juni 2011 på Wayback Machine

24.12.2012

2.1

cSvn

webbgränssnitt för visning av Subversion-förråd

C

RADIX-1.0

csvn.radix.pro Arkiverad 16 mars 2022 på Wayback Machine

11/17/2020

0.1.3

Anteckningar

  1. ↑ https://subversion.apache.org/docs/release-notes/release-history.html
  2. ↑ Apache Subversion 1.10.8 släpptes  - 2022 .
  3. ↑ Apache Subversion 1.14.2 släpptes  - 2022 .
  4. ↑ 1 2 Subversionen med öppen källkod på Open Hub: Languages-sida - 2006.
  5. ↑ https://projects.apache.org/json/projects/subversion.json
  6. ↑ 1 2 Open Hub - 2006.
  7. ↑ 1 2 https://www.openhub.net/p/subversion/analyses/latest/languages_summary
  8. ↑ 1 2 3 4 Gratis programvarukatalog
  9. ↑ http://subversion.tigris.org/license-1.html
  10. ↑ Det engelska ordet subversion kan översättas på två sätt - som "omstörta" ( subversion ) och som "subversion" ( subversion )
  11. ↑ Med namnet på klientprogrammet för kommandoraden , som är en del av paketet
  12. ↑ Apache varumärkeslista . Hämtad 10 oktober 2015. Arkiverad från originalet 7 oktober 2015.
  13. ↑ Subversion Features Arkiverad 8 april 2011 på Wayback Machine 
  14. ↑ Riskerna med distribuerad versionskontroll Arkiverad 15 juli 2011 på Wayback Machine Ben Collins-   Sussman
  15. ↑ CVS är ute, Subversion finns i Arkiverad 25 mars 2010.  (engelska) Red Hat magazine, augusti 2005
  16. ↑ CVS - sourceforge Arkiverad 10 juni 2010.
  17. ↑ CVS-versionskontrollsystem . Hämtad 30 juni 2010. Arkiverad från originalet 8 juli 2010.
  18. ↑ HEAD UP: FreeBSD src repo övergår till git i  helgen . lists.freebsd.org (17 december 2020). Hämtad 22 december 2020. Arkiverad från originalet 18 december 2020.
  19. ↑ The Forrester Wave: Software Change and Configuration Management, Q2 2007 (länk ej tillgänglig) . Forrester Research . Arkiverad från originalet den 25 augusti 2011. 
  20. ↑ Statistik för popularitetstävling för bzr, git, git-core, mercurial, subversion . Hämtad 24 juni 2010. Arkiverad från originalet 6 april 2014.
  21. ↑ Arkiverad kopia . Hämtad 24 juni 2010. Arkiverad från originalet 17 juli 2011.
  22. ↑ se http://subversion.apache.org/docs/ Arkiverad 17 juni 2010 på Wayback Machine  
  23. ↑ Ben Collins-Sussman, Brian W. Fitzpatrick & C. Michael Pilato. Versionskontroll med  Subversion . Hämtad 27 november 2019. Arkiverad från originalet 8 augusti 2010.
  24. ↑ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. Versionskontroll i Subversion . Hämtad 27 november 2019. Arkiverad från originalet 18 november 2019.
  25. ↑ Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato. Historik om Subversion / Versionskontroll i Subversion (länk ej tillgänglig) (2007). — För Subversion 1.4. Hämtad 21 juli 2010. Arkiverad från originalet 25 augusti 2011. 
  26. ↑ Ändringslogg Arkiverad 18 juni 2010 på Wayback Machine 
  27. ↑ Goliath Business News Arkiverad 5 december 2008.
  28. ↑ Subversion 1.1 Release Notes . Hämtad 18 juni 2010. Arkiverad från originalet 17 juni 2010.
  29. ↑ Subversion 1.2 Release Notes . Hämtad 18 juni 2010. Arkiverad från originalet 17 juni 2010.
  30. ↑ Subversion 1.3 Release Notes . Hämtad 19 juni 2010. Arkiverad från originalet 17 juni 2010.
  31. ↑ Subversion 1.4 Release Notes . Hämtad 18 juni 2010. Arkiverad från originalet 17 juni 2010.
  32. ↑ Subversion 1.5 Release Notes . Hämtad 18 juni 2010. Arkiverad från originalet 2 juli 2016.
  33. ↑ Subversion 1.6 Release Notes . Hämtad 18 juni 2010. Arkiverad från originalet 17 juni 2010.
  34. ↑ Subversion överförd till Apache Software Foundations kontroll Arkiverad 23 februari 2010 på Wayback Machine , nixp.ru
  35. ↑ Subversion & the Move to the Apache Software Foundation  (nedlänk) , (videomeddelande från presidenten för Subversion Corporation)
  36. ↑ Apache Subversion 1.7 Release Notes . Hämtad 12 oktober 2011. Arkiverad från originalet 12 oktober 2011.
  37. ↑ 12 Subversion 1.8 Release Notes . Hämtad 9 juli 2013. Arkiverad från originalet 10 juli 2013.
  38. ↑ arbete med symboliska länkar stöds endast i arbetskopior under UNIX- system
  39. ↑ 1 2 Grenar och taggar i Subversion är inte en oberoende förvarsdimension. Se nyckelbegreppen bakom förgrening arkiverad 5 oktober 2015 på Wayback Machine
  40. ↑ Termerna repository och repository är synonyma.
  41. ↑ Kapitel 5. Lagringsadministration Arkiverad 9 november 2017 på Wayback Machine i Subversion Version Control
  42. ↑ Operationer listas här ur lagringsfilsystemets synvinkel . I en arbetskopia är åtgärder på objekt något annorlunda. Ändringar i arbetskopian kommer dock att utlösa de åtgärder som beskrivs här i arkivet. Till exempel kommer ett kommando svn movei arbetskopian att utföra operationer Dpå A+valvet.
  43. ↑ C++-projektstruktur med Subversion och Mxx_ru Arkiverad 19 februari 2008 på Wayback Machine .
  44. ↑ Lagra komplexa projekt i ett arkiv och tagga flera projekt samtidigt Arkiverad 4 augusti 2008 på Wayback Machine .
  45. ↑ Inter-File Branching in Perforce Arkiverad 14 juli 2007.
  46. ↑ Sökvägsbaserad auktorisering . Tillträdesdatum: 27 maj 2008. Arkiverad från originalet den 7 oktober 2008.
  47. ↑ Typiska exempel Arkiverade 3 december 2008 på Wayback Machine , avsnitt i Subversion Version Control, version 1.4
  48. ↑ Bubble-Up-metod Arkiverad 17 juni 2010 på Wayback Machine 
  49. ↑ I CVS kan en katalog flyttas direkt till förvaret med hjälp av filsystemet , medan filerna i den inte kommer att förlora sin historia. Denna ändring kommer dock att påverka alla versioner och filgrenar i den katalogen (eftersom kataloger inte har versionsinformation alls i CVS).
  50. ↑ Subversion FAQ . Hämtad 14 april 2010. Arkiverad från originalet 15 april 2010.
  51. ↑ Ett bättre alternativ kan vara att hacka CVS-förvaret - byt namn på katalogen direkt till förvaret på servern
  52. ↑ Runtime Configuration Area. Anpassa din Subversion-upplevelse (nedlänk) . Hämtad 16 september 2010. Arkiverad från originalet 25 augusti 2011. 
  53. ↑ Kopiera/flytta-relaterade förbättringar i Subversion 1.5 . Hämtad 24 juni 2008. Arkiverad från originalet 24 juni 2008.
  54. ↑ Sammanfoga spårning (grundläggande) . Hämtad 24 juni 2008. Arkiverad från originalet 24 juni 2008.
  55. ↑ Subversion merge återintegrera Arkiverad 31 augusti 2009 på Wayback Machine 
  56. ↑ svn utplåna . Hämtad 21 juli 2008. Arkiverad från originalet 22 november 2002.

Länkar

 URI- scheman
Officiell
inofficiell