Sistem kawalan versi(dari Sistem Kawalan Versi Bahasa Inggeris, VCS atau Sistem Kawalan Semakan) - perisian untuk memudahkan kerja dengan menukar maklumat. Sistem kawalan versi membolehkan anda menyimpan berbilang versi dokumen yang sama, kembali kepada versi terdahulu jika perlu, tentukan siapa yang membuat perubahan tertentu dan bila, dan banyak lagi.

Sistem sedemikian paling banyak digunakan dalam pembangunan perisian untuk menyimpan kod sumber program yang sedang dibangunkan. Walau bagaimanapun, mereka boleh berjaya digunakan di kawasan lain di mana kerja dijalankan dengan sejumlah besar dokumen elektronik yang sentiasa berubah-ubah. Khususnya, sistem kawalan versi digunakan dalam CAD, biasanya sebagai sebahagian daripada sistem pengurusan data produk (PDM). Versi digunakan dalam alat pengurusan konfigurasi ( Alat Pengurusan Konfigurasi Perisian).

Kadangkala penciptaan versi baharu dilakukan tanpa disedari oleh pengguna (secara telus), sama ada oleh program aplikasi yang mempunyai sokongan terbina dalam untuk fungsi sedemikian, atau melalui penggunaan sistem fail khas. Dalam kes ini, pengguna hanya bekerja dengan fail seperti biasa, dan apabila menyimpan fail, versi baharu dibuat secara automatik.

Ia sering berlaku bahawa beberapa orang bekerja pada satu projek pada masa yang sama. Jika dua orang menukar fail yang sama, maka salah seorang daripada mereka mungkin membuat asal perubahan yang dibuat oleh yang lain secara tidak sengaja. Sistem kawalan versi menjejaki konflik tersebut dan menyediakan cara untuk menyelesaikannya. Kebanyakan sistem boleh menggabungkan (gabungan) perubahan secara automatik yang dibuat oleh pembangun yang berbeza. Walau bagaimanapun, penggabungan perubahan automatik sedemikian biasanya hanya boleh dilakukan untuk fail teks dan dengan syarat bahagian yang berlainan (tidak bertindih) fail ini telah ditukar. Had ini disebabkan oleh fakta bahawa kebanyakan sistem kawalan versi tertumpu pada menyokong proses pembangunan perisian, dan kod sumber program disimpan dalam fail teks. Jika penggabungan automatik gagal, sistem mungkin menawarkan untuk menyelesaikan masalah secara manual.

Selalunya tidak mungkin untuk melakukan gabungan sama ada secara automatik atau mod manual, sebagai contoh, jika format fail tidak diketahui atau terlalu rumit. Sesetengah sistem kawalan versi menyediakan keupayaan untuk mengunci fail dalam repositori. Kunci menghalang pengguna lain daripada mendapatkan salinan kerja atau menghalang salinan kerja fail daripada diubah suai (contohnya, melalui sistem fail) dan dengan itu memastikan akses eksklusif hanya kepada pengguna yang bekerja dengan dokumen.

Banyak sistem kawalan versi menyediakan beberapa ciri lain:

• Membolehkan anda mencipta varian yang berbeza satu dokumen, yang dipanggil cawangan, Dengan sejarah umum perubahan sebelum titik cawangan dan dengan yang berbeza selepasnya.
• Mereka membolehkan untuk mengetahui siapa dan bila ditambah atau menukar set baris tertentu dalam fail.
• Kekalkan log perubahan di mana pengguna boleh menulis penjelasan tentang perkara dan sebab mereka berubah dalam versi tertentu.
• Kawal hak akses pengguna, membenarkan atau menafikan membaca atau menukar data, bergantung pada orang yang meminta tindakan itu.

Prosedur biasa untuk bekerja dengan sistem

Setiap sistem kawalan versi mempunyai ciri khusus tersendiri dalam set arahan, cara pengguna bekerja dan pentadbiran. Namun begitu, perintah am kerja untuk kebanyakan VCS adalah stereotaip sepenuhnya. Di sini diandaikan bahawa projek itu, walau apa pun, sudah wujud dan repositorinya terletak pada pelayan, yang mana pemaju mendapat akses.

Bermula dengan projek

Langkah pertama yang mesti diambil oleh pembangun ialah mendapatkan salinan kerja projek atau bahagiannya yang akan diusahakan. Tindakan ini dilakukan menggunakan arahan versi ambil (biasanya daftar keluar atau klon). Pembangun menentukan versi yang perlu disalin; secara lalai, versi terkini (atau yang dipilih oleh pentadbir sebagai yang utama) biasanya disalin.

Menggunakan arahan pengekstrakan, sambungan diwujudkan dengan pelayan, dan projek (atau sebahagian daripadanya - salah satu direktori dengan subdirektori) dalam bentuk pepohon direktori dan fail disalin ke komputer pembangun. Amalan biasa adalah untuk menduplikasi salinan kerja: sebagai tambahan kepada direktori utama dengan projek, salinan lain daripadanya juga ditulis pada cakera tempatan (sama ada dalam direktori yang berasingan, dipilih khas, atau dalam subdirektori sistem projek utama pokok). Apabila bekerja pada projek, pembangun hanya menukar fail dalam salinan kerja utama. Salinan tempatan kedua disimpan sebagai rujukan, membolehkan anda menentukan pada bila-bila masa, tanpa menghubungi pelayan, perubahan yang telah dibuat pada fail tertentu atau projek secara keseluruhan dan dari versi mana salinan kerja itu "diputarkan" ; Sebagai peraturan, sebarang percubaan untuk menukar salinan ini secara manual membawa kepada ralat dalam pengendalian perisian VCS.

Kitaran kerja harian

Dengan beberapa variasi yang ditentukan oleh ciri sistem dan butiran proses teknologi yang diterima pakai, kitaran kerja biasa pembangun semasa hari bekerja kelihatan seperti ini.

Mengemas kini salinan kerja Apabila perubahan dibuat pada versi utama projek, salinan kerja pada komputer pembangun menjadi lama: percanggahannya dengan versi utama projek meningkat. Ini meningkatkan risiko perubahan yang bercanggah (lihat). Oleh itu, adalah mudah untuk mengekalkan salinan kerja dalam keadaan sedekat mungkin dengan versi utama semasa, yang mana pembangun melakukan operasi salinan kerja kemas kini ( kemas kini) sekerap mungkin (kekerapan sebenar kemas kini ditentukan oleh kekerapan perubahan, bergantung pada aktiviti pembangunan dan bilangan pembangun, serta masa yang dihabiskan untuk setiap kemas kini - jika ia besar, pemaju terpaksa hadkan kekerapan kemas kini agar tidak membuang masa). Pengubahsuaian projek Pembangun mengubah suai projek dengan menukar fail yang disertakan dalam salinan kerja mengikut spesifikasi projek. Kerja ini dilakukan secara tempatan dan tidak memerlukan panggilan ke pelayan VCS. Membaiki perubahan Setelah menyelesaikan peringkat kerja seterusnya pada tugas, pembangun melakukan ( komited) perubahan anda, memindahkannya ke pelayan (sama ada ke cawangan utama, jika kerja pada tugas selesai sepenuhnya, atau ke cawangan pembangunan berasingan tugas ini). VCS mungkin memerlukan pembangun untuk mengemas kini salinan kerja sebelum melakukan. Jika sistem menyokong perubahan tertunda ( rak) perubahan boleh dipindahkan ke pelayan tanpa melakukan. Jika dasar kerja yang diluluskan dalam VCS membenarkan ini, maka perubahan boleh direkodkan bukan setiap hari, tetapi hanya selepas selesai kerja pada tugas; dalam kes ini, semua perubahan yang berkaitan dengan kerja disimpan hanya dalam salinan kerja tempatan pembangun sehingga kerja selesai.

Bercabang

Anda boleh membuat pembetulan kecil dalam projek dengan mengedit terus salinan kerja dan kemudian melakukan perubahan terus ke cawangan utama (batang) pada pelayan. Walau bagaimanapun, apabila melakukan kerja berskala besar, pesanan ini menjadi menyusahkan: kekurangan rakaman perubahan perantaraan pada pelayan tidak membenarkan bekerja pada apa-apa dalam mod kumpulan; di samping itu, risiko kehilangan perubahan semasa kemalangan tempatan meningkat dan keupayaan untuk menganalisis dan kembali ke versi sebelumnya kod dalam kod yang diberikan hilang. kerja. Oleh itu, adalah menjadi amalan biasa untuk perubahan sedemikian untuk mewujudkan cawangan ( cawangan), iaitu, "tunas" dari batang dalam beberapa versi versi baru projek atau sebahagian daripadanya, pembangunan yang dijalankan selari dengan perubahan dalam versi utama. Cawangan dicipta oleh pasukan khas. Salinan kerja cawangan boleh dibuat semula dengan cara biasa (menggunakan arahan semak keluar kerja, menyatakan alamat atau pengecam cawangan), atau dengan menukar salinan kerja sedia ada kepada cawangan tertentu.

Kitaran kerja asas apabila menggunakan cawangan kekal sama seperti dalam kes umum: pembangun mengemas kini salinan kerja secara berkala (jika lebih daripada seorang bekerja di cawangan) dan melakukan kerja hariannya kepadanya. Kadangkala cawangan pembangunan kekal bebas (apabila perubahan menjana versi baharu projek yang dibangunkan lagi secara berasingan daripada yang utama), tetapi lebih kerap daripada tidak, apabila kerja yang mana cawangan itu dibuat selesai, cawangan itu disepadukan semula ke dalam batang (cabang utama). Ini boleh dilakukan dengan arahan gabungan (biasanya bercantum), atau dengan membuat tampalan ( tampalan), mengandungi perubahan yang dibuat semasa pembangunan cawangan dan menggunakan patch ini pada versi utama semasa projek.

Menggabungkan versi

Tiga jenis operasi yang dilakukan dalam kawalan versi boleh mengakibatkan keperluan untuk menggabungkan perubahan. ini:

• Mengemas kini salinan kerja (perubahan yang dibuat dalam versi utama digabungkan dengan yang tempatan).
• Melakukan perubahan (perubahan setempat digabungkan dengan perubahan yang telah dilakukan pada versi utama).
• Penggabungan cawangan (perubahan yang dibuat dalam satu cabang pembangunan digabungkan dengan perubahan yang dibuat di cabang yang lain).

Dalam semua kes, keadaan pada asasnya adalah sama dan mempunyai ciri ciri berikut:

1. Salinan fail repositori dan pepohon direktori atau sebahagian daripadanya telah dibuat sebelum ini.
2. Selepas itu, beberapa perubahan dibuat secara bebas pada pokok asal dan salinan.
3. Ia diperlukan untuk menggabungkan perubahan dalam asal dan salinan sedemikian rupa agar tidak memecahkan koheren logik projek dan tidak kehilangan data.

Agak jelas bahawa jika syarat (2) tidak dipenuhi (iaitu, jika perubahan dibuat hanya kepada yang asal atau hanya pada salinan), penggabungan adalah asas - ia cukup untuk menyalin bahagian yang diubah ke tempat yang tidak ada. perubahan. Jika tidak, penggabungan perubahan menjadi tugas yang tidak remeh, dalam banyak kes memerlukan campur tangan pembangun. Secara umum, mekanisme untuk menggabungkan perubahan secara automatik berfungsi berdasarkan prinsip berikut:

• Perubahan mungkin terdiri daripada mengubah suai kandungan fail, mencipta fail atau direktori baharu, atau memadam atau menamakan semula fail atau direktori yang sedia ada dalam projek itu.
• Jika dua perubahan merujuk kepada fail dan/atau direktori yang berbeza dan tidak berkaitan, ia sentiasa boleh digabungkan secara automatik. Penggabungan mereka ialah perubahan yang dibuat dalam setiap versi projek disalin ke dalam versi gabungan.
• Mencipta, memadam dan menamakan semula fail dalam direktori projek boleh digabungkan secara automatik selagi ia tidak bercanggah antara satu sama lain. Dalam kes ini, perubahan yang dibuat dalam setiap versi projek disalin ke versi gabungan. Yang bercanggah biasanya:
  • Memadam dan menukar fail atau direktori yang sama.
  • Memadam dan menamakan semula fail atau direktori yang sama (jika sistem menyokong operasi penamaan semula).
  • Mencipta versi fail yang berbeza dengan nama yang sama dan kandungan yang berbeza.
• Perubahan dalam fail teks yang sama yang dibuat dalam versi berbeza boleh digabungkan jika ia berada di tempat yang berbeza dalam fail dan tidak bertindih. Dalam kes ini, semua perubahan yang dibuat disertakan dalam versi gabungan.
• Perubahan dalam fail yang sama, melainkan ia adalah fail teks, sentiasa bercanggah dan tidak boleh digabungkan secara automatik.

Dalam semua kes versi asas untuk bergabung ialah versi di mana versi yang digabungkan telah dipecahkan. Jika ini adalah operasi komit, maka versi asas akan menjadi versi kemaskini terakhir sebelum komit, jika kemas kini - kemudian versi kemas kini sebelumnya, jika cawangan bergabung - maka versi di mana cawangan yang sepadan dicipta. Sehubungan itu, set perubahan yang dibandingkan ialah set perubahan yang dibuat dari asas kepada versi terkini dalam semua varian gabungan.

Sebilangan besar sistem kawalan versi moden tertumpu terutamanya pada projek pembangunan perisian di mana jenis kandungan fail utama ialah teks. Sehubungan itu, mekanisme untuk menggabungkan perubahan secara automatik tertumpu pada pemprosesan fail teks, iaitu fail yang mengandungi teks, yang terdiri daripada garisan aksara abjad angka, ruang dan tab, dipisahkan oleh baris baharu.

Apabila menentukan kebolehterimaan penggabungan perubahan dalam fail teks yang sama, mekanisme perbandingan teks baris demi baris standard berfungsi (contoh pelaksanaannya ialah utiliti sistem perbezaan GNU), yang membandingkan versi yang digabungkan dengan yang asas dan membina senarai perubahan, iaitu, menambah, memadam dan menggantikan set baris . Unit minimum Data untuk algoritma ini ialah rentetan; walaupun perbezaan terkecil menjadikan rentetan berbeza. Memandangkan aksara pembatas, dalam kebanyakan kes, tidak membawa sebarang beban semantik, mekanisme penggabungan boleh mengabaikan aksara ini apabila membandingkan rentetan.

Set rentetan diubah yang didapati tidak bersilang dianggap serasi dan penggabungannya dilakukan secara automatik. Jika fail yang digabungkan mengandungi perubahan yang mempengaruhi baris fail yang sama, ini membawa kepada konflik. Fail sedemikian hanya boleh digabungkan secara manual. Sebarang fail selain daripada fail teks adalah binari dari sudut pandangan VCS dan tidak membenarkan penggabungan automatik.

Konflik dan penyelesaiannya

Keadaan apabila, apabila menggabungkan beberapa versi, perubahan yang dibuat di dalamnya bersilang antara satu sama lain dipanggil konflik. Jika terdapat percanggahan perubahan, sistem kawalan versi tidak boleh membuat projek gabungan secara automatik dan terpaksa menghubungi pembangun. Seperti yang dinyatakan di atas, konflik boleh timbul pada peringkat melakukan perubahan, mengemas kini atau menggabungkan cawangan. Dalam semua kes, apabila konflik dikesan, operasi yang sepadan dihentikan sehingga ia diselesaikan.

Untuk menyelesaikan konflik, sistem, secara amnya, menawarkan pembangun tiga pilihan untuk fail bercanggah: asas, setempat dan pelayan. Perubahan bercanggah sama ada ditunjukkan kepada pembangun dalam modul perisian khas untuk menggabungkan perubahan (dalam kes ini, pilihan gabungan dan versi gabungan fail berubah secara dinamik bergantung pada arahan pengguna ditunjukkan), atau hanya ditandakan dengan penanda khas secara langsung dalam teks fail yang digabungkan (maka pembangun mesti menjana teks yang dikehendaki sendiri di kawasan yang dipertikaikan dan mengekalkannya).

Konflik dalam sistem fail diselesaikan dengan lebih mudah: hanya memadam fail boleh bercanggah dengan salah satu operasi lain, dan susunan fail dalam direktori tidak penting, jadi pembangun hanya boleh memilih operasi yang perlu disimpan dalam versi gabungan.

Kunci

Mekanisme penguncian membolehkan salah satu pembangun menggunakan fail atau kumpulan fail secara eksklusif untuk membuat perubahan padanya. Walaupun fail dikunci, ia kekal baca sahaja untuk semua pembangun lain, dan sebarang percubaan untuk membuat perubahan padanya ditolak oleh pelayan. Secara teknikal, penyekatan boleh diatur dengan cara yang berbeza. Mekanisme berikut adalah tipikal untuk sistem moden.

Penggunaan kunci secara besar-besaran, apabila semua atau kebanyakan fail dalam projek boleh dikunci dan untuk sebarang perubahan adalah perlu untuk mengunci set fail yang sepadan, juga dipanggil strategi "daftar keluar terkunci". Sistem awal kawalan versi menyokong strategi ini secara eksklusif, sekali gus menghalang konflik daripada timbul sejak awal. Dalam VCS moden, penggunaan perolehan tanpa sekatan lebih diutamakan, manakala sekatan dianggap lebih sebagai kejahatan yang perlu yang harus dihadkan apabila boleh. Kelemahan menggunakan kunci adalah jelas:

• Kunci hanya mengganggu produktiviti kerana ia memaksa anda menunggu fail terkunci dikeluarkan, walaupun dalam kebanyakan kes perubahan bersama Fail yang sama, yang dibuat semasa kerja dengan makna yang berbeza, tidak bersilang dan digabungkan secara automatik apabila bergabung.
• Kekerapan konflik dan kerumitan penyelesaiannya dalam kebanyakan kes tidak begitu besar sehingga menimbulkan kesulitan yang serius. Kemunculan konflik perubahan yang serius selalunya menandakan sama ada perbezaan pendapat yang ketara pemaju yang berbeza mengenai reka bentuk serpihan yang sama, atau mengenai organisasi kerja yang salah (apabila dua atau lebih pembangun melakukan perkara yang sama).
• Penyekatan menimbulkan masalah pentadbiran. Contoh biasa: pembangun mungkin terlupa membuka kunci fail yang dia sibuk semasa pergi bercuti. Untuk menyelesaikan masalah sedemikian, perlu menggunakan langkah pentadbiran, termasuk termasuk dalam sistem cara teknikal untuk menetapkan semula kunci yang salah, tetapi walaupun ia wujud, masa dihabiskan untuk menyusun sistem.

Sebaliknya, dalam beberapa kes penggunaan kunci agak wajar. Contoh yang jelas ialah organisasi kerja dengan fail binari yang tidak ada alatan penggabungan perubahan atau penggabungan sedemikian pada asasnya adalah mustahil (seperti, sebagai contoh, untuk fail imej). Jika penggabungan automatik tidak dapat dilakukan, maka dalam keadaan operasi biasa, sebarang perubahan selari pada fail yang serupa akan membawa kepada konflik. Dalam kes ini, adalah lebih mudah untuk membuat fail sedemikian boleh dikunci untuk memastikan bahawa sebarang perubahan padanya hanya akan dibuat secara berurutan.

Versi projek, tag

Sistem kawalan versi memastikan penyimpanan semua versi fail sedia ada dan, sebagai hasilnya, semua versi projek secara keseluruhan yang telah berlaku sejak permulaan pembangunannya. Tetapi konsep "versi" dalam sistem yang berbeza boleh ditafsirkan dalam dua cara.

Sesetengah sistem menyokong versi fail. Ini bermakna mana-mana fail yang muncul dalam projek menerima nombor versinya sendiri (biasanya nombor 1; versi "sifar" bersyarat bagi fail ialah fail kosong dengan nama yang sama). Setiap kali pembangun melakukan perubahan pada fail, bahagian yang sepadan daripada perubahan komited digunakan pada fail dan fail menerima nombor versi baharu, biasanya berurutan. Memandangkan komit biasanya hanya mempengaruhi sebahagian daripada fail dalam repositori, nombor versi fail yang tersedia pada masa yang sama berbeza mengikut masa dan projek secara keseluruhan (iaitu, keseluruhan set fail dalam repositori) tidak sebenarnya tidak mempunyai apa-apa "nombor versi", kerana ia terdiri daripada banyak fail dengan nombor versi yang berbeza. Sebagai contoh, sistem kawalan versi CVS berfungsi dengan cara yang sama.

Untuk sistem lain, konsep "versi" bukan merujuk kepada fail individu, tetapi kepada repositori sepenuhnya. Repositori kosong yang baru dibuat mempunyai versi 1 atau 0, sebarang perubahan yang dilakukan membawa kepada peningkatan dalam bilangan ini (iaitu, walaupun satu fail berubah sebanyak satu bait, keseluruhan repositori dianggap berubah dan menerima nombor versi baharu). Beginilah cara nombor versi ditafsirkan, contohnya, oleh sistem Subversion. Nombor versi fail individu di sini, sebenarnya, tidak wujud; kita boleh menganggap nombor versi semasa repositori secara bersyarat sedemikian (iaitu, anggap bahawa dengan setiap perubahan yang dibuat pada repositori, semua failnya menukar versi nombor, malah yang tidak berubah). Kadangkala, apabila bercakap tentang "versi fail" dalam sistem sedemikian, ia bermaksud versi repositori di mana fail itu terakhir diubah suai (sebelum masa yang menarik bagi kami).

Untuk tujuan praktikal, biasanya bukan fail individu yang penting, tetapi keseluruhan projek. Dalam sistem yang menyokong versi fail berasingan, untuk pengenalan versi tertentu projek, anda boleh menggunakan tarikh dan masa - maka versi projek akan terdiri daripada versi fail yang disertakan di dalamnya yang berada dalam repositori pada masa yang ditentukan. Jika versi repositori secara keseluruhan disokong, nombor versi projek boleh menjadi nombor versi repositori. Walau bagaimanapun, kedua-dua pilihan tidak begitu mudah, kerana tarikh mahupun nombor versi repositori biasanya tidak membawa maklumat tentang perubahan ketara dalam projek, tentang berapa lama dan intensif mereka mengusahakannya. Untuk menandakan versi projek (atau bahagiannya) dengan lebih mudah, sistem kawalan versi menyokong konsep tersebut tag.

Tag ialah label simbolik yang boleh dikaitkan dengan versi tertentu fail dan/atau direktori dalam repositori. Menggunakan arahan yang sesuai, semua atau sebahagian daripada fail projek yang memenuhi syarat tertentu (contohnya, termasuk dalam versi kepala cawangan utama projek pada masa tertentu) boleh diberikan label yang diberikan. Dengan cara ini, anda boleh mengenal pasti versi projek (versi "XX.XXX.XXX" ialah satu set versi fail repositori dengan teg "XX.XXX.XXX"), sekali gus membetulkan keadaannya pada masa yang dikehendaki. Sebagai peraturan, sistem penandaan agak fleksibel dan membolehkan anda menandai berbilang versi fail dan direktori dengan satu teg. Ini membolehkan anda membina "versi projek" dalam sebarang cara sewenang-wenangnya. Dari perspektif pengguna sistem, penandaan mungkin kelihatan berbeza. Dalam sesetengah sistem, ia digambarkan dengan tepat sebagai tanda (tag boleh dibuat, digunakan pada versi fail dan direktori tertentu, atau dialih keluar). Dalam sistem lain (contohnya, Subversion), teg hanyalah direktori berasingan dalam pepohon fail repositori, di mana salinan versi fail yang diperlukan dibuat daripada batang dan cawangan projek menggunakan arahan salin. Jadi secara visual, teg hanyalah salinan versi tertentu fail repositori yang diletakkan dalam direktori berasingan. Mengikut konvensyen, pepohon direktori yang sepadan dengan teg tidak dibenarkan untuk melakukan perubahan (iaitu, versi projek yang diwakili oleh teg tidak boleh diubah).

Prinsip asas pembangunan perisian dalam VCS

Prosedur untuk menggunakan sistem kawalan versi dalam setiap kes tertentu ditentukan oleh peraturan teknikal dan peraturan yang diterima pakai oleh syarikat atau organisasi tertentu yang membangunkan projek. Walau bagaimanapun, prinsip umum untuk penggunaan VCS yang betul adalah sedikit dan sama untuk semua pembangunan dan sistem kawalan versi.

1. Sebarang kerja, ujian atau versi demo projek dikumpul hanya dari repositori sistem. Binaan "peribadi", yang termasuk perubahan yang belum dilakukan, hanya boleh dilakukan oleh pembangun untuk tujuan ujian sementara. Ini memastikan bahawa repositori mengandungi semua yang diperlukan untuk mencipta versi kerja projek.
2. Versi semasa cawangan induk sentiasa betul. Ia tidak dibenarkan melakukan perubahan pada cawangan utama yang tidak lengkap atau yang belum lulus sekurang-kurangnya ujian awal. Pada bila-bila masa, membina projek daripada versi semasa harus berjaya.
3. Sebarang perubahan ketara hendaklah didokumenkan sebagai cawangan yang berasingan. Keputusan pertengahan Kerja pemaju komited untuk cawangan ini. Setelah perubahan selesai, cawangan digabungkan dengan batang. Pengecualian dibenarkan hanya untuk perubahan kecil, kerja yang dijalankan oleh satu pemaju dalam masa tidak lebih daripada satu hari bekerja.
4. Versi projek ditandakan dengan tag. Versi yang diserlahkan dan ditandakan tidak pernah diubah lagi.

Sistem kawalan versi teragih

ubah Buat perubahan tanpa membuat versi baharu - biasanya apabila pembangun tersilap melakukan ( komited) versi, tetapi tidak memuat naik ( menolak) kepada pelayan. salahkan Memahami siapa yang membuat perubahan. cawangan Cawangan ialah hala tuju pembangunan yang bebas daripada yang lain. Cawangan ialah salinan sebahagian (biasanya satu direktori) repositori yang mana anda boleh membuat perubahan anda sendiri tanpa menjejaskan cawangan lain. Dokumen dalam cawangan yang berbeza mempunyai sejarah yang sama sebelum titik cawangan dan yang berbeza selepasnya. set perubahan, senarai perubahan, aktiviti Satu set perubahan. Mewakili set suntingan bernama yang dibuat pada salinan tempatan untuk tujuan bersama. Dalam sistem yang menyokong set pengeditan, pembangun boleh mengumpulkan suntingan setempat dan melakukan perubahan yang berkaitan secara logik dengan satu perintah, menentukan set pengeditan yang diperlukan sebagai parameter. Walau bagaimanapun, suntingan lain akan kekal tidak dibetulkan. Contoh biasa: anda sedang berusaha untuk menambah fungsi baharu, dan pada masa ini ralat kritikal ditemui yang diperlukan segera. Pembangun membuat set perubahan untuk kerja yang telah dilakukan dan set baharu untuk pembetulan. Setelah selesai pembetulan ralat, arahan diberikan untuk melakukan hanya set kedua suntingan. daftar masuk, komit, serah Cipta versi baharu, lakukan perubahan. Dalam sesetengah SUV ( Subversion) - versi baharu dipindahkan secara automatik ke storan dokumen. daftar keluar, klon Mengambil semula dokumen daripada storan dan mencipta salinan berfungsi. konflik Konflik ialah situasi apabila beberapa pengguna membuat perubahan pada bahagian yang sama dalam dokumen. Konflik dikesan apabila seorang pengguna melakukan perubahannya, dan yang kedua cuba melakukannya, dan sistem itu sendiri tidak dapat menggabungkan perubahan yang bercanggah dengan betul. Memandangkan program mungkin tidak cukup pintar untuk menentukan perubahan yang "betul", pengguna kedua perlu menyelesaikan konflik itu sendiri ( azam). cantuman, backport, memetik ceri, pemindahan Gunakan algoritma penggabungan yang dibina ke dalam SUV untuk memindahkan perubahan individu ke cawangan lain tanpa menggabungkannya. Sebagai contoh, jika kami membetulkan pepijat dalam cawangan percubaan, kami membuat perubahan yang sama pada batang yang stabil. kepala Versi utama adalah yang paling versi terkini untuk cawangan/batang yang terletak di dalam simpanan. Terdapat banyak versi utama kerana terdapat cawangan. merge, integration Penggabungan ialah penggabungan perubahan bebas ke dalam satu versi dokumen. Berlaku apabila dua orang telah menukar fail yang sama atau apabila menolak perubahan dari satu cawangan ke cawangan yang lain. tarik, kemas kini Dapatkan versi baharu daripada repositori. Dalam sesetengah SUV ( Subversion) - berlaku dan tarik, Dan suis, iaitu, perubahan dimuatkan, dan kemudian salinan kerja dibawa ke keadaan terkini. berhati-hati, konsep kemas kini samar-samar dan dalam Subversion Dan Mercurial bermakna berbeza. tolak Muat naik versi baharu ke repositori. Banyak SUV yang diedarkan ( Git, Mercurial) anggap bahawa komited mesti diberikan setiap kali pengaturcara telah menyelesaikan beberapa fungsi lengkap. Dan muat naiknya apabila terdapat Internet dan orang lain mahukan perubahan anda. komited biasanya tidak memerlukan memasukkan nama pengguna dan kata laluan, dan menolak- tuntutan. rebase Gunakan algoritma cantum terbina dalam SUV untuk mengalihkan titik cawangan (versi dari mana cawangan itu bermula) ke versi batang kemudian. Paling kerap digunakan dalam senario ini: Boris telah membuat perubahan dan mendapati dia tidak boleh memuat naik ( menolak) mereka kerana sebelum ini Anna telah menukar tempat yang sama sekali berbeza dalam kod. Anda hanya boleh menggabungkan mereka ( bercantum). Tetapi pokok itu akan menjadi linear dan lebih mudah dibaca jika anda meninggalkan edisi anda, tetapi membuat perubahan yang sama pada edisi Anna - ini rebase. Jika Anna dan Boris sedang mengusahakan sekeping kod yang sama, menghalang satu sama lain dan menyelesaikan konflik secara manual, rebase Tidak digalakkan. repositori, depot Repositori Dokumen ialah tempat di mana sistem kawalan versi menyimpan semua dokumen bersama-sama dengan sejarah perubahannya dan maklumat perkhidmatan lain. semakan versi Dokumen. Sistem kawalan versi membezakan versi dengan nombor yang diberikan secara automatik. rak Perubahan rak. Sesetengah sistem menyediakan keupayaan untuk mencipta set perubahan dan menyimpannya pada pelayan tanpa melakukannya. Set tertunda perubahan tersedia untuk dibaca oleh ahli projek lain, tetapi tidak termasuk dalam cawangan utama sehingga pasukan khas berbuat demikian. Sokongan untuk menangguhkan perubahan membolehkan pengguna menyimpan kerja yang belum selesai pada pelayan tanpa membuat cawangan berasingan untuk ini. jalur Keluarkan keseluruhan cawangan daripada repositori. tag, label Label yang boleh diberikan kepada versi tertentu dokumen. Label ialah nama simbolik untuk sekumpulan dokumen, di mana label itu menerangkan bukan sahaja set nama fail, tetapi juga versi setiap fail. Versi dokumen yang disertakan dalam teg mungkin dimiliki oleh titik masa yang berbeza. trunk, mainline, master Trunk adalah cabang utama pembangunan projek. Dasar batang mungkin berbeza dari projek ke projek, tetapi secara amnya adalah seperti berikut: kebanyakan perubahan dibuat pada batang; jika perubahan besar diperlukan yang boleh membawa kepada ketidakstabilan, cawangan dicipta yang bergabung dengan batang apabila inovasi telah diuji secukupnya; Sebelum mengeluarkan versi seterusnya, cawangan dibuat untuk keluaran berikutnya, di mana hanya pembetulan dibuat. kemas kini, segerakkan, suis Menyegerakkan salinan kerja kepada beberapa keadaan storan tertentu. Selalunya, tindakan ini bermakna mengemas kini salinan kerja kepada keadaan terkini repositori. Walau bagaimanapun, jika perlu, anda boleh menyegerakkan salinan kerja ke keadaan yang lebih lama daripada keadaan semasa. salinan kerja Salinan dokumen kerja (tempatan).

lihat juga

• Perbandingan sistem kawalan versi (Pengurusan Konfigurasi Perisian), Ben Collins-Sussman (pencipta Subversion) pada sistem kawalan versi teragih.
• (Bahasa Inggeris) perbandingan sistem kawalan versi dari segi kesempurnaan proses pembangunan perisian.

Sistem kawalan versi merekod dan menyimpan berbilang perubahan pada fail. Ini membolehkan anda kembali ke titik tertentu dalam sejarah perubahan pada fail atau projek. Sesetengah sistem, seperti Subversion, menjejaki sejarah fail individu. Lain-lain, seperti Git dan Mercurial, menjejaki sejarah keseluruhan repositori.

Kawalan versi adalah seperti sistem keselamatan. Jika anda membuat perubahan yang kemudiannya menyebabkan masalah, anda boleh mengembalikan fail atau keseluruhan projek ke titik tertentu dan bukannya bermula dari awal.

Salah satu pilihan yang paling biasa digunakan ialah versi tempatan. Oleh itu, kebanyakan pengguna hanya tidak memberi perhatian kepadanya, kerana ia adalah salah satu daripada banyak fungsi aplikasi.

Setiap aplikasi melaksanakan sekurang-kurangnya tahap asas versi tempatan, yang terdiri daripada fungsi buat asal dan buat semula. Beberapa program seperti Microsoft Office dan Dokumen Google, mengandungi ciri yang lebih maju seperti perbandingan versi dan mengulas.

Sistem kawalan versi aplikasi dihadkan oleh jenis fail yang mereka sokong dan jumlah sejarah perubahan yang boleh mereka simpan. Sistem kawalan versi kendiri, sebaliknya, boleh menumpukan pada ciri yang lebih kompleks, menyimpan sejarah versi yang tidak terhingga dan tidak terhad kepada format tertentu. Walaupun sesetengah sistem lebih sesuai untuk fail tertentu. Atas sebab ini, mereka lebih popular dalam pengaturcaraan. Walaupun ia boleh digunakan untuk mengawal versi mana-mana fail, daripada dokumen teks asas kepada fail grafik yang besar.

Sistem kawalan versi dibahagikan kepada dua kategori: diedarkan dan berpusat. Masing-masing mempunyai kelebihan dan kekurangan tersendiri yang menjadikannya sesuai untuk aliran kerja yang berbeza. Setiap jenis termasuk banyak sistem yang berbeza. Sistem kawalan versi yang paling popular ialah Git, Subversion dan Mercurial. Mari kita lihat perbezaan utama antara kawalan versi teragih dan terpusat.

Versi diedarkan

Kawalan versi teragih juga dikenali sebagai kawalan semakan teragih. Ia dibina berdasarkan prinsip kesamaan nod. Selain itu, setiap nod rakan sebaya mempunyai klon repositorinya sendiri. Dengan pendekatan ini, sejarah pangkalan kod disalin, jadi sebarang kerosakan maut pada repositori asal, sisi pelayan boleh dipulihkan sepenuhnya daripada mana-mana klon yang tersedia. Walau bagaimanapun, dalam aliran kerja standard, perubahan pada repositori tidak menghasilkan kemas kini lengkap repositori. Sebaliknya, hanya perubahan yang dibuat kepada rakan sebaya dipaparkan, membolehkan anda melakukan operasi dengan cepat tanpa perlu menghubungi pelayan.

Kawalan versi teragih adalah popular terima kasih kepada sistem seperti Git dan Mercurial. Ia digunakan secara meluas untuk menganjurkan kerjasama dalam projek sumber terbuka. kod sumber. Oleh kerana sifat persediaan, pengklonan keseluruhan asas kod projek untuk setiap sistem rakan sebaya membolehkan lebih banyak kebebasan apabila melibatkan aliran kerja dan kerjasama.

Kawalan versi terpusat

Tidak seperti kawalan versi teragih dan kawalan versi tempatan, data dalam sistem kawalan versi terpusat ( C.V.C.), seperti Perforce dan Subversion, disimpan dalam repositori sebelah pelayan. Ini bermakna setiap nod menyemak fail dan melakukan perubahan kepada pangkalan data pusat.

Masalahnya ialah ketersediaan data. Memandangkan fail disimpan dalam storan pusat, jika pelayan ranap, tiada kerja boleh berlaku sehingga pelayan dimulakan semula. Lebih-lebih lagi, jika pelayan rosak, maka jika tiada salinan sandaran yang terkini, semua data mungkin hilang sepenuhnya.

Kelebihan utama sistem sedemikian ialah data disimpan di satu tempat. Ini memudahkan penyelenggaraan dan mengehadkan akses pengguna.

Kesimpulan

Kawalan versi ialah cara mudah untuk memantau perubahan pada fail dan projek. Walaupun sistem kawalan versi terutamanya dipasarkan sebagai alat untuk mengurus projek pembangunan perisian, ia boleh berguna untuk mengurus sebarang jenis fail.

Terjemahan artikel "Apakah itu kawalan versi" oleh pasukan projek yang mesra.

baik buruk

Dalam setiap operasi yang saya ukur, Mercurial berprestasi lebih baik daripada Subversion. Kelajuan adalah 2-6 kali lebih besar apabila ia datang ke tempatan Subversi 1.4.3 repositori (paling banyak kaedah cepat akses). Dalam kes penggunaan repositori rangkaian yang lebih realistik, Subversion berada dalam kedudukan yang lebih teruk. Oleh kerana arahan Subversion mesti berkomunikasi dengan pelayan, dan Subversion tidak mempunyai keupayaan replikasi yang berguna, prestasi pelayan dan lebar jalur rangkaian menjadi kesesakan walaupun untuk projek kecil.

Di samping itu, Subversion memerlukan ruang cakera tambahan untuk mengelakkan permintaan rangkaian semasa menjalankan operasi tertentu: mencari fail yang diubah suai (status) dan memaparkan perubahan (perbezaan). Akibatnya, salinan kerja Subversion adalah saiz yang sama (jika tidak lebih besar) daripada gabungan repositori Mercurial dan direktori kerja, walaupun repositori Mercurial mengandungi sejarah lengkap projek.

Subversion mempunyai sokongan alat yang luas pengeluar pihak ketiga. Dalam hal ini, Mercurial kini ketinggalan dengan ketara. Walaupun jurang semakin hampir, beberapa utiliti GUI untuk Mercurial lebih unggul daripada rakan Subversion mereka. Seperti Mercurial, Subversion mempunyai manual pengguna yang sangat baik.

Kerana Subversion tidak menyimpan sejarah perubahan pada klien, ia sangat sesuai untuk menguruskan projek yang mengandungi sejumlah besar fail binari. Jika anda membuat 50 perubahan pada fail sepuluh megabait yang tidak boleh dimampatkan, ruang cakera yang digunakan oleh Subversion akan kekal tidak berubah. Ruang yang digunakan oleh mana-mana sistem kawalan versi yang diedarkan akan meningkat dengan cepat mengikut kadar bilangan perubahan kerana perbezaan antara suntingan adalah besar.

Di samping itu, ia biasanya sukar, dan selalunya mustahil, untuk mengalir versi berbeza fail binari. Subversion membolehkan pengguna mengunci fail, yang memberikan hak eksklusif pengguna untuk membuat perubahan padanya buat sementara waktu. Ini boleh menjadi kelebihan yang ketara untuk projek yang menggunakan binari secara meluas.

Mercurial boleh mengimport sejarah perubahan daripada repositori Subversion. Proses sebaliknya juga mungkin. Ini memungkinkan untuk menguji perairan dan menggunakan Mercurial dan Subversion pada masa yang sama sebelum memutuskan sama ada untuk menukar atau tidak. Menukar sejarah ialah proses langkah demi langkah, jadi anda boleh melakukan penukaran awal dan kemudian membuat perubahan selanjutnya.

1.6.2. Git

Git ialah sistem kawalan versi teragih yang direka untuk pengurusan kod sumber Inti Linux. Seperti Mercurial, reka bentuk awal sistem dipengaruhi oleh Monotone.

Git menyediakan senarai besar arahan, yang bilangannya dalam versi 1.5.0 mencapai 139 unit unik. Ia mempunyai reputasi sebagai sukar untuk dipelajari. Berbanding dengan Git, Mercurial menekankan kesederhanaan.

Dari segi prestasi, Git sangat pantas. Dalam sesetengah kes ia lebih pantas daripada Mercurial (oleh sekurang-kurangnya di bawah Linux), manakala yang lain Mercurial lebih pantas. Walau bagaimanapun, pada Windows, kedua-dua tahap prestasi dan sokongan keseluruhan, pada masa penulisan, Git adalah lebih teruk daripada Mercurial.

Manakala repositori Mercurial tidak memerlukan sebarang operasi penyelenggaraan, repositori Git memerlukan manual yang kerap "mengemas semula" metadata sendiri. Jika anda tidak melakukan ini, prestasi mula menurun, bersama-sama dengan peningkatan dalam jumlah ruang cakera yang digunakan. Tatasusunan cakera pelayan yang mengandungi beberapa repositori Git, yang berkaitan dengan peraturan ketat kekerapan "mengemas semula", lambat laun akan tersumbat, menyebabkan proses sandaran harian mengambil masa lebih daripada 24 jam dengan mudah. tadi "berbungkus" repositori Git mengambil ruang kurang sedikit daripada repositori Mercurial, tetapi saiz repositori yang tidak dibungkus akan menjadi beberapa pesanan magnitud yang lebih besar.

Teras Git ditulis dalam C. Banyak arahan Git dilaksanakan dalam bentuk Skrip Shell atau skrip Perl, dan tahap kualiti skrip ini sangat berbeza. Saya telah melihat beberapa pemasangan di mana skrip terus berjalan walaupun ralat yang membawa maut.

Mercurial menyediakan keupayaan untuk mengimport sejarah versi daripada repositori Git.

1.6.3. CVS

CVS mungkin merupakan sistem kawalan versi yang paling banyak digunakan di dunia. Oleh kerana usianya yang mulia, serta kekacauan yang berlaku di dalamnya, ia telah diselenggara dengan sangat buruk selama bertahun-tahun.

CVS adalah berdasarkan seni bina pelayan pelanggan berpusat. Ia tidak melakukan pengelompokan perubahan fail ke dalam komitmen atom, dengan itu membolehkan orang ramai dengan mudah "pecahkan binaan": Seseorang boleh berjaya membuat sebahagian daripada perubahan pada repositori, dan kemudian terkunci kerana keperluan untuk melakukan gabungan. Ini akan membawa kepada situasi di mana peserta lain hanya akan melihat sebahagian kecil daripada perubahan yang sepatutnya mereka lihat. Ciri ini juga mempengaruhi cara anda bekerja dengan sejarah perubahan. Jika anda ingin mendapatkan semua perubahan yang dibuat oleh seorang ahli pasukan untuk menyelesaikan masalah tertentu, anda perlu menyemak secara manual perihalan dan tarikh perubahan yang dibuat untuk setiap fail yang terjejas (jika anda tahu fail yang terjejas).

CVS memperkatakan konsep cawangan dan teg yang agak mengelirukan, yang saya tidak akan cuba huraikan dalam buku ini. Ia tidak menyokong menamakan semula kedua-dua fail dan folder, jadi repositori boleh rosak dengan mudah. Memandangkan mekanisme pemantauan integriti dalaman hampir tiada, selalunya mustahil untuk mengatakan dengan pasti sama ada repositori itu rosak, dan jika ya, maka bagaimana. Oleh itu, saya tidak akan mengesyorkan CVS untuk digunakan dalam mana-mana projek sedia ada atau baharu.

Mercurial menyediakan keupayaan untuk mengimport sejarah versi CVS. Walau bagaimanapun, terdapat beberapa masalah di sini yang turut dihadapi oleh mana-mana alat import CVS yang lain. Kekurangan perubahan atom dan versi data sistem fail hierarki menjadikannya mustahil untuk membina semula sejarah perubahan CVS dengan tepat, jadi andaian dibuat dalam beberapa kes dan nama semula biasanya tidak ditunjukkan. Memandangkan banyak tugas pentadbiran CVS mesti dilakukan secara manual, yang meningkatkan risiko ralat, adalah perkara biasa bagi alat import CVS untuk mengembalikan banyak ralat integriti repositori (tarikh dan fail perubahan versi yang tidak realistik sepenuhnya yang kekal terkunci selama sepuluh tahun yang lalu - ini hanyalah beberapa masalah yang paling kurang menarik yang saya boleh ingat daripada pengalaman saya sendiri).

«

1.8. Sejarah Ringkas Kawalan Versi

Utiliti kawalan versi lama yang paling terkenal ialah SCCS (Sistem Kawalan Kod Sumber), yang ditulis oleh Marc Rochkind dari Bell Labs pada awal 70-an. SCCS beroperasi pada fail individu dan memerlukan setiap orang yang bekerja pada projek mempunyai akses kepada satu ruang kerja yang dikongsi. Hanya seorang yang boleh mengedit fail pada satu masa; konflik akses fail telah diselesaikan menggunakan kunci. Situasi biasa ialah terlupa untuk mengalih keluar kunci selepas mengedit, yang menghalang orang lain daripada mengakses fail tanpa bantuan pentadbir.

Walter Tichy membangunkan alternatif percuma kepada SCCS pada awal 1980-an; beliau memanggil programnya RCS (Revision Control System). Seperti SCCS, RCS memerlukan pembangun untuk bekerja dalam satu ruang kerja kongsi dan mengunci fail untuk menghalang orang yang berbeza daripada menukar fail pada masa yang sama.

Kemudian, pada tahun 1980-an, Dick Grune menggunakan RCS sebagai asas untuk satu set skrip shell, pada mulanya dipanggil cmt, dan kemudiannya dinamakan semula sebagai CVS (Concurrent Versions System). Inovasi besar CVS ialah ia membenarkan pembangun bekerja secara serentak dan, sedikit sebanyak, secara bebas di ruang kerja peribadi mereka sendiri. Ruang ini menghalang pembangun daripada sentiasa memijak jari kaki satu sama lain, yang merupakan perkara biasa di SCCS dan RCS. Setiap pembangun mempunyai salinan setiap fail projek, dan pembangun boleh mengubah suai salinan mereka secara bebas. Mereka terpaksa menggabungkan suntingan mereka sendiri sebelum menyerahkan perubahan kepada repositori pusat.

Brian Berliner mengambil skrip asal Gruen dan menulisnya semula dalam C, mengeluarkan kod pada tahun 1989 yang kemudiannya akan berkembang menjadi versi moden CVS. CVS kemudiannya memperoleh keupayaan untuk bekerja melalui rangkaian, memperoleh seni bina pelayan-pelanggan. Seni bina CVS berpusat: hanya pelayan mempunyai salinan sejarah projek. Salinan kerja pelanggan hanya mengandungi contoh fail versi terkini dan sejumlah kecil metadata untuk mencari pelayan. CVS telah mencapai kejayaan yang tidak pernah berlaku sebelum ini: ia mungkin sistem kawalan versi yang paling banyak digunakan di dunia.

Pada awal 1990-an, Sun Microsystems membangunkan sistem kawalan versi teragih awal yang dipanggil TeamWare. Setiap salinan kerja TeamWare mengandungi salinan lengkap sejarah perubahan projek. Tiada konsep repositori pusat dalam TeamWare seperti itu. (Seperti CVS menggunakan RCS untuk menyimpan sejarah, TeamWare menggunakan SCCS.)

Apabila tahun 1990-an berkembang, kesedaran tentang beberapa masalah dengan CVS meningkat. Sistem menulis perubahan serentak kepada berbilang fail secara berasingan, dan bukannya menghimpunkannya ke dalam satu operasi atom secara logik. Kaedah kawalan hierarki fail tidak begitu baik: mudah untuk membuat kekacauan repositori dengan menamakan semula fail dan direktori. Selain itu, kod sumber CVS tidak mudah difahami dan diselenggara, menjadikannya hampir tidak dapat diatasi "ambang kesakitan" pembetulan untuk isu seni bina ini.

Pada tahun 2001, Jim Blandy dan Karl Fogel—dua pembangun yang pernah bekerja pada CVS sebelum ini—memulakan projek untuk menggantikannya dengan alat yang mempunyai seni bina yang lebih baik dan kod yang lebih bersih. Hasilnya, Subversion, tidak beralih daripada model pelayan pelanggan berpusat CVS, tetapi menambahkan komit atom berbilang fail, pengurusan ruang nama yang lebih baik dan ciri lain yang menjadikan Subversion alat yang lebih mudah untuk digunakan berbanding CVS. Sejak keluaran versi pertamanya, Subversion telah dengan cepat mendapat populariti.

Lebih kurang serentak, Graydon Hoare mula mengusahakan sistem kawalan versi bercita-cita tinggi yang dipanggilnya Monotone. Sistem ini bukan sahaja menghapuskan banyak masalah peranti dalaman CVS mempunyai seni bina teragih, tetapi ia juga lebih jauh daripada beberapa sistem kawalan versi sebelumnya (dan seterusnya) dalam beberapa inovasinya. Monotone menggunakan cincang kriptografi sebagai pengecam dan mempunyai pemahaman yang wujud tentang " amanah" kod daripada pelbagai sumber.

Kehidupan Mercurial bermula pada tahun 2005. Walaupun beberapa aspek seni binanya dipengaruhi oleh Monotone, Mercurial memfokuskan pada kemudahan penggunaan, prestasi tinggi dan kebolehskalaan kepada projek yang sangat besar.

Gambaran keseluruhan sistem kawalan versi

Sistem kawalan versi telah menjadi bahagian penting dalam kehidupan bukan sahaja pembangun perisian, tetapi juga semua orang yang berhadapan dengan masalah mengurus maklumat yang berubah secara intensif dan ingin menjadikan kehidupan mereka lebih mudah. Akibatnya, ia muncul nombor besar pelbagai produk yang ditawarkan peluang yang banyak dan menyediakan alat kawalan versi yang meluas. Artikel ini akan membincangkan secara ringkas yang paling popular daripada mereka, menyenaraikan kelebihan dan kekurangan mereka.

Sebagai perbandingan, sistem kawalan versi yang paling biasa telah dipilih: RCS, CVS, Subversion, Aegis, Monoton, Git, Bazaar, Arch, Perforce, Mercurial, TFS.

RCS ialah sistem pengurusan semakan versi.
(www.gnu.org/software/rcs/rcs.html)

Mari mulakan ulasan kami dengan salah satu sistem kawalan versi pertama - RCS (Sistem Kawalan Semakan), yang dibangunkan pada tahun 1985. Ia menggantikan sistem kawalan versi SCCS (Source Code Control System), yang popular pada masa itu.

Pada masa ini, RCS sedang giat digantikan oleh sistem kawalan versi CVS yang lebih berkuasa, tetapi masih agak popular dan merupakan sebahagian daripada projek GNU.

RCS membenarkan anda bekerja hanya dengan fail individu, mencipta sejarah perubahan untuk setiap fail. Untuk fail teks, tidak semua versi fail disimpan, hanya versi terkini dan semua perubahan yang dibuat padanya. RCS juga boleh menjejaki perubahan pada fail binari, tetapi setiap perubahan disimpan sebagai versi fail yang berasingan.

Apabila seorang pengguna membuat perubahan pada fail, fail itu kekal dikunci untuk orang lain. Mereka tidak boleh memintanya daripada repositori untuk mengedit sehingga pengguna pertama selesai dan melakukan perubahan.

Mari kita lihat kelebihan dan kekurangan utama sistem kawalan versi RCS.

Kelebihan:

1. RCS - mudah digunakan dan sangat sesuai untuk membiasakan diri dengan prinsip operasi sistem kawalan versi.

2. Sangat sesuai untuk membuat sandaran fail individu yang tidak memerlukan pengubahsuaian yang kerap oleh sekumpulan pengguna.

3. Diedarkan secara meluas dan diprapasang dalam kebanyakan perisian percuma sistem operasi Oh.

Kelemahan:

1. Jejaki perubahan hanya kepada fail individu, yang tidak membenarkannya digunakan untuk kawalan versi projek besar.

2. Tidak membenarkan berbilang pengguna membuat perubahan pada fail yang sama pada masa yang sama.

3. Kefungsian rendah berbanding sistem kawalan versi moden.

Kesimpulan:

Sistem kawalan versi RCS menyediakan set alat yang terlalu lemah untuk mengurus projek yang dibangunkan dan hanya sesuai untuk membiasakan diri dengan teknologi kawalan versi atau mengekalkan sejarah kecil pemulangan semula fail individu.

CVS ialah sistem kawalan versi selari.
(www.nongnu.org/cvs)

Sistem Versi Serentak ialah pembangunan logik sistem kawalan semakan (RCS), menggunakan piawaian dan algoritma kawalan versinya, tetapi lebih berfungsi, dan membolehkan anda bekerja bukan sahaja dengan fail individu, tetapi juga dengan keseluruhan projek.

CVS adalah berdasarkan teknologi pelanggan-pelayan yang berinteraksi melalui rangkaian. Pelanggan dan pelayan juga boleh ditempatkan pada mesin yang sama jika hanya seorang yang bekerja pada projek itu, atau jika anda perlu menyelenggara kawalan tempatan versi.

CVS berfungsi seperti berikut. Versi terkini dan semua perubahan yang dibuat disimpan dalam repositori pelayan. Pelanggan yang menyambung ke pelayan menyemak perbezaan versi tempatan daripada versi terkini yang disimpan dalam repositori, dan jika terdapat perbezaan, muat naiknya ke projek tempatan anda. Jika perlu, selesaikan konflik dan buat perubahan yang diperlukan pada produk yang dibangunkan. Selepas ini, semua perubahan dimuat naik ke repositori pelayan. CVS, jika perlu, membolehkan anda melancarkan semula versi projek yang diingini yang sedang dibangunkan dan mengurus beberapa projek secara serentak.

Berikut adalah kelebihan dan kekurangan utama sistem kawalan versi selari.

Kelebihan:

1. Berbilang pelanggan boleh bekerja pada projek yang sama pada masa yang sama.

2. Membolehkan anda mengurus bukan sahaja satu fail, tetapi keseluruhan projek.

3. Ia mempunyai sejumlah besar antara muka grafik yang mudah yang boleh memuaskan hati hampir semua orang, walaupun rasa yang paling mencabar.

4. Digunakan secara meluas dan datang secara lalai dengan kebanyakan sistem pengendalian Linux.

5. Apabila memuat turun fail ujian dari repositori, hanya perubahan dipindahkan, dan bukan keseluruhan fail.

Kelemahan:

1. Apabila anda mengalihkan atau menamakan semula fail atau direktori, semua perubahan yang berkaitan dengan fail atau direktori ini hilang.

2. Kesukaran dalam mengekalkan beberapa cabang selari projek yang sama.

3. Sokongan fon terhad.

4. Untuk setiap perubahan kepada fail binari, keseluruhan versi fail disimpan, bukan hanya perubahan yang dibuat.

5. Fail yang diubah suai sentiasa dipindahkan sepenuhnya daripada klien ke pelayan.

6. Operasi intensif sumber, kerana ia memerlukan akses yang kerap kepada repositori, dan salinan yang disimpan mempunyai sedikit redundansi.

Kesimpulan:

Walaupun CVS sudah lapuk dan cacat serius, ia masih antara yang paling banyak sistem popular kawalan versi dan bagus untuk menguruskan projek kecil yang tidak memerlukan penciptaan berbilang versi selari yang perlu digabungkan secara berkala. CVS boleh disyorkan sebagai langkah perantaraan dalam menguasai pengendalian sistem kawalan versi, yang membawa kepada jenis program sedemikian yang lebih berkuasa dan moden.

Sistem kawalan versi subversi.
(www.subversion.tigris.org)

Subversion ialah sistem kawalan versi terpusat yang dicipta pada tahun 2000 dan berdasarkan teknologi pelayan-pelanggan. Ia mempunyai semua kelebihan CVS dan menyelesaikan masalah utamanya (menamakan semula dan memindahkan fail dan direktori, bekerja dengan fail binari dan lain-lain.). Ia sering dipanggil dengan nama bahagian pelanggan - SVN.

Prinsip bekerja dengan Subversion sangat serupa dengan bekerja dengan CVS. Pelanggan menyalin perubahan daripada repositori dan menggabungkannya ke dalam projek tempatan pengguna. Jika konflik timbul perubahan setempat dan perubahan disimpan dalam repositori, maka situasi sedemikian diselesaikan secara manual. Perubahan kemudiannya dibuat pada projek tempatan dan hasilnya disimpan dalam repositori.

Apabila bekerja dengan fail yang tidak membenarkan perubahan digabungkan, prinsip berikut boleh digunakan:

1. Fail dimuat turun dari repositori dan disekat (memuat turunnya dari repositori adalah dilarang).

2. Perubahan yang perlu dibuat.

3. Fail dimuat naik ke repositori dan dibuka kuncinya (pelanggan lain dibenarkan memuat turunnya dari repositori).

Sebahagian besarnya kerana kesederhanaan dan persamaan dalam pengurusan dengan CVS, tetapi terutamanya kerana fungsinya yang luas, Subversion berjaya bersaing dengan CVS malah berjaya menggantikannya.

Walau bagaimanapun, Subversion juga mempunyai kelemahannya. Mari kita lihat kekuatan dan kelemahannya untuk dibandingkan dengan sistem kawalan versi lain.

Kelebihan:

1. Sistem arahan serupa dengan CVS.

2. Kebanyakan ciri CVS disokong.

3. Pelbagai antara muka grafik dan kerja mudah daripada konsol.

4. Sejarah perubahan pada fail dan direktori dijejaki walaupun selepas ia dinamakan semula dan dialihkan.

5. Kecekapan tinggi bekerja dengan kedua-dua fail teks dan binari.

6. Sokongan terbina dalam banyak alat pembangunan bersepadu seperti KDevelop, Zend Studio dan banyak lagi.

7. Kemungkinan mencipta salinan cermin repositori.

8. Dua jenis repositori - pangkalan data atau satu set fail biasa.

9. Keupayaan untuk mengakses repositori melalui Apache menggunakan protokol WebDAV.

10. Ketersediaan mekanisme yang mudah untuk mencipta label dan cawangan projek.

11. Anda boleh mengaitkan set sifat tertentu dengan setiap fail dan direktori, memudahkan interaksi dengan sistem kawalan versi.

12. Pengedaran yang meluas memungkinkan untuk menyelesaikan dengan cepat kebanyakan masalah yang timbul dengan beralih kepada data yang terkumpul oleh komuniti Internet.

Kelemahan:

1. Salinan lengkap repositori disimpan pada komputer tempatan dalam fail tersembunyi, yang memerlukan jumlah memori yang agak besar.

2. Terdapat masalah dengan menamakan semula fail jika fail yang dinamakan semula secara setempat oleh satu klien pada masa yang sama diubah suai oleh klien lain dan dimuat naik ke repositori.

3. Sokongan yang lemah untuk menggabungkan cawangan projek.

4. Kesukaran memadam sepenuhnya maklumat tentang fail dalam repositori, kerana ia sentiasa mengandungi maklumat tentang perubahan sebelumnya pada fail, dan tiada cara standard untuk memadam sepenuhnya data tentang fail daripada repositori.

Kesimpulan:

Subversion ialah sistem kawalan versi moden yang mempunyai pelbagai alat untuk memenuhi sebarang keperluan untuk mengurus versi projek menggunakan sistem kawalan berpusat. Terdapat banyak sumber di Internet khusus untuk ciri Subversion, yang membolehkan anda menyelesaikan semua masalah yang timbul semasa kerja anda dengan cepat dan cekap.

Kemudahan pemasangan, penyediaan untuk kerja dan keupayaan yang mencukupi membolehkan subversi untuk mengambil salah satu kedudukan utama dalam perlumbaan kompetitif sistem kawalan versi.

Sistem kawalan versi Aegis.

Aegis, dicipta oleh Peter Miller pada tahun 1991, adalah alternatif pertama kepada sistem kawalan versi terpusat. Semua operasi di dalamnya dijalankan melalui sistem fail Unix. Malangnya, Aegis tidak mempunyai sokongan rangkaian terbina dalam, tetapi interaksi boleh dijalankan menggunakan protokol seperti NFS, HTTP, FTP.

Ciri utama Aegis ialah cara ia mengawal perubahan yang dibuat pada repositori.

Pertama, sebelum membuat sebarang perubahan, mereka mesti lulus beberapa ujian. Dan jika inovasi dalam kod sumber program tidak lulus ujian, maka perlu sama ada menambah ujian baharu atau membetulkan kemungkinan ralat dalam kod sumber.

Kedua, sebelum perubahan dibuat kepada cawangan utama projek yang sedang dibangunkan, ia mesti diluluskan oleh penyemak.

Ketiga, hierarki akses kepada repositori disediakan, berdasarkan sistem hak akses sistem pengendalian seperti Unix kepada fail.

Semua ini menjadikan penggunaan sistem kawalan versi Aegis boleh dipercayai, tetapi amat sukar, malah dokumentasi yang baik tidak menjadikannya lebih mudah.

Mari kita serlahkan kelebihan dan kekurangan utama sistem kawalan versi Aegis.

Kelebihan:

1. Kawalan yang boleh dipercayai terhadap ketepatan perubahan yang dimuatkan.

2. Keupayaan untuk menyediakan tahap akses yang berbeza kepada fail repositori, yang menyediakan tahap keselamatan yang baik.

3. Dokumentasi berkualiti tinggi.

4. Keupayaan untuk menamakan semula fail yang disimpan dalam repositori tanpa kehilangan sejarah perubahan.

5. Keupayaan untuk bekerja dengan repositori tempatan jika tiada akses rangkaian ke repositori utama.

Kelemahan:

1. Kekurangan sokongan terbina dalam untuk interaksi rangkaian.

2. Kesukaran menyediakan dan bekerja dengan repositori.

3. Antara muka grafik yang lemah.

Kesimpulan:

Kerumitan Aegis mungkin tidak menggalakkan pengguna daripada menggunakan sistem kawalan versi, jadi ia tidak disyorkan untuk rujukan atau untuk projek perisian kecil. Walau bagaimanapun, ia mempunyai beberapa kelebihan yang boleh berguna dalam beberapa situasi tertentu, terutamanya apabila kawalan ketat ke atas kualiti perisian yang dibangunkan diperlukan.

Sistem kawalan versi monoton.
(monotone.ca)

Monotone ialah satu lagi sistem kawalan versi terdesentralisasi yang dibangunkan oleh Graydon Hoem. Di dalamnya, setiap pelanggan bertanggungjawab untuk menyegerakkan versi produk yang dibangunkan dengan pelanggan lain.

Bekerja dengan sistem kawalan versi ini agak mudah, dan banyak arahan serupa dengan arahan yang digunakan dalam Subversion dan CVS. Perbezaan terutamanya terletak pada organisasi penggabungan cawangan projek daripada pemaju yang berbeza.

Bekerja dengan Monotone distrukturkan seperti berikut. Pertama, pangkalan data projek SQLite dibuat dan kunci dijana menggunakan algoritma pencincangan SHA1 (Secure Hash Algorithm 1).

Kemudian, semasa pengguna mengedit projek, semua perubahan disimpan dalam pangkalan data ini, sama seperti menyimpan perubahan dalam repositori sistem kawalan versi lain.

Untuk menyegerakkan projek dengan pengguna lain, anda perlu:

Eksport kunci (kod cincang versi terkini projek) dan terima kunci serupa daripada pelanggan lain.

Kini semua orang yang mendaftar dengan cara ini boleh menyegerakkan pembangunan dengan rakan sekerja mereka menggunakan satu set arahan yang mudah.

Mari kita ringkaskan kelebihan dan kekurangan sistem kawalan versi Monotone.

Kelebihan:

1. Satu set arahan yang ringkas dan jelas, serupa dengan arahan Subversion dan CVS.

2. Menyokong menamakan semula dan memindahkan fail dan direktori.

3. Dokumentasi berkualiti tinggi, yang sangat memudahkan penggunaan sistem kawalan versi.

Kelemahan:

1. Kelajuan rendah.

2. Kurang berkuasa cengkerang grafik.

3. Kemungkinan padanan (tetapi sangat rendah) kod cincang semakan yang berbeza dalam kandungan.

Kesimpulan:

Monotone ialah alat yang berkuasa dan mudah untuk mengurus versi projek yang sedang dibangunkan. Set arahan difikirkan dengan baik dan intuitif, terutamanya mudah untuk pengguna yang biasa bekerja dengan Subversion dan CVS. Dokumentasi yang direka dengan baik dan lengkap akan membolehkan anda membiasakan diri dengan cepat dan menggunakan semua ciri Subversion dengan potensi penuhnya.

Walau bagaimanapun, kelajuan kerja yang agak rendah dan kekurangan cengkerang grafik yang berkuasa boleh menyebabkan kerja dengan projek besar agak sukar. Oleh itu, jika anda memerlukan sistem kawalan versi untuk menyokong produk yang kompleks dan besar, anda harus melihat Git atau Mercurial.

Sistem kawalan versi Git.
(www.git-scm.com)

Sejak Februari 2002, kebanyakan pengaturcara mula menggunakan sistem kawalan versi BitKeeper untuk membangunkan kernel Linux. Cukup untuk masa yang lama Tiada masalah dengannya, tetapi pada tahun 2005 Larry McVoy (pembangun BitKeeper) telah menarik balik versi percuma program tersebut.

Adalah mustahil untuk membangunkan projek berskala Linux tanpa sistem kawalan versi yang berkuasa dan boleh dipercayai. Salah satu calon dan projek yang paling sesuai ialah sistem kawalan versi Monotine, tetapi Torvalds Linus tidak berpuas hati dengan kelajuannya. Oleh kerana keanehan organisasi Monatone tidak membenarkan peningkatan ketara dalam kelajuan pemprosesan data, pada 3 April 2005 Linus mula membangun sistem sendiri kawalan versi - Git.

Hampir serentak dengan Linus (tiga hari kemudian), Matt Makal juga mula membangunkan sistem kawalan versi baharu. Matt memanggil projeknya Mercurial, tetapi lebih lanjut mengenainya kemudian, tetapi sekarang mari kita kembali ke sistem kawalan versi teragih Git.

Git ialah sistem kawalan versi yang fleksibel, diedarkan (tanpa pelayan tunggal) yang memberikan banyak peluang bukan sahaja kepada pembangun perisian, tetapi juga kepada penulis untuk menukar, menambah dan menjejaki perubahan pada "manuskrip" dan jalan cerita, dan untuk guru menyesuaikan dan membangunkan kursus kuliah, dan pentadbir untuk dokumentasi, dan untuk banyak bidang lain yang memerlukan pengurusan sejarah perubahan.

Setiap pembangun yang menggunakan Git mempunyai repositori tempatan mereka sendiri, membenarkan kawalan versi tempatan. Kemudian, data yang disimpan dalam repositori tempatan boleh ditukar dengan pengguna lain.

Selalunya apabila bekerja dengan Git, anda membuat repositori pusat yang disegerakkan oleh pembangun lain. Contoh penyusunan sistem dengan repositori pusat ialah projek pembangunan kernel Linux (http://www.kernel.org).

Dalam kes ini, semua peserta projek menjalankan pembangunan tempatan mereka dan memuat turun kemas kini secara bebas daripada repositori pusat. Apabila kerja yang diperlukan telah disiapkan dan dinyahpepijat oleh peserta projek individu, mereka, selepas pemilik repositori pusat telah memperakui bahawa kerja yang dilakukan adalah betul dan terkini, memuat naik perubahan mereka ke repositori pusat.

Mempunyai repositori tempatan juga meningkatkan kebolehpercayaan storan data dengan ketara, kerana jika salah satu repositori gagal, data itu boleh dipulihkan dengan mudah daripada repositori lain.

Kerja pada versi projek dalam Git boleh dijalankan di beberapa cawangan, yang kemudiannya boleh digabungkan sepenuhnya atau sebahagiannya dengan mudah, dimusnahkan, digulung semula dan dikembangkan menjadi lebih banyak cawangan baharu projek.

Kami boleh membincangkan keupayaan Git untuk masa yang lama, tetapi untuk ringkas dan pemahaman yang lebih mudah, kami akan membentangkan kelebihan dan kekurangan utama sistem kawalan versi ini

Kelebihan:

1. Sistem yang boleh dipercayai untuk membandingkan semakan dan menyemak ketepatan data, berdasarkan algoritma pencincangan SHA1 (Algoritma Hash Selamat 1).

2. Sistem fleksibel untuk projek cawangan dan penggabungan cawangan antara satu sama lain.

3. Kehadiran repositori tempatan yang mengandungi maklumat lengkap tentang semua perubahan membolehkan anda mengekalkan kawalan versi tempatan penuh dan memuat naik hanya perubahan yang disahkan sepenuhnya ke repositori utama.

4. Prestasi tinggi dan kelajuan kerja.

5. Set arahan yang mudah dan intuitif.

6. Banyak cengkerang grafik yang membolehkan anda bekerja dengan cepat dan cekap dengan Git.

7. Kebolehan melakukan titik kawalan, di mana data disimpan tanpa pemampatan delta, tetapi sepenuhnya. Ini membolehkan anda mengurangkan kelajuan pemulihan data, kerana titik kawalan terdekat diambil sebagai asas, dan pemulihan sedang dijalankan dari dia. Jika pusat pemeriksaan tiada, projek besar boleh mengambil masa berjam-jam untuk pulih.

8. Pengedaran meluas, kebolehcapaian mudah dan dokumentasi berkualiti tinggi.

9. Fleksibiliti sistem membolehkan anda mengkonfigurasinya dengan mudah dan juga mencipta kawalan sistem khusus atau antara muka pengguna berdasarkan git.

10. Akses rangkaian universal menggunakan protokol http, ftp, rsync, ssh, dsb.

Kelemahan:

1. Unix - orientasi. Pada masa ini tiada pelaksanaan Git matang yang serasi dengan sistem pengendalian lain.

2. Kemungkinan (tetapi sangat rendah) padanan kod cincang semakan yang berbeza dalam kandungan.

3. Perubahan pada fail individu tidak dijejaki, tetapi hanya pada keseluruhan projek, yang boleh menyusahkan apabila bekerja dengan projek besar yang mengandungi banyak fail terputus sambungan.

4. Apabila pada mulanya mencipta repositori dan menyegerakkannya dengan pembangun lain, anda memerlukan cukup masa yang lama untuk memuat turun data, terutamanya jika projek itu besar, kerana anda perlu menyalin keseluruhan repositori ke komputer tempatan anda.

Kesimpulan:

Git ialah sistem kawalan versi yang fleksibel, mudah dan berkuasa yang boleh memuaskan hati sebahagian besar pengguna. Kekurangan sedia ada dihapuskan secara beransur-ansur dan tidak dibawa masalah yang serius pengguna. Jika anda menjalankan projek besar, jauh dari segi geografi, dan lebih-lebih lagi, jika anda sering perlu membangunkan perisian tanpa akses kepada pembangun lain (contohnya, anda tidak mahu membuang masa semasa terbang dari negara ke negara atau semasa berulang-alik ke kerja), anda boleh melakukan sebarang perubahan dan menyimpannya dalam repositori tempatan, rollback, bertukar antara cawangan, dll.). Git ialah salah satu peneraju dalam sistem kawalan versi.

Sistem kawalan versi merkuri.
(mercurial.selenic.com)

Sistem kawalan versi teragih Mercurial telah dibangunkan oleh Matt Macal selari dengan sistem kawalan versi Git yang dicipta oleh Torvalds Linus.

Pada asalnya, ia dicipta untuk pengurusan yang berkesan projek besar di bawah Linux, dan oleh itu tertumpu pada kerja yang pantas dan boleh dipercayai dengan repositori yang besar. Pada masa ini, mercurial disesuaikan untuk berfungsi di bawah Windows, Mac OS X dan kebanyakan sistem Unix.

Kebanyakan sistem kawalan versi ditulis dalam Python, dan hanya bahagian tertentu program yang memerlukan prestasi terbaik ditulis dalam C.

Semakan dikenal pasti berdasarkan algoritma pencincangan SHA1 (Secure Hash Algorithm 1); walau bagaimanapun, ia juga mungkin untuk menetapkan nombor individu kepada semakan.

Sama seperti dalam git, ia menyokong keupayaan untuk mencipta cawangan projek dan kemudian menggabungkannya.

Digunakan untuk interaksi antara pelanggan protokol HTTP, HTTPS atau SSH.

Set arahan adalah mudah dan intuitif, sama seperti arahan subversi. Terdapat juga beberapa cengkerang grafik dan akses kepada repositori melalui antara muka web. Ia juga penting untuk mempunyai utiliti yang membolehkan anda mengimport repositori banyak sistem kawalan versi lain.

Mari kita lihat kelebihan dan kekurangan utama Mercurial.

Kelebihan:

1. Pemprosesan data yang cepat.

2. Sokongan merentas platform.

3. Kebolehan bekerja dengan beberapa cabang projek.

4. Mudah digunakan.

5. Keupayaan untuk menukar repositori sistem sokongan versi lain, seperti CVS, Subversion, Git, Darcs, GNU Arch, Bazaar, dll.

Kelemahan:

1. Kemungkinan (tetapi sangat rendah) padanan kod cincang semakan yang berbeza dalam kandungan.

2. Fokus pada bekerja dalam konsol.

Kesimpulan:

Antara muka yang ringkas dan digilap, satu set arahan dan keupayaan untuk mengimport repositori daripada sistem kawalan versi lain akan menjadikan peralihan kepada Mercurial dan mempelajari ciri utama tidak menyakitkan dan pantas. Ia tidak mungkin mengambil masa lebih daripada beberapa hari.

Kebolehpercayaan dan kelajuan membolehkannya digunakan untuk kawalan versi projek besar. Semua ini menjadikan Mercurial pesaing yang layak untuk Git.

Sistem kawalan versi Bazar.
(bazaar.canonical.com)

Bazaar ialah sistem kawalan versi yang diedarkan secara percuma yang dibangunkan dengan sokongan Canonical Ltd. Ia ditulis dalam Python dan berjalan pada sistem pengendalian Linux, Mac OS X dan Windows.

Tidak seperti Git dan Mercurial, yang dicipta untuk mengawal versi kernel operasi sistem Linux, dan oleh itu tertumpu pada prestasi maksimum Apabila bekerja dengan sejumlah besar fail, Bazaar memfokuskan pada antara muka pengguna yang mudah dan mesra. Pengoptimuman kelajuan kerja telah dijalankan pada peringkat kedua, apabila versi pertama program telah muncul.

Seperti dalam banyak sistem kawalan versi lain, sistem arahan Bazaar sangat serupa dengan arahan CVS atau Subversion, yang, bagaimanapun, tidak menghairankan, kerana ia menyediakan antara muka yang mudah, ringkas dan intuitif untuk berinteraksi dengan program.

Adalah bagus bahawa perhatian yang besar diberikan untuk bekerja dengan cawangan projek (mencipta, menggabungkan cawangan, dll.), yang sangat penting apabila membangunkan projek yang serius dan membolehkan anda melakukan penambahbaikan dan eksperimen tanpa ancaman kehilangan versi utama perisian .

Kelebihan besar sistem kawalan versi ini ialah keupayaan untuk bekerja dengan repositori sistem kawalan versi lain, seperti Subversion atau Git.

Mari kita ringkaskan secara ringkas kelebihan dan kekurangan yang paling ketara bagi sistem kawalan versi ini.

Kelebihan:

1. Sokongan merentas platform.

2. Antara muka yang mudah dan intuitif.

3. Kerja mudah dengan cawangan projek.

4. Keupayaan untuk bekerja dengan repositori sistem kawalan versi lain.

5. Dokumentasi yang sangat baik.

6. Antara muka grafik yang mudah.

7. Fleksibiliti yang melampau, membolehkan anda menyesuaikan diri dengan keperluan pengguna tertentu.

Kelemahan:

1. Kelajuan yang lebih rendah berbanding git dan mercurial, tetapi keadaan ini beransur-ansur diperbetulkan.

2. Untuk kefungsian penuh, perlu memasang bilangan pemalam yang cukup besar yang membolehkan anda mendedahkan sepenuhnya semua keupayaan sistem kawalan versi.

Kesimpulan:

Bazar – sistem yang selesa kawalan versi dengan antara muka yang bagus. Baik untuk pengguna yang ditangguhkan oleh prospek untuk bekerja dengan baris arahan. Sekumpulan pilihan tambahan dan sambungan akan membolehkan anda menyesuaikan program untuk memenuhi keperluan anda. Persamaan sistem arahan dengan Git dan Subversion, dan keupayaan untuk bekerja secara langsung dengan repositori mereka, akan membuat peralihan ke Bazaar cepat dan tidak menyakitkan. Kejayaan bazar itu juga dibuktikan dengan fakta bahawa ia digunakan oleh pembangun Ubuntu Linux.

Sistem kawalan versi gerbang.

Arch ialah sistem kawalan versi teragih yang dicipta oleh Tom Lord. Ia pada asalnya dicipta untuk menyelesaikan masalah CVS, yang mereka berjaya lakukan.

Arch melakukan operasi atom untuk menyimpan perubahan pada repositori, i.e. menghapuskan situasi memuat turun repositori, apabila beberapa perubahan telah dimuat turun, dan ada yang belum sempat memuat turun.

Keupayaan untuk membuat cawangan versi projek dan menggabungkan cawangan individu, menamakan semula dan memindahkan fail dan direktori sambil mengekalkan sejarah perubahan, dan banyak ciri bagus lain disokong.

Tidak memerlukan perkhidmatan khas untuk repositori rangkaian dan boleh menggunakan protokol seperti FTP, SFTP atau WebDAV dan sebagainya.

Tetapi, malangnya, ia hanya disokong oleh sistem UNIX; namun, memindahkan Arch ke sistem pengendalian lain tidak sepatutnya sukar.

Sukar untuk melihat kualiti asas yang lebih baik berbanding sistem kawalan versi teragih lain, seperti git, mercurial, bazar, jadi jika anda mempunyai pilihan, lebih baik menggunakan sesuatu yang lebih berkuasa dan meluas.

Perforce sistem kawalan versi.
(www.perforce.com)

Mari teruskan semakan sistem kawalan versi kami dan beralih kepada program komersial. Mari kita mulakan dengan sistem kawalan versi terpusat - Perforce, dibangunkan oleh Perforce Software.

Sistem Perforce mempunyai organisasi pelayan pelanggan dan membolehkan anda mengurus beberapa projek secara serentak, mencipta repositorinya sendiri untuk setiap projek.

Perforce ialah sistem merentas platform. Terdapat versi yang boleh dijalankan di bawah sistem pengendalian Sistem Unix,Mac OS X, Microsoft Windows.

Untuk bekerja dengan sistem kawalan versi, anda boleh menggunakan kedua-dua konsol dan antara muka grafik yang direka khas.

Kelebihan utama Perforce ialah keupayaan untuk menyepadukan dengan banyak alat dan aplikasi pembangunan perisian seperti Autodesk 3D Studio Max, Maya, Adobe Photoshop, Microsoft Office, Eclipse, emacs dan banyak lagi.

Sokongan untuk keupayaan untuk mencipta cawangan versi projek, mengurusnya secara fleksibel, menggabungkannya, kembali kepada semakan sebelumnya - menjadikan Perforce agak kompetitif sistem yang mampu dan menyumbang kepada penyebarannya yang meluas. Walau bagaimanapun, ini adalah produk komersial, yang agak mengecilkan skopnya dan mengehadkan penyebarannya. Ia digunakan terutamanya dalam syarikat komersial besar, yang bukan sahaja fungsi penting, tetapi juga sokongan teknikal yang tepat pada masanya.

Sistem kawalan versi Team Foundation Server.
(msdn.microsoft.com/en-us/library/ms364061.aspx)

Tegasnya, Team Foundation Server (TFC) tidak boleh dipanggil hanya sebagai sistem kawalan versi - ia adalah sejenis penyelesaian komprehensif yang merangkumi sistem kawalan versi, sistem pengumpulan data, pelaporan dan fungsi berguna lain.

Projek terurus apabila bekerja dengan TFC terdiri daripada cawangan kod sumber projek, set laporan dan elemen tersuai. Apabila membuat projek, parameternya dipilih terlebih dahulu, yang boleh anda pilih sendiri atau gunakan templat. Templat membolehkan anda menentukan laluan pembangunan projek, menjadikannya fleksibel atau diformalkan secara tegar, menetapkan strategi pembangunan, dan mengambil kira dokumen dan laporan yang diperlukan.

TFC mudah disepadukan dengan Microsoft Excel dan Microsoft Project, menjadikannya lebih mudah untuk mencipta dan menjejaki elemen projek terkawal.

Sebagai sistem kawalan versi, TFC membenarkan anda untuk:

Edit fail projek secara kolaboratif;

Selesaikan konflik;

Buat cawangan projek dan kemudian gabungkannya;

Uruskan akses kepada repositori;

Kembali ke versi sebelumnya;

Buat perubahan yang belum selesai - perubahan yang tidak ditambahkan secara langsung pada repositori, tetapi boleh dilihat oleh pengguna lain, dan perubahan ini boleh dimuat turun hanya dengan mendapatkan kebenaran khas daripada pemilik perubahan;

Tandai versi individu fail dalam repositori dan kumpulkan mereka;

Pangkalan data digunakan untuk menyimpan data dan repositori projek yang dibangunkan Pelayan SQL 2005.

TFC ialah alat yang berkuasa dan mudah yang membolehkan anda bukan sahaja mengurus versi kod sumber, tetapi juga untuk mengatur sepenuhnya keseluruhan kitaran pembangunan projek daripada menulis program kepada dokumentasi mereka. Walau bagaimanapun, sistem yang berkuasa dan kompleks ini lebih sesuai untuk projek besar yang memerlukan pengurusan pembangunan yang kompleks dan teliti. Jika anda mempunyai perkembangan kecil, maka masuk akal untuk menggunakan alat yang kurang berkuasa, atau lebih baik lagi, alat yang diedarkan secara bebas, kerana ini akan menjimatkan masa, wang dan saraf anda.

Generalisasi.

Banyak pilihan sistem kawalan versi membolehkan anda memenuhi sebarang keperluan dan mengatur kerja anda mengikut cara yang anda perlukan. Walau bagaimanapun, di antara pelbagai sistem terdapat pemimpin yang jelas. Jadi, jika anda perlu menguruskan projek besar yang terdiri daripada berpuluh-puluh ribu fail dan beribu-ribu orang bekerja, maka sebaiknya pilih Git atau Mercurial. Jika perkara utama untuk anda ialah antara muka yang mudah, dan projek yang sedang dibangunkan tidak begitu besar, maka sistem Bazaar adalah lebih baik untuk anda.

Untuk pengaturcara solo atau projek kecil yang tidak memerlukan cawangan atau mencipta berbilang versi, Subversion ialah pertaruhan terbaik anda.

Tetapi akhirnya pilihan adalah soal citarasa, kerana kini terdapat banyak sistem kawalan versi yang akan memberikan anda semua yang anda perlukan. Jadi pilih dan anda tidak akan menyesal. Sistem kawalan versi adalah perisian yang sangat penting untuk setiap pembangun dan banyak lagi.

Adakah anda mempunyai idea perniagaan baharu yang hebat berkaitan pembangunan perisian?Adakah anda perlu membangunkan penyelesaian teknologi yang kompleks? Atau adakah anda mempunyai sekumpulan besar pengaturcara yang bekerja pada tugas yang sama? Kemudian ingat tiga perkataan ini:sistem kawalan versi .

Sistem kawalan versi (cvs), 2017 - Bandingkan: Git, SVN, Mercurial

, atau vcs- inilah yang menghalang projek daripada runtuh apabila terdapat ramai orang yang mengerjakannya. Pengaturcara, pengurus, penulis salinan masing-masing boleh bekerja pada karya mereka sendiri tanpa mengganggu antara satu sama lain dan tanpa menyebabkan kerosakan yang tidak dapat diperbetulkan.

Jika anda belum biasa dengan konsepnyasistem kawalan versi, kemudian di sini semuanya ditunjukkan dengan sangat jelas.

Atau tonton video daripada GitHub.

Jadi sistem kawalan versi manakah yang sesuai untuk projek anda?

Kami membandingkan beberapa penyelesaian popular untuk memudahkan anda membuat pilihan.

Ini sangat khusus topik teknikal. Kami telah cuba menjadikan ulasan kami dapat difahami oleh semua orang. Tetapi jika anda tidak mempunyai pengalaman pengaturcaraan, pastikan anda berunding dengan jabatan pembangunan anda sebelum membuat keputusan.

Sistem kawalan versi, termasuk SVN (Subversion) dan Git yang terkenal, pada asalnya dicipta untuk membolehkan pasukan pembangun bekerja pada projek kerjasama tanpa menimbulkan kekeliruan. Dalam sistem kawalan, anda tidak perlu menjejaki cawangan kod secara bebas dan mengkaji nota kepada mereka. Sebaliknya, repositori pusat digunakan di mana segala-galanya teratur dan berstruktur. Ia mudah untuk mengemas kini fail, menambah komen, dan juga menggabungkan cawangan projek.

Pendapat mengenai apasistem kawalan versiyang terbaik, berbeza-beza, dan ini membawa kepada perdebatan hangat di kalangan pengaturcara. Memilih dan mengkajisistem kawalan versiuntuk projek anda, ingat bahawa faedah penyelesaian tertentu selalunya subjektif. Contohnya, keutamaan peribadi pengaturcara atau, katakan, penunjuk seperti prestasi, keupayaan pemalam IDE, dsb.

Perbezaan utama antara sistem kawalan versi ialah sama ada ia adalah pelayan pelanggan atau terdesentralisasi (p2p). Adakah mereka mempunyai repositori pusat (pelayan) di mana kod itu diambil dan dari mana ia dikembalikan dengan perubahan yang dibuat. Atau adakah ia salinan masuk storan tempatan, dikemas kini melalui rakan sebaya: lagi rangkaian terdesentralisasi, digunakan untuk penyegerakan, pertukaran tampalan (set perubahan) dan untuk mengekalkan kod semasa.

Ia juga bernilai mengambil kira kelajuan, fungsi dan ambang untuk kemasukan/penguasaan sesuatu tertentusistem kawalan. Mari lihat yang paling biasasistem kawalan versidan sebab mengapa pengaturcara lebih suka penyelesaian tertentu.

Sistem versi serentak (CVS)

CVS muncul pada tahun 1980-an dan masih popular di kalangan pembangun produk komersial dan pembangun sumber terbuka.

CVS diedarkan di bawah termaPerjanjian Lesen Terbuka GNU dan membolehkan anda mendapatkan versi projek yang dikehendaki daripada pelayan - “daftar keluar" (ekstrak) , dan kemudian hantar semula ke pelayan, "daftar masuk" (kembali),dengan perubahan yang dilakukan.

Asalnya CVS telah dicipta untuk mengelakkan konflik versi. Semua peserta diberikan hanya versi terkini kod untuk digunakan. Ini adalah sistem kawalan versi pertama. Pengguna perlu melakukan perubahan dengan cepat pada repositori sebelum orang lain mengalahkannya.

Sekarang CVS mempunyai sokongan untuk mengerjakan projek dengan cawangan kod. Ini menghasilkan beberapa pilihan produk dengan ciri-ciri berbeza yang boleh digabungkan kemudian.

Pelayan CVS biasanya dijalankan di bawah Unix, tetapi CVS -pelanggan juga tersedia dalam sistem pengendalian popular lain. CVS - "matang", diuji masasistem kawalan versi. Ia masih merupakan sistem sumber terbuka, tetapi hari ini ciri-ciri baru ditambah agak jarang.

Pada masa yang sama, CVSNT ialah versi yang dipisahkan kepada projek yang berasingan CVS untuk pelayan Windows - kini agak aktif mengembangkan fungsinya.

Kelebihan:

• Teknologi teruji masa yang telah berada di pasaran selama beberapa dekad.

Kelemahan:

• Menamakan semula atau memindahkan fail tidak ditunjukkan dalam sejarah
• Risiko keselamatan yang berkaitan dengan pautan simbolik kepada fail
• Tiada sokongan untuk operasi atom, yang boleh membawa kepada rasuah kod
• Operasi dengan cawangan kod program adalah mahal, kerana inisistem kawalantidak bertujuan untuk projek jangka panjang dengan cawangan kod

Apache Subversion (SVN)

SVN dicipta sebagai alternatif CVS untuk memperbaiki kekurangan CVS dan pada masa yang sama memastikan keserasian yang tinggi dengannya.

Seperti CVS SVN ialah sistem percuma kawalan versi sumber terbuka. Satu-satunya perbezaan ialah ia diedarkan di bawah lesen Apache, dan bukan di bawahDi bawah Perjanjian Lesen Awam GNU.

Untuk mengekalkan integriti pangkalan data, SVN menggunakan apa yang dipanggil operasi atom. Apabila versi baharu dikeluarkan, sama ada semua atau tiada pembetulan digunakan pada produk akhir. Oleh itu, kod tersebut dilindungi daripada suntingan separa huru-hara yang tidak konsisten antara satu sama lain dan menyebabkan ralat.

Ramai pembangun telah beralih kepadaSVN, kerana teknologi baharu mewarisi ciri yang lebih baik CVS dan pada masa yang sama mengembangkannya.

Semasa di CVS operasi dengan cawangan kod adalah mahal dan tidak disediakan oleh seni bina sistem; SVN dicipta hanya untuk ini. Iaitu, untuk projek yang lebih besar dengan percabangan kod dan banyak bidang pembangunan.

Kelemahan SVN termasuk kelajuan yang agak perlahan dan kekurangan kawalan versi teragih. Diedarkan kawalan versi menggunakan model peer-to-peer dan bukannya pelayan berpusat untuk menyimpan kemas kini kod perisian. Dan walaupun model peer-to-peer berfungsi lebih baik dalam projek sumber terbuka, ia tidak sesuai dalam kes lain. Kelemahan pendekatan sisi pelayan ialah apabila pelayan ranap, pelanggan tidak mempunyai akses kepada kod.

Kelebihan:

• Berasaskan sistem CVS
• Membenarkan operasi atom
• Operasi percabangan kod lebih murah
• Pelbagai pilihan pemalam IDE
• Tidak menggunakan model peer-to-peer

Kelemahan:

• Ralat masih berterusan berkaitan dengan menamakan semula fail dan direktori
• Set arahan yang tidak memuaskan untuk bekerja dengan repositori
• Kelajuan yang agak rendah

Git

Sistem ini dicipta untuk mengurus pembangunan kernel Linux dan menggunakan pendekatan yang sama sekali berbeza daripada CVS dan SVN.

Asas Git konsep telah ditetapkan untuk mewujudkan pengedaran yang lebih cepatsistem kawalan versi, bertentangan dengan peraturan dan penyelesaian yang digunakan dalam CVS . Memandangkan Git dibangunkan terutamanya untuk Linux, ia berjalan paling pantas pada OS ini.

Git juga berjalan pada sistem seperti Unix (seperti MacOS), dan pakej mSysGit digunakan untuk berjalan pada platform Windows.

Kod program mungkin tidak tersedia apabila menggunakan komputer tanpa repositori. Terdapat penyelesaian untuk masalah ini, dan sesetengah pembangun percaya bahawa kelajuan Git adalah harga yang berpatutan untuk membayar ketidakselesaan itu.

Git juga mempunyai banyak alat untuk menavigasi sejarah perubahan anda. Setiap salinan kerja kod sumber mengandungi keseluruhan sejarah pembangunan, yang sangat berguna apabila pengaturcaraan tanpa sambungan Internet.

Kelebihan:

• Bagus untuk mereka yang membenci CVS/SVN
• Peningkatan yang ketara dalam prestasi
• Operasi murah dengan cawangan kod
• Sejarah pembangunan penuh tersedia di luar talian
• Diedarkan, model peer-to-peer

Kelemahan:

• Halangan kemasukan (pembelajaran) yang tinggi bagi mereka yang pernah menggunakan SVN sebelum ini
• Sokongan terhad untuk Windows (berbanding dengan Linux)

Mercurial

Mercurial telah dikeluarkan pada masa yang sama dengan Git. itu yang sama diedarkan sistem kawalan versi.

Mercurial dicipta sebagai alternatif kepada Git untuk membangunkan modul kernel Linux. Tetapi sejak kami memilih Git, Mercurial digunakan kurang. Walau bagaimanapun, banyak pembangun terkemuka bekerja dengan sistem ini, sebagai contohOpenOffice.org .

Sistem kawalan versi Mercurial adalah berbeza daripada yang lainsistem kawalan versikerana ia ditulis terutamanya dalam Python (bukan C). Walau bagaimanapun, beberapa bahagian dilaksanakan sebagai modul lanjutan dalam C.

Memandangkan sistem ini tidak berpusat dan ditulis dalam Python, ramai pengaturcara Python cenderung untuk beralih kepada Mercurial.

Pengguna ambil perhatian bahawa Mercurial mengekalkan beberapa ciri SVN, semasa berada sistem teragih, dan terima kasih kepada persamaan ini, ia mempunyai halangan yang lebih rendah untuk masuk bagi mereka yang sudah biasa dengan SVN. Dokumentasi Mercurial juga lebih lengkap, yang membantu anda membiasakan diri dengan perbezaan dengan lebih cepat.

Satu daripada kelemahan yang ketara Mercurial ialah, tidak seperti Git, ia tidak boleh menggabungkan dua cabang induk, kerana Mercurial menggunakan sistem pemalam dan bukannya sokongan skrip. Ini bagus untuk sesetengah pengaturcara, tetapi ramai yang tidak mahu melepaskan kuasa Git.

Kelebihan:

• Lebih mudah untuk belajar berbanding Git
• Dokumentasi terperinci
• Model yang diedarkansistem kawalan versi

Kelemahan:

• Tiada pilihan untuk menggabungkan dua cawangan induk
• Menggunakan pemalam dan bukannya skrip
• Lebih sedikit peluang untuk penyelesaian bukan standard

yang manakawalan versi berfungsi untuk saya?

Dalam kebanyakan kes, pemaju menggunakan CVS kerana ia lebih dikenali oleh mereka. Jika sesebuah pasukan sudah mengusahakan sesuatu projek, maka prospek untuk memindahkan semua pembangunan kepada yang lainsistem kawalanentah bagaimana tidak memberi inspirasi. Jika mereka terpaksa menukar sistem, kemungkinan besar mereka akan bertukar kepada SVN.

CVS telah pun mencapai status "teknologi matang", yang bermaksud ciri dan penyelesaian baharu yang radikal tidak akan muncul di dalamnya. Momentum tabiat itu hilang apabila orang berpindah ke SVN. Ini bermakna bahawa CVS secara beransur-ansur menjadi perkara yang lepas.

Hari ini SVN memegang telapak tangan di kalangan pelayan pelayansistem kawalan versi. Ia termasuk faedah CVS dan mengatasi mereka. Jika kita bercakap tentang kelaziman, maka kemungkinan besar anda akan menghadapi lebih kerap CVS atau SVN berbanding dengan Git atau Mercurial. Jadi, pengetahuan tentang satu teknologi pelayan, walaupun tidak penting, akan memudahkan peralihan anda.

Disebabkan penggunaan meluas dan kematangan teknologi, SVN mempunyai pangkalan pengetahuan yang besar, memudahkan pengguna mendapatkan bantuan.

Git jelas lebih pantas daripada pesaingnya. Untuk projek yang dibuat untuk diedarkansistem kawalan versi, ini adalah peningkatan yang jelas.

Kelemahan penting Git ialah kadangkala sukar untuk menerangkan nuansa cara ia berfungsi.sistem kawalan, dan ini memperlahankan aliran kerja sementara pengaturcara membiasakannya. Walau bagaimanapun, sebaik sahaja "ambang kemasukan" diatasi, produktiviti meningkat dan kemudahan mengurus cawangan kod akan membayar balik sepenuhnya masa yang dibelanjakan.

Bagi mereka yang membenci Git (dan ia mempunyai pengkritiknya di kalangan pembangun), Mercurial ialah kompromi antara SVN dan Git. Sistem ini digunakan dalam banyak projek terkenal dan juga mempunyai dokumentasi yang baik.

Bersesuaian dengan versi Windows Git juga semakin maju ke arah menjadi sepantas versi Linux, jadi ia mungkin berkaitan dengan anda walaupun anda tidak membangun di Linux.

Untuk memahami mana yang terbaik untuk anda, ambil kira ciri projek dan pasukan anda. Bercakap dengan pemaju!

Jika projek memerlukan satu pokok kod sumber yang akan diusahakan oleh sekumpulan kecil pengaturcara, maka SVN ialah pilihan anda. Ia boleh dipercayai dan direka hanya untuk kes sedemikian.

Jika anda melancarkan projek sumber terbuka, yang mana anda masa yang berbeza beberapa pengaturcara akan berfungsi, atau jika anda merancang untuk sentiasa mengemas kini kod, kemudian pilih Git. Kepantasan dan pengurusan pokok sumber adalah lebih baik di sini berbanding di SVN.

Jika anda berada di persimpangan jalan atau hanya tidak menyukai cara SVN atau Git berfungsi, maka Mercurial adalah untuk anda.

Semua sistem ini berfungsi sepenuhnya. Dan juga percuma. Ia digunakan untuk mencipta perisian, tapak web, dan juga sistem pengendalian yang anda gunakan dan ketahui.

Pertama sekali, tentukan sama ada satu atau yang lain sesuaisistem kawalanversi untuk perniagaan anda, dan kemudian - sama pentingnya - pastikan pilihan ini tidak akan menimbulkan kemarahan pengaturcara.

Bermula dengan SVN

Jika anda tidak pernah bekerja dengan SVN atau Git dan tidak tahu bagaimana untuk bermula, makapenyelesaian pengehosan digabungkan dengan antara muka grafik akan membantu anda membiasakannya dengan cepat.

Seperti dalam kebanyakan kes, perkara yang paling penting ialah mula bekerja, dan kemudian pemahaman akan datang. Mengendalikan sistem kawalan versi sangat serupa dengan bekerja dengan fail pada pelayan menggunakan klien FTP.

CATATAN:Terdapat banyak penyelesaian pengehosan untuksistem kawalan versi, termasuk percuma tempoh percubaan. Anda boleh membuat repositori pertama anda (tempat untuk bekerjasama dengan fail kod) secara percuma. Berikut adalah beberapa perkhidmatan ini:

Pengehosan SVN & GIT

Mencipta repositori pertama

Selepas anda membuat akaun, anda perlu membuat repositori - untuk setiap platform secara berasingan. Ia biasanya kelihatan seperti ini:

• Log masuk ke akaun anda, klik pada projek anda.
• Mencipta projek:

• Dalam baris "Buat Projek Baharu", masukkan nama projek anda
• Klik pada butang "Buat Projek".

• Sambungan SVN:

• Selepas mencipta projek, pilih tab "Kawalan Sumber" (versi kod sumber)
• Klik pada pautan "Dayakan Kawalan Sumber"
• Beri nama repositori
• Klik "Simpan"

Pelanggan grafik SVN dan GIT

Jadi, repositori telah dibuat. Sekarang kita memerlukan segala-galanya untuk dipaparkan di dalamnya secara ringkas dan jelas. Untuk melakukan ini, anda memerlukan GUI.

— program yang selesa untuk bekerja dengansistem kawalan versipada Microsoft Windows dan mungkin klien Apache Subversion terbaik yang tersedia. TortoiseSVN dilaksanakan sebagai sambungan shell Windows, menjadikannya mudah untuk disepadukan pelayar. Ia juga merupakan program sumber terbuka dengan 34 pek bahasa tersedia

SmartGit

– Pelanggan grafik Git (Sumber Terbuka diedarkansistem kawalan versi). Berfungsi pada Windows, Mac OS X dan Linux.Kos lesen - $39

"Menyemak" repositori ("Daftar keluar")

Jadi, pelanggan telah dipilih. Sekarang anda perlu membuat repositori untuk sistem kawalan. Perlu masukURL repositori, nama pengguna dan kata laluan anda.

URL biasanya kelihatan seperti ini:https://svn .hostname.com/svn/ > (anda boleh menggunakan https:// (SSL) jika anda mempunyai akaun berbayar)

1. Pergi ke folder akar, klik butang Semak Keluar dan buat folder yang berfungsi untuk klien. Kini anda boleh menambah fail padanya.
2. Setelah fail projek diekstrak, anda boleh mengeditnya dalam direktori tempatan pada komputer anda.

Selepas membuat perubahan pada fail, klik butang Daftar Masuk pada bar alat untuk menyimpannya. Anda boleh menyemak perubahan dan menambah ulasan kepada mereka - ini adalah idea yang cukup bagus, kerana pada masa hadapan anda akan mengetahui dengan tepat apa yang anda usahakan, perubahan yang dibuat dan akan memaklumkan peserta projek lain.

Pelanggan anda juga harus menyediakan keupayaan untuk mula bekerja dengan semakan pada bila-bila masa dengan membuka log semakan atau sejarah perubahan - kemudian, jika perlu, anda boleh "gulung semula" ke versi terdahulu untuk setiap fail secara berasingan. Sekarang anda sudah biasa dengan konsep asas, dokumentasi