Pertanyaan ini menanyakan tentang replikasi transparan , dan saya kira belum ada jawaban karena orang mungkin terpaku pada transparansi. Saya akan mengambil kebebasan menyisihkan transparansi untuk saat ini untuk fokus pada replikasi. Saya akan berurusan dengan (atau kemahiran) transparansi nanti, dan sebenarnya saya tidak benar-benar berpikir itu semua yang penting dalam DVCS.
Pertama, saya akan membahas beberapa poin kunci tentang cara repositori bekerja dalam DVCS. (Saya paling akrab dengan Mercurial, jadi itulah yang akan saya gunakan sebagai contoh, tapi saya percaya semua yang saya katakan juga berlaku untuk git.)
A. Dalam DVCS, klon mana pun berisi konten file dan riwayat yang sama dengan aslinya.
Memberikan Anda menjaga repo tetap selaras, ini berarti Anda dapat menggunakan operasi propagasi perubahan DVCS biasa (klon, dorong, tarik) dan repo biasa untuk membangun sistem replikasi.
B. Perubahan baru tidak harus disebarkan ke tempat asalnya.
Khususnya, jika saya ingin mendapatkan perubahan dari repo tertentu, dan menambahkan beberapa perubahan saya sendiri, perubahan saya tidak harus kembali ke repo tertentu. Mereka bisa pergi ke tempat lain. Utilitas ini harus menjadi jelas dari contoh yang akan saya tunjukkan di bawah ini.
C. Perubahan dapat diperbanyak melalui push atau pull.
Dalam sistem terpusat, perubahan baru bisa (saya pikir) hanya bisa didorong ke repo. Dalam DVCS, dimungkinkan untuk mengatur berbagai topologi perubahan propagasi, yang beberapa di antaranya hanya melibatkan penarikan. Ini memberi lebih banyak fleksibilitas dalam pengaturan.
Contohnya
Demi diskusi, katakanlah tim Anda yang terdistribusi menggunakan sistem di domain duke.de, duke.us, duke.cn, dan duke.mx, dan selanjutnya duke.de adalah tempat kami ingin memiliki repo "diberkati". Dengan asumsi-asumsi ini, izinkan saya menjelaskan sejumlah contoh topologi berbeda yang dapat Anda atur, dengan mengingat tiga poin utama DVCS di atas.
0. Model Dorong Terpusat
Miliki satu repo di hg.duke.de dan minta para pengembang di semua lokasi klon dan tarik dari sini dan dorong perubahan di sini. Ini mungkin bekerja untuk orang-orang di Jerman, tetapi mungkin akan menjadi masalah bagi orang-orang di seluruh dunia. Semua operasi kloning, tarik, dan dorong akan melewati tautan jaringan jarak jauh yang lambat. Ini menggunakan DVCS seperti sistem terpusat. Ini adalah masalah yang Anda coba selesaikan.
1. Dorong Terpusat dengan Replikasi
Dapatkan repo yang diberkati di hg.duke.de dan miliki replika di hg.duke.cn, hg.duke.mx, dan hg.duke.us. Pengembang mengkloning dari replika lokal mereka dan mendorong perubahan ke hg.duke.de. Setiap kali perubahan baru muncul di hg.duke.de, sebuah hook berjalan yang menyebarkannya ke replika. Replika-replika itu hanya baca-saja, sehingga tidak akan pernah ada penggabungan atau konflik.
Jika saya seorang pengembang di Meksiko, misalnya, saya akan mengkloning dari hg.duke.mx tetapi mendorong perubahan ke hg.duke.de. Jika perubahan lain didorong ke hg.duke.de sebelum saya bisa mendorong perubahan saya, dorongan saya akan diblokir. Perubahan lainnya akan direplikasi ke hg.duke.mx, jadi saya akan menarik perubahan ini secara lokal, bergabung, dan kemudian mencoba untuk mendorong ke hg.duke.de lagi.
Ini harus memberikan beberapa keuntungan, karena operasi klon besar semua dilakukan secara lokal. Mendorong ke repo pusat di lokasi lain mungkin tidak terlalu buruk, karena perubahan didorong relatif jarang, perubahan tambahan umumnya cukup kecil. (Mercurial khususnya mengirim diff terkompresi, bukan seluruh file dan sejarahnya.)
Di Mercurial, Anda dapat mengatur repo lokal untuk menarik dari satu lokasi dan mendorong ke yang lain dengan meletakkan sesuatu seperti berikut ini di .hg/hgrcfile:
[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de
2. Model Tarik Sederhana
Melanjutkan dengan hg.duke.de sebagai repo yang diberkati dan yang lainnya sebagai replika, kita dapat menyebarkan perubahan melalui tarikan alih-alih mendorong. Pengembang mengkloning dan menarik dari replika lokal mereka seperti biasa. Saat perubahan siap, pengembang mengajukan permintaan tarik ke beberapa layanan pusat, yang menarik dari repo pengembang ke hg.duke.de. Kebijakan perlu ditetapkan untuk penggabungan. Misalnya, jika ada konflik penggabungan, permintaan mungkin ditolak, mengharuskan pengembang untuk menarik (dari replika lokal), menggabungkan, dan mengirimkan kembali permintaan tarik.
Pendekatan ini memiliki keuntungan tidak membuat pengembang menunggu sementara perubahan sedang disebarkan. Tentu saja, dev masih harus menunggu permintaan tarik untuk ditindaklanjuti, tetapi setidaknya dia dapat bekerja pada perubahan tambahan selama waktu itu.
Variasi
Ada banyak variasi yang dapat diterapkan.
Pengajuan permintaan tarik adalah waktu yang tepat untuk meninjau kode. Perubahan diterbitkan, dalam arti bahwa itu tersedia untuk semua orang, tetapi mereka belum diintegrasikan ke dalam repo yang diberkati.
Permintaan tarik dapat ditindaklanjuti secara manual atau oleh beberapa sistem otomatis. Memproses permintaan tarik mungkin tidak menggabungkan perubahan langsung ke repo yang diberkati, tetapi sebaliknya menjadi area pementasan sementara di mana siklus pembuatan dan pengujian dilakukan. Hanya setelah melewati semua tes maka perubahan akan diintegrasikan ke dalam repo yang diberkati.
Mereka yang lebih nyaman dengan model dorong mungkin ingin mengatur repo pementasan lokal di setiap lokasi, di samping replika, misalnya hg-stage.duke.mx, hg-stage.duke.cn, dll. Ini membutuhkan sedikit lebih banyak pekerjaan, meskipun, karena pengembang tidak hanya harus bergabung dengan perubahan lokal lainnya, tetapi seseorang harus bertanggung jawab untuk menggabungkan perubahan dari repo pementasan ke dalam repo yang diberkati. Ini dapat bekerja dalam kondisi yang tepat, dan dapat dibantu oleh otomatisasi.
"Transparansi"
Sekarang untuk masalah replikasi transparan.
Mengingat skenario di atas, saya tidak benar-benar melihat perlunya replikasi transparan. Semua repo dapat dilihat oleh semua orang, dan ada konvensi untuk menarik / mengkloning dari replika lokal dan mendorong repo yang diberkati atau area pementasan lokal.
Jika Anda menginginkan transparansi, Anda dapat meminta orang mengatur domain pencarian DNS sesuai dengan lokasinya. Replika lokal dan pementasan repo hanya akan disebut sebagai "hg" dan "hg-stage" dan pengaturan DNS akan menyelesaikan ini untuk hg.duke.cn dan hg-stage.duke.cn untuk pengembang di Cina, dan juga untuk pengembang di lokasi lain. Tapi ini sedikit ajaib dan bisa membingungkan, dan saya benar-benar tidak berpikir itu menambah banyak.
Saya harap ini menjawab pertanyaan Anda. Saya mengambil sejumlah kebebasan dengan tanggapannya, tetapi bagi saya tampaknya situasi Anda dapat diatasi melalui penggunaan teknik yang telah saya jelaskan di atas.