Už ste čítali o pracovných kópiách; teraz predvedieme ako Subversion klient vytvára a používa.
Pracovná kópia Subversion je obyčajný strom adresárov vo vašom lokálnom systéme, pozostávajúci zo zbierky súborov. Môžte tieto súbory upravovať akokoľvek si želáte a ak sú to súbory zdrojových kódov, môžte z nich zostaviť program bežnou cestou. Vaša pracovná kópia je váš vlastný súkromný pracovný priestor: Subversion nikdy nebude pripájať zmeny iných ľudí, ani sprístupňovať vaše zmeny druhým, pokiaľ mu vy výlučne neprikážete, aby tak urobil.
Potom ako ste urobili zmeny súborov vo vašej pracovnej kópii a overili, že všetky správne pracujú, Subversion vám poskytne príkaz na zverejnenie vaších zmien ostatným ľuďom pracujúcich s vami na vašom projekte (zapísaním do úložiska). Ak ostatní ľudia publikujú ich vlastné zmeny, Subversion vám poskytne príkaz na zlúčenie týchto zmien vo vašom pracovnom adresári (načítaním z úložiska).
Pracovná kópia taktiež obsahuje nejaké prídavné súbory, vytvorené a udržiavané Subverziou, aby pomohli realizovať tieto príkazy. Predovšetkým, každý adresár vo vašej pracovnej kópii obsahuje podadresár pomenovaný .svn, taktiež známy ako pracovná kópia administratívny adresár. Súbory v každom administratívnom adresári pomáhaju Subverzii rozoznať, ktoré súbory obsahujú nezverejnené zmeny a ktoré súbory sú neplatné s ohľadom na prácu iných.
A typical Subversion repository often holds the files (or source code) for several projects; usually, each project is a subdirectory in the repository's filesystem tree. In this arrangement, a user's working copy will usually correspond to a particular subtree of the repository.
Napríklad, predpokladajme, že máte úložisko, ktoré obsahuje dva softvérové projekty.
Inými slovami, koreňový adresár úložiska má dva podadresáre: maľovať a kalkulovať.
Aby ste získali pracovnú kópiu, musíte najprv získať niektorý pod-strom z úložiska. (Výraz získať môže vyznieť ako niečo, čo má dočinenia so zamykaním alebo uschovávaním zdrojov, ale nie je to tak ); jednoducho len vytvorí súkromnú kópiu projektu pre vás).
Predpokladajme, že urobíte zmeny v button.c. Keďže si .svn adresár pamätá dátum zmeny súboru a pôvodný obsah, Subversion vie povedať, že ste zmenili súbor. Avšak, Subversion nezverejní žiadne zmeny pokiaľ ste mu/jej tak vyslovene neprikázali. Úkon zverejnenia vašich zmien je všeobecne viac známy ako odovzdanie ( alebo overovanie) zmien do úložiska.
Aby ste zverejnili vaše zmeny ostatným môžete použiť príkaz odovzdať.
Teraz boli vaše zmeny do button.c odovzdané do úložiska; ak iný užívateľ získa pracovnú kópiu /kalkulovať, uvidí vaše zmeny v najnovšej verzii vášho súboru.
Predpokladajmem, že máte spolupracovníka, Sally, ktorá získala pracovnú kópiu /kalkulovať v tom istom čase ako vy. Keď odovzdáte vašu zmenu do button.c, Sallyina pracovná kópia ostane nezmenená; Subversion zmení len pracovné kópie na úživateľovu požiadavku.
Doviesť jej projekt do aktuálneho stavu, Sallz môže požiadať Subversion o aktualizovanie jej pracovnej kópie, využitím príkazu aktualizovať Subverzie.Tento príkaz včlení vaše zmeny do jej pracovnej kópie, takisto ako všetky ostatné, ktoré boli odovzdané odkedy ich Sally získala.
Všimnite si, že Sally nepotrebovala špecifikovať, ktoré súbory chce aktualizovať; Subversion používa informácie v .svn adresári a ďalšie informácie v úložisku na rozhodnutie, ktoré súbory by mali byť aktualizované.
Úložiská Subversion môžu byť prístupné mnohými rozlišnými metódami - na lokálnom disku alebo cez rôzne sieťové protokoly. Hoci pozícia úložiska je vždy URL. Schéma URL udáva prístupovú metódu:
Tabuľka 2.1. URL na prístup k úložisku
| Schéma | Metódy prístupu |
|---|---|
file://
| Priamy prístup k úložisku na miestnom, alebo sieťovom disku. |
http://
| Prístup cez WebDAV protokol k Subversion-ovému Apache serveru. |
https://
| Rovnako ako http://, ale s SSL kryptovaním. |
svn://
| Neautentifikovaný TCP/IP prístup cez vlastný protokol k svnserve serveru. |
svn+ssh://
| autentifikovaný, šifrovaný TCP/IP prístup pomocou vlastného protokolu k svnserve serveru |
Pre väčšiu časť, URL Subverzie používa štandardnú skladbu, dovoľujúc menám serverov a číslam portov byť špecifikovaných ako časť URL. súbor:// prístupová metóda je obyčajne používaná pre lokálny prístup, hoci môže byť použitá s cestami UNC do sieťového hostiteľa. URL preto zoberie podobu file://hostname/path/to/repos. Pre lokálny prístroj, je od hostname URL časti požadované, aby bola neprítomná alebo localhost. Kvôli tomu, sa lokálne cesty objavujú s tromi lomítkami, file:///path/to/repos.
Taktiež, užívatelia file:// schémy v platforme Windowsu budú musieť používať neoficiálne “štandardnú” skladbu pre prístup do úložísk, ktoré sú na tom istom prístroji, ale na inej mechanike než je klientova súčasná pracujúca mechanika. Obidva s dvoch nasledujúcich URL cestných skladieb bude pracovať kde X je mechanika na ktorej úložisko spočíva:
file:///X:/path/to/repos ... file:///X|/path/to/repos ...
Zapamätajte si, že URL používa obyčajné lomítka hoci prirodzená (nie-URL) forma cesty vo Windowse používa spätné lomítko.
Prístup k úložisku FSFS je bezpečný aj pomocou zdielaného disku, ale k BDB úložisku takýto prístup nie je možný.
Do not create or access a Berkeley DB repository on a network share. It cannot exist on a remote filesystem. Not even if you have the network drive mapped to a drive letter. If you attempt to use Berkeley DB on a network share, the results are unpredictable - you may see mysterious errors right away, or it may be months before you discover that your repository database is subtly corrupted.
A svn commit operation can publish changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents, create, delete, rename and copy files and directories, and then commit the complete set of changes as a unit.
In the repository, each commit is treated as an atomic transaction: either all the commits changes take place, or none of them take place. Subversion retains this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.
Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number of the previous revision. The initial revision of a freshly created repository is numbered zero, and consists of nothing but an empty root directory.
A nice way to visualize the repository is as a series of trees. Imagine an array of revision numbers, starting at 0, stretching from left to right. Each revision number has a filesystem tree hanging below it, and each tree is a “snapshot” of the way the repository looked after each commit.
Je dôležité poznamenať, že pracovná kópie namusí nutne vždy zodpovedať jednej revízií. Môže taktiež obsahovať súbory z viacero rôznych revizií. Napríklad predpokladajme, ze získate pracovnú kópiu z úložiska s aktuálnou revíziou 4:
calc/Makefile:4
integer.c:4
button.c:4
Teraz, pracovný adresár zodpovedá presne revízií 4 v úložisku. Ašak predpokladajme, že ste urobili zmeny v button.c, a tieto zmeny ste odovzdali. Predpokladajúc, že neboli vykonané žiadne ine zmeny, vaše odovzdanie vytvorí v úložisku reviíziu 5 a vaša pracovná bude teraz vyzerať takto:
calc/Makefile:4
integer.c:4
button.c:5
Suppose that, at this point, Sally commits a change to integer.c, creating revision 6. If you use svn update to bring your working copy up to date, then it will look like this:
calc/Makefile:6
integer.c:6
button.c:6
Sally's changes to integer.c will appear in your working copy, and your change will still be present in button.c. In this example, the text of Makefile is identical in revisions 4, 5, and 6, but Subversion will mark your working copy of Makefile with revision 6 to indicate that it is still current. So, after you do a clean update at the top of your working copy, it will generally correspond to exactly one revision in the repository.
For each file in a working directory, Subversion records two essential pieces of information in the .svn/ administrative area:
what revision your working file is based on (this is called the file's working revision), and
a timestamp recording when the local copy was last updated by the repository.
Given this information, by talking to the repository, Subversion can tell which of the following four states a working file is in:
Súbor nebol zmenený v pracovnom adresáry ani neboli odovzdané zmeny do úložiska. Príkaz odovzdať aj aktualizovať budú bez efektu.
Súbor bol zmenený v pracovom adresáry, ale neboli odovzdané žiadne zmeny do úložsika od jeho základnej revízie. Miestne zmeny, ktoré neboli odovzdené do úložiska, môžu byť odovzdané pomocou odovzdať. Príkaz aktualizovať nevykoná nič.
Súbor nebol menení v pracovnom adresáry, ale bol zmenení v úložisku. Súbor by mal byť eventuálne aktulizovaný, aby bol zhodný s aktuálnou revíziou. Príkaz odovdzať na tomto súbore neurobí nič, a príkaz aktualizovať príme poslesné zmeny do pracovnej kópie.
The file has been changed both in the working directory, and in the repository. A commit of the file will fail with an out-of-date error. The file should be updated first; an update command will attempt to merge the public changes with the local changes. If Subversion can't complete the merge in a plausible way automatically, it leaves it to the user to resolve the conflict.