Bu soru şeffaf çoğaltmayı soruyor ve sanırım henüz hiç yanıt yok çünkü insanlar şeffaflığa kapılıyor olabilir. Çoğaltmaya odaklanmak için şeffaflığı bir kenara bırakma özgürlüğünü alacağım. Daha sonra şeffaflıkla başa çıkacağım (veya incelikle) ve aslında bir DVCS'de bunların hepsi bu kadar önemli olduğunu düşünmüyorum.
İlk olarak, depoların bir DVCS'de çalışma şekli hakkında birkaç önemli noktadan bahsedeyim. (Mercurial'ı en iyi biliyorum, bu yüzden örnekler için kullanacağım, ancak söylediğim her şeyin git için de doğru olduğuna inanıyorum.)
A. Bir DVCS'de, herhangi bir klon orijinal ile aynı dosya içeriğini ve geçmişini içerir.
Depoları düzgün bir şekilde senkronize tutmanızı sağlamak, bir çoğaltma sistemi oluşturmak için sıradan DVCS değişiklik yayma işlemlerini (klon, itme, çekme) ve sıradan depoları kullanabileceğiniz anlamına gelir.
B. Yeni değişikliklerin geldikleri yere yayılması gerekmez.
Özellikle, belirli bir repodan değişiklik alıp kendi değişikliklerimi ekleseydim, değişikliklerimin o repoya geri dönmesi gerekmez. Başka bir yere gidebilirler. Bunun faydası aşağıda göstereceğim örneklerden anlaşılmalıdır.
C. Değişiklikler itme veya çekme ile çoğaltılabilir.
Merkezi bir sistemde, yeni değişiklikler hemen hemen (sadece sanırım) repoya itilebilir. Bir DVCS'de, bazıları sadece çekmeyi içeren çeşitli değişiklik yayılım topolojileri ayarlamak mümkündür. Bu, kurulumda daha fazla esneklik sağlar.
Örnekler
Tartışma uğruna, dağıtılmış takımlarınızın duke.de, duke.us, duke.cn ve duke.mx alanlarındaki sistemleri kullandığını ve duke.de'nin "kutsanmış" repoya sahip olmak istediğimiz yer olduğunu varsayalım. Bu varsayımlar göz önüne alındığında, yukarıdaki üç temel DVCS noktasını göz önünde bulundurarak, ayarlayabileceğiniz farklı topolojilerden birkaç örnek vereyim.
0. Merkezi İtme Modeli
Hg.duke.de adresinde tek bir repo var ve tüm konumlardaki geliştiricilerin klonlayıp buradan çekip değişiklikleri buraya itmelerini sağlayın. Bu, Almanya'daki insanlar için işe yarayabilir, ancak muhtemelen dünyanın geri kalanındaki insanlar için bir sorun olacaktır. Tüm klonlama, çekme ve gönderme işlemleri yavaş uzun mesafeli ağ bağlantılarından geçer. Bu, merkezi bir sistem gibi bir DVCS kullanıyor. Bu çözmeye çalıştığınız problem.
1. Çoğaltma ile Merkezi İtme
Hg.duke.de adresinde mübarek repo ve hg.duke.cn, hg.duke.mx ve hg.duke.us adreslerinde kopyalar edinin. Geliştiriciler yerel kopyalarından kopyalar ve değişiklikleri hg.duke.de adresine gönderir. Hg.duke.de dosyasında yeni değişiklikler göründüğünde, bunları çoğaltmalara geçiren bir kanca çalışır. Kopyalar başka türlü salt okunurdur, bu nedenle hiçbir zaman birleşme veya çakışma olmaz.
Örneğin, Meksika'da bir geliştiriciysem, hg.duke.mx dosyasından klonlayacağım, ancak değişiklikleri hg.duke.de adresine göndereceğim. Değişikliklerimi itmeden önce diğer değişiklikler hg.duke.de içine itilirse, push'um engellenir. Diğer değişiklikler hg.duke.mx dosyasına çoğaltılacaktır, bu nedenle bu değişiklikleri yerel olarak çekeceğim, birleştireceğim ve sonra tekrar hg.duke.de adresine zorlamaya çalışacağım.
Büyük klon operasyonlarının tümü yerel olarak yapıldığından, bu bazı avantajlar sağlamalıdır. Merkezi bir repoya başka bir yerde itmek çok kötü olmayabilir, çünkü değişiklikler nispeten nadiren itilir, artımlı değişiklikler genellikle oldukça küçüktür. (Özellikle Mercurial, esasen tüm dosyaları ve geçmişlerini değil, sıkıştırılmış farkları gönderir.)
Mercurial'ta, bir konumdan çekmek ve .hg/hgrcdosyaya aşağıdakine benzer bir şey koyarak başka bir konum oluşturmak için yerel bir repo oluşturabilirsiniz :
[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de
2. Basit Çekme Modeli
Mübarek repo olarak hg.duke.de ve diğer kopyalar olarak devam ederek, itme yerine çekme yoluyla değişiklikleri yayabiliriz. Geliştiriciler her zamanki gibi yerel kopyalarından klonlar ve çekerler. Bir değişiklik hazır olduğunda, geliştirici, geliştiricinin deposundan hg.duke.de adresine gelen bazı merkezi hizmete bir çekme isteği gönderir. Birleşme için bir politika oluşturulması gerekecektir. Örneğin, birleştirme çakışmaları varsa, istek reddedilebilir ve geliştiricinin çekme isteğini almasını (yerel kopyadan), birleştirmesini ve yeniden göndermesini gerektirir.
Bu yaklaşım, değişiklikler yayılırken geliştiriciyi bekletmeme avantajına sahiptir. Elbette, geliştirici çekme talebinin gerçekleştirilmesini beklemek zorundadır, ancak en azından bu süre zarfında ek değişiklikler üzerinde çalışabilir.
Varyasyonlar
Uygulanabilecek bir sürü varyasyon vardır.
Bir çekme isteğinin sunulması kod incelemesi için mükemmel bir zamandır. Değişiklikler herkesin erişimine açık olduğu için yayınlandı, ancak kutsanmış repoya henüz entegre edilmedi.
Çekme istekleri manuel olarak veya bazı otomatik sistemlerde gerçekleştirilebilir. Bir çekme isteğinin işlenmesi, değişiklikleri doğrudan kutsanmış repoya değil, bir oluşturma ve test döngüsünün yapıldığı geçici bir hazırlama alanına birleştirebilir. Ancak tüm testler geçtikten sonra değişiklikler kutsanmış repoya entegre edilecekti.
Bir itme modeliyle daha rahat olanlar, her yerde, çoğaltmanın yanında, örneğin hg-stage.duke.mx, hg-stage.duke.cn, vb. bununla birlikte, geliştiriciler sadece diğer yerel değişikliklerle birleşmekle kalmaz, aynı zamanda evreleme depolarındaki değişiklikleri kutsanmış repoya birleştirmekten de birileri sorumlu olmalıdır. Bu doğru koşullar altında çalışabilir ve otomasyona yardımcı olabilir.
"Şeffaflık"
Şimdi şeffaf çoğaltma konusuna.
Yukarıdaki senaryolar göz önüne alındığında, şeffaf çoğaltma ihtiyacını gerçekten görmüyorum. Tüm depolar herkes tarafından görülebilir ve yerel kopyadan çekme / klonlama ve kutsanmış bir repoya veya yerel bir sahneleme alanına itme kuralları vardır.
Şeffaflık istiyorsanız, kişilerin konumlarına göre DNS arama alan adları ayarlamasını sağlayabilirsiniz. Yerel çoğaltma ve hazırlama depolarına basitçe "hg" ve "hg-stage" denir ve DNS kurulumu bunları Çin'deki geliştiriciler için hg.duke.cn ve hg-stage.duke.cn olarak ve buna karşılık olarak diğer yerlerdeki geliştiriciler. Ama bu biraz sihir ve kafa karıştırıcı olabilir ve gerçekten çok şey kattığını düşünmüyorum.
Umarım bu soruya cevap verir. Yanıtla ilgili birtakım özgürlükler aldım, ama bana öyle geliyor ki, yukarıda tarif ettiğim teknikler kullanılarak durumunuz düzeltilebilir.