Anda sudah membaca tentang copy pekerjaan; sekarang kami akan mendemonstrasikan bagaimana klien Subversion membuat dan menggunakannya.
Copy pekerjaan Subversion adalah susunan direktori biasa pada sistem lokal Anda, dan berisi koleksi file. Anda bisa mengedit file-file ini sesuka Anda, dan jika ada file kode sumber, Anda bisa mengompilasi program Anda darinya seperti biasa. Copy pekerjaan Anda adalah area kerja pribadi Anda sendiri: Subversion tidak akan pernah menyatukan perubahan orang lain, maupun membuat perubahan Anda sendiri tersedia bagi yang lain, sampai Anda memberitahukan secara eksplisit untuk melakukannya.
After you've made some changes to the files in your working copy and verified that they work properly, Subversion provides you with commands to publish your changes to the other people working with you on your project (by writing to the repository). If other people publish their own changes, Subversion provides you with commands to merge those changes into your working directory (by reading from the repository).
Copy pekerjaan juga berisi beberapa file ekstra, dibuat dan dipelihara oleh Subversion, untuk membantunya menjalankan perintah ini. Pada khususnya, setiap direktori dalam copy pekerjaan Anda berisi subdirektori yang dinamai .svn, juga dikenal sebagai direktori administratif copy pekerjaan. File dalam setiap direktori administratif membantu Subversion mengenal file mana yang berisi perubahan yang belum diterbitkan, dan file mana yang ketinggalan zaman dibandingkan dengan pekerjaan orang lain.
Suatu repositori Subversion umum sering menampung file (atau kode sumber) untuk beberapa proyek; biasanya, setiap proyek adalah subdirektori dalam susunan sistem file repositori. Dalam pengaturan ini, copy pekerjaan pengguna akan terhubung ke subpohon tertentu dari repositori.
Sebagai contoh, anggap Anda mempunyai repositori yang berisi dua proyek software.
Dengan kata lain, akar direktori repositori mempunyai dua subdirektori: gambar dan hitung.
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).
Anggap Anda membuat perubahan ke button.c. Karena direktori .svn mengingat tanggal modifikasi file dan isi aslinya, Subversion bisa memberitahu bahwa Anda telah mengubah file. Akan tetapi, Subversion tidak mengumumkan perubahan Anda sampai Anda memberitahu Subversion secara eksplisit untuk melakukannya. Tindakan penerbitan perubahan Anda lebih umum dikenal sebagai mengkomit (atau checking in) perubahan ke repositori.
Untuk menerbitkan perubahan Anda bagi yang lain, Anda bisa menggunakan perintah Subversion komit.
Sekarang perubahan Anda ke button.c sudah dikomit ke repositori; jika pengguna lain melakukan check out copy pekerjaan dari /hitung, mereka akan melihat perubahan Anda dalam file versi terbaru.
Anggap Anda mempunyai kolaborator, Sally, yang melakukan check out copy pekerjaan /hitung pada saat yang sama seperti yang Anda lakukan. Ketika Anda mengkomit perubahan Anda ke button.c, copy pekerjaan Sally dibiarkan tidak berubah; Subversion hanya mengubah copy pekerjaan atas permintaan pengguna.
Agar proyeknya mutahir, Sally bisa meminta Subversion untuk memutahirkan copy pekerjaannya, dengan menggunakan perintah Subversion mutahirkan. Ini akan menyertakan perubahan Anda ke dalam copy pekerjaannya, juga bagi perubahan-perubahan lain yang telah dikomit sejak Sally melakukan check out.
Catatan bahwa Sally tidak perlu untuk menetapkan file yang mana yang dimutahirkan; Subversion menggunakan informasi dalam direktori .svn, dan informasi lebih lanjut dalam repositori, untuk memutuskan file yang perlu dimutahirkan.
Repositori Subversion bisa diakses melalui banyak metode berbeda - pada diska lokal, atau melalui berbagai protokol jaringan. Lokasi repositori, bagaimanapun juga, selalu URL. Skema URL menunjukan metode akses:
Tabel 2.1. URL Akses Repositori
| Skema | Metode Akses |
|---|---|
file://
| Akses repositori langsung pada drive lokal atau jaringan. |
http://
| Mengakses via protokol WebDAV ke server Apache yang mengenal Subversion. |
https://
| Sama seperti http://, tapi dengan enkripsi SSL. |
svn://
| Unauthenticated TCP/IP access via custom protocol to a svnserve server. |
svn+ssh://
| authenticated, encrypted TCP/IP access via custom protocol to a svnserve server. |
For the most part, Subversion's URLs use the standard syntax, allowing for server names and port numbers to be specified as part of the URL. The file:// access method is normally used for local access, although it can be used with UNC paths to a networked host. The URL therefore takes the form file://hostname/path/to/repos. For the local machine, the hostname portion of the URL is required to be either absent or localhost. For this reason, local paths normally appear with three slashes, file:///path/to/repos.
Also, users of the file:// scheme on Windows platforms will need to use an unofficially “standard” syntax for accessing repositories that are on the same machine, but on a different drive than the client's current working drive. Either of the two following URL path syntaxes will work where X is the drive on which the repository resides:
file:///X:/path/to/repos ... file:///X|/path/to/repos ...
Perlu dicatat bahwa URL menggunakan garis miring biasa meskipun bentuk asli (non-URL) suatu path pada Windows menggunakan garis miring terbalik.
You can safely access a FSFS repository via a network share, but you cannot access a BDB repository in this way.
Jangan membuat atau mengakses repositori Berkeley DB pada jaringan berbagi. Ia tidak bisa berada pada sistem file remote. Bahkan tidak jika Anda mempunyai drive jaringan yang dipetakan ke sautu huruf drive. Jika Anda mencoba untuk menggunakan Berkeley DB pada jaringan berbagi, hasilnya tidak bisa ditebak - Anda mungkin melihat kesalahan misterius segera, atau mungkin berbulan-bulan sebelum Anda menemukan bahwa database repositori sudah rusak.
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.
Setiap kali repositori menerima komit, ia membuat kondisi baru pada susunan sistem file, disebut revisi. Setiap revisi ditempati angka alami unik, satu lebih besar dari jumlah revisi sebelumnya. Revisi awal dari repositori yang baru dibuat diberi angka nol, dan tidak terdiri dari apapun tapi direktori akar kosong.
Cara yang baik untuk memvisualisasikan repositori adalah sebagai satu seri pohon-pohon. Bayangkan jajaran dari angka revisi, dimulai dari 0, terentang dari kiri ke kanan. Setiap angka revisi mempunyai pohon sistem file bergantung dibawahnya, dan setiap pohon merupakan “potret” dari cara repositori terlihat setelah setiap komit.
Penting untuk dicatat bahwa copy pekerjaan tidak selalu sesuai dengan setiap revisi tunggal dalam repositori; mereka bisa berisi file dari beberapa revisi. Sebagai contoh, anggaplah Anda melakukan check out copy pekerjaan dari repositori di mana revisi paling baru ialah 4:
calc/Makefile:4
integer.c:4
button.c:4
Sampai saat ini, direktori pekerjaan ini tepat sesuai terhadap revisi 4 dalam repositori. Tetapi, anggap Anda membuat perubahan pada button.c, dan mengkomit perubahan itu. Dengan menganggap tidak ada yang lain telah mengkomit, komit Anda akan membuat revisi 5 dari repositori, dan copy pekerjaan Anda sekarang akan terlihat seperti ini:
calc/Makefile:4
integer.c:4
button.c:5
Anggap bahwa pada titik ini Sally mengkomit perubahan integer.c yang menyebabkan pembuatan revisi 6. Jika Anda menggunakan svn update untuk menjadikan copy pekerjaan Anda mutahir, maka ia akan terlihat seperti ini:
calc/Makefile:6
integer.c:6
button.c:6
Perubahan Sally pada integer.c akan terlihat dalam copy pekerjaan Anda, dan perubahan Anda masih akan ada dalam button.c. Dalam contoh ini, teks Makefile sama persis dalam revisi 4, 5, dan 6, tapi Subversion akan menandai copy pekerjaan Anda untuk Makefile dengan revisi 6 untuk menunjukan bahwa ia masih saat ini. Maka, setelah Anda melakukan pemutahiran bersih pada puncak dari copy pekerjaan Anda, ia umumnya akan merujuk ke tepat satu revisi dalam repositori.
Untuk setiap file dalam direktori pekerjaan, Subversion merekam dua bagian esensial dari informasi dalam area administratif .svn/:
revisi apa file kerja Anda didasarkan (ini disebut revisi pekerjaan) file, dan
suatu cap waktu yang merekam kapan copy lokal dimutahirkan terakhir kali oleh repositori.
Melalui informasi ini, dengan menghubungi repositori, Subversion bisa memberitahu suatu file pekerjaan dalam keadaan apa dari empat keadaan berikut:
File tidak diubah dalam direktori pekerjaan, dan tidak ada perubahan ke file itu yang telah dikomit ke repositori sejak revisi pekerjaannya. Komit file tidak akan melakukan apa-apa, dan mutahirkan file tidak akan mengerjakan apapun.
The file has been changed in the working directory, and no changes to that file have been committed to the repository since its base revision. There are local changes that have not been committed to the repository, thus a commit of the file will succeed in publishing your changes, and an update of the file will do nothing.
The file has not been changed in the working directory, but it has been changed in the repository. The file should eventually be updated, to make it current with the public revision. A commit of the file will do nothing, and an update of the file will fold the latest changes into your working copy.
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.