Semua sistem kontrol versi harus masalah fundamental yang sama: bagaimana sistem akan membolehkan pengguna untuk berbagi informasi, tapi menjaganya dari saling injak secara tidak sengaja? Semua ini terlalu mudah bagi pengguna untuk menulis ulang perubahan dalam repositori secara tidak sengaja.
Pertimbangkan skenario ini: anggap kami mempunyai dua teman kerja, Harry dan Sally. Mereka masing-masing memutuskan untuk mengedit file pada repositori yang sama pada saat yang sama. Jika Harry menyimpan ke repositori lebih dulu, lalu mungkin saja (beberapa waktu kemudian) Sally bisa menimpanya dengan file tulisan versi barunya sendiri secara tidak sengaja. Sementara versi file Harry tidak akan hilang selamanya (karena sistem mengingat setiap perubahan), setiap perubahan yang dibuat Harry tidak akan ada dalam versi file terbaru Sally, karena ia tidak pernah melihat perubahan Harry untuk dimulainya. Pekerjaan Harry masih secara efektif hilang - atau setidaknya hilang dari versi file terbaru dan mungkin karena kecelakaan. Ini betul-betul situasi yang ingin kami hindari!
Many version control systems use a lock-modify-unlock model to address this problem, which is a very simple solution. In such a system, the repository allows only one person to change a file at a time. First Harry must lock the file before he can begin making changes to it. Locking a file is a lot like borrowing a book from the library; if Harry has locked a file, then Sally cannot make any changes to it. If she tries to lock the file, the repository will deny the request. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, his turn is over, and now Sally can take her turn by locking and editing.
Masalah dengan model kunci-ubah-buka kunci adalah bahwa itu sedikit membatasi, dan sering menjadi halangan bagi pengguna:
Mengunci bisa menyebabkan masalah administratif. Kadang-kadang Harry akan mengunci file dan melupakannya. Sementara itu, karena Sally masih menunggu untuk mengedit file, tangannya terikat. Dan kemudian Harry pergi berlibur. Sekarang Sally harus mendapatkan administrator untuk melepaskan kunci Harry. Situasi berakhir menyebabkan penangguhan yang tidak perlu dan buang-buang waktu.
Mengunci bisa menyebabkan serialisasi yang tidak perlu. Bagaimana jika Harry sedang mengedit awal file teks, dan Sally ingin mengedit akhir dari file yang sama? Ini bukan waktu yang bersamaan sama sekali. Mereka bisa dengan mudah mengedit file secara simultan, dan tidak ada kerusakan besar akan terjadi, dengan asumsi perubahan digabung dengan benar. Tidak perlu mereka mengambil giliran dalam situasi ini.
Mengunci bisa membuat rasa aman yang salah. Anggap bahwa Harry mengunci dan mengedit file A, sementara Sally mengunci dan mengedit file B secara simultan. Tapi anggap bahwa A dan B tergantung pada satu yang lain, dan perubahan yang dibuat ke masing-masing secara semantik tidak sama. Tiba-tiba A dan B tidak bekerja sama lagi. Sistem penguncian tidak berdaya untuk mencegah masalah tersebut - lagipula karena suatu alasan, solusi ini memberikan rasa aman yang salah. Adalah mudah bagi Harry dan Sally untuk membayangkan bahwa dengan mengunci file, masing-masing memulai tugas yang aman dan terinsulasi, dan lalu mencegah mereka mendiskusikan perbedaan-perbedaan yang tidak kompatibel secara dini.
Subversion, CVS, and other version control systems use a copy-modify-merge model as an alternative to locking. In this model, each user's client reads the repository and creates a personal working copy of the file or project. Users then work in parallel, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.
Here's an example. Say that Harry and Sally each create working copies of the same project, copied from the repository. They work concurrently, and make changes to the same file A within their copies. Sally saves her changes to the repository first. When Harry attempts to save his changes later, the repository informs him that his file A is out-of-date. In other words, that file A in the repository has somehow changed since he last copied it. So Harry asks his client to merge any new changes from the repository into his working copy of file A. Chances are that Sally's changes don't overlap with his own; so once he has both sets of changes integrated, he saves his working copy back to the repository.
Tapi bagaimana jika perubahan-perubahan Sally benar-benar bertumpukan dengan perubahan-perubahan Harry? Lalu apa? Situasi ini disebut konflik, dan biasanya tidak begitu bermasalah. Ketika Harry meminta kliennya untuk menggabung perubahan repositori terbaru ke dalam copy pekerjaannya, copy file A miliknya ditandai sebagai dalam keadaan konflik: dia akan bisa melihat kedua set dari perubahan-perubahan yang konflik, dan memilih diantaranya secara manual. Perlu dicatat bahwa perangkat lunak tidak bisa menyelesaikan konflik secara otomatis; hanya manusia yang mampu mengerti dan membuat pilihan-pilihan pintar yang diperlukan. Sekali Harry sudah menyelesaikan perubahan yang saling tindih secara manual (mungkin dengan mendiskusikannya bersama Sally!), dia bisa menyimpan file gabungan dengan aman kembali ke repositori.
Model copy-ubah-gabung mungkin terdengar sedikit kacau, tapi dalam prakteknya, ia berjalan dengan sangat baik. Para pengguna bisa bekerja secara paralel, tidak pernah menunggu yang lain. Saat mereka bekerja pada file yang sama, tampak bahwa kebanyakan perubahan-perubahan konkuren mereka tidak tumpang tindih sama sekali; konflik jarang terjadi. Dan jumlah waktu untuk menyelesaikan konflik jauh lebih sedikit daripada jumlah waktu yang hilang oleh suatu sistem penguncian.
Akhirnya, itu semua berujung pada satu faktor kritis: komunikasi pengguna. Ketika para pengguna berkomunikasi dengan buruk, konflik-konflik baik sintatik maupun semantik meningkat. Tidak ada sistem yang memaksa pengguna untuk berkomunikasi dengan sempurna, dan tidak ada sistem yang dapat mendeteksi konflik semantik. Jadi tidak ada gunanya untuk mencegah konflik; dalam praktek, penguncian nampak untuk menghambat produktivitas lebih dari pada yang lain.
There is one common situation where the lock-modify-unlock model comes out better, and that is where you have unmergeable files. For example if your repository contains some graphic images, and two people change the image at the same time, there is no way for those changes to be merged together. Either Harry or Sally will lose their changes.
Subversion menggunakan solusi copy-ubah-gabung secara bawaan, dan dalam banyak kasus ini adalah semua yang akan Anda perlukan. Akan tetapi, sejak Versi 1.2, Subversion juga mendukung penguncian file. Jadi jika Anda mempunyai file yang tidak bisa digabung, atau jika Anda dipaksa menggunakan kebijakan penguncian oleh manajemen, Subversion akan masih menyediakan fitur yang Anda butuhkan.