Eerder heb je al wat gelezen over werkkopieën; nu zullen we demonstreren hoe de Subversion client deze creëert en gebruikt.

Een Subversion werkkopie is eenvoudigweg een mapstructuur met een verzameling van bestanden op je lokale systeem. Je kunt de bestanden bewerken zoals je wilt en als het broncode bestanden zijn, is het mogelijk om ze vanaf die locatie te compileren op de gebruikelijke manier. Je werkkopie is je eigen privé werkomgeving: Subversion zal zelf geen wijzigingen van anderen in je lokale kopie verwerken, of jouw werk aan anderen beschikbaar stellen, zonder dat je daar zelf opdracht voor hebt gegeven.

Nadat je wijzigingen in je bestanden hebt aangebracht en hebt geverifieerd of deze goed werken, biedt Subversion commando’s om je wijzigingen te publiceren voor andere mensen die met jou aan het project werken (door middel van het opslaan in het archief). Als andere mensen hun eigen werk publiceren, biedt Subversion je opdrachten om die wijzigingen samen te voegen in je werkkopie (door te lezen vanuit het archief).

A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, your working copy contains a subdirectory named .svn, also known as the working copy administrative directory . The files in this administrative directory help Subversion recognize which files contain unpublished changes, and which files are out-of-date with respect to others' work. Prior to 1.7 Subversion maintained .svn administrative subdirectories in every versioned directory of your working copy. Subversion 1.7 takes a completely different approach and each working copy now has only one administrative subdirectory which is an immediate child of the root of that working copy.

A standaard Subversion archief bevat vaak de (bron) bestanden voor meerdere projecten; vaak is er voor elk project een submap in de boomstructuur van het archief bestandssysteem. Bij deze indeling correspondeert de werkkopie van een gebruiker meestal met een bepaalde submap van het archief.

Bijvoorbeeld, stel je hebt een archief met twee software projecten.

Afbeelding 2.6. Het archief bestandssysteem

Met andere woorden, de hoofdmap van het archief heeft twee submappen: paint en calc.

To get a working copy, you must check out some subtree of the repository. (The term check out may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you.)

Suppose you make changes to button.c. Since the .svn directory remembers the file's modification date and original contents, Subversion can tell that you've changed the file. However, Subversion does not make your changes public until you explicitly tell it to. The act of publishing your changes is more commonly known as committing (or checking in ) changes to the repository.

Om je wijzigingen te publiceren naar anderen, gebruik je het Subversion commando Vastleggen.

Met dit commando worden je wijzigingen in button.c vastgelegd in het archief; als een andere gebruiker een werkkopie ophaalt van /calc, dan zal deze jouw wijzigingen in de laatste versie zien.

Stel je hebt een medewerker, Sally, die op hetzelfde moment als jij een werkkopie ophaalt van /calc. Als jij je wijzigingen aan button.c vastlegt, blijft Sally’s werk ongewijzigd; Subversion wijzigt alleen werkkopieën op aanvraag van de gebruiker.

Om haar project bij te werken, kan Sally Subversion vragen om haar werkkopie bij te werken, door het Subversion commando Verversen te gebruiken. Hiermee worden jouw wijzigingen in haar kopie verwerkt, net zoals andere wijzigingen die vastgelegd zijn sinds zij haar werkkopie ophaalde.

Merk op dat Sally niet aan hoefde te geven welke bestanden bijgewerkt moesten worden; Subversion gebruikt hiervoor de informatie in de .svn map and informatie uit het archief, om te bepalen welke bestanden bijgewerkt moeten worden.

Subversion archieven kunnen op verschillende methodes benaderd worden – vanaf de lokale harde schijf, of met verschillende netwerk protocollen. Een archief locatie is echter altijd een URL. De vorm van de URL bepaald de toegangsmethode:

Over het algemeen wordt voor de Subversion URLs de standaard syntax gebruikt, waardoor het mogelijk is om server namen en poort nummers als onderdeel van de URL te specificeren. De file:// toegangsmethode wordt normaal gesproken alleen gebruikt voor lokale toegang, alhoewel het ook gebruikt kan worden voor UNC paden naar een netwerk host. De URL krijgt in die gevallen de schrijfwijze file://hostname/path/to/repos. Voor een lokale machine is de hostname niet nodig of localhost. Hierdoor verschijnen lokale paden vaak met drie schuine strepen, file:///path/to/repos.

Ook de gebruikers van het file:// schema op een Windows systeem moet een onofficiële “standaard” syntax gebruiken voor het benaderen van archieven die op dezelfde machine staan, maar op een andere schijf dan de schijf waar op gewerkt wordt. Eén van de twee volgende URL pad vormen kunnen gebruikt worden, waarbij X de schijfletter aangeeft waarop het archief zich bevindt.

file:///X:/pad/naar/repository
...
file:///X|/pad/naar/repository
...
      

Merk op dat de URL gewone schuine strepen gebruikt, terwijl de standaard (niet URL) methode voor een pad op een Windows machine een schuine streep naar links gebruikt.

Je kunt een FSFS repository via een network share benaderen, dit is niet aanbevolen voor diverse redenen:

Een SVN Vastleggen actie worden wijzigingen aan meerdere bestanden en mappen als één enkele actie vastgelegd in het archief. In je werkkopie kun je mappen, bestanden en de inhoud daarvan wijzigen, creëren, verwijderen, hernoemen en kopiëren en vervolgens de hele set van wijzigingen in één keer vastleggen.

In het archief wordt ieder vastlegging behandeld als behandeld als een complete transactie in zijn geheel: dat houdt in dat of alle wijzigingen worden vastgelegd of geen enkele wijziging wordt vastgelegd. Subversion houdt vast aan deze werkwijze met het oog op programma crashes, netwerk problemen en andere gebruikersacties.

Elke keer als het archief een Vastlegging accepteert, creëert het een nieuwe status van de bestandssysteem boom, dit wordt een revisie genoemd. Elke revisie krijgt een uniek geheel getal, één nummer hoger dan het nummer van de vorige revisie. De initiële revisie van een vers archief heeft nummer nul en heeft alleen een lege hoofdmap.

Een mooie manier om een archief te visualiseren, is het gebruik van serie van bomen. Stel je een verzameling van revisienummers voor, aan de linker kant beginnend bij 0 en oplopend van links naar rechts. Elke revisie heeft een boom van het bestandssysteem onder zich hangen en elke boom is een “momentopnamen” van het archief zoals het er uit zag na het vastleggen.

Afbeelding 2.7. Het Archief

Het is belangrijk om op te merken dat werkkopieën niet altijd overeen komen met één enkele revisie in het archief; er kunnen bestanden in zitten die uit verschillende revisies komen. Bijvoorbeeld, je haalt een werkkopie op uit een archief, waarvan de meest recente revisie nummer 4 is:

calc/Makefile:4
integer.c:4
button.c:4
      

Op dit moment komt de werk map precies overeen met revisie 4 in het archief. Echter, stel je wijzigt nu button.c en legt de wijziging vast. Er van uitgaande dat niemand anders wijzigingen heeft vastgelegd, zal jouw toepassing revisie 5 van het archief creëren, en zal je werkkopie er als volgt uit zien.

calc/Makefile:4
integer.c:4
button.c:5
      

Stel dat op dit moment Sally een wijziging in integer.c vastlegt, dan wordt revisie 6 aangemaakt. Als jij zelf dan svn verversen uitvoert om je werkkopie bij te werken, dan zal deze er zo uitzien:

calc/Makefile:6
integer.c:6
button.c:6
      

Sally’s wijziging aan integer.c zal in je werkkopie zichtbaar worden en je eigen wijziging zal nog steeds in button.c zitten. In dit voorbeeld zal de tekst van Makefile gelijk zijn voor revisie 4, 5 en 6, maar zal Subversion je werkkopie van Makefile markeren met revisie 6. Dit om aan te geven dat dit nog de actuele versie is. Kortweg, als je een schone versie ophaalt van je werkkopie, dan komt die kopie overeen met één enkele revisie in het archief.

Voor elk bestand in een werk map houdt Subversion twee essentiële stukjes informatie bij in de .svn/ administratie map:

Met deze informatie en communicerend met het archief, kan Subversion bepalen in welke van de volgende vier fases een bestand verkeert: