Ekipler kaynak dosyalarda yazma işleminin nasıl önlenmesini sağlar? [kapalı]

Kapalı. Bu soru konu dışı . Şu anda cevapları kabul etmiyor.

Bu soruyu geliştirmek ister misiniz? Sorunuzu güncelleyin o yüzden -konu üzerinde Oyun Geliştirme Stack Exchange için.

4 yıl önce kapandı .

Örneğin, oyun motoru, birden fazla kişi tarafından aynı anda çalışılırken üzerine yazma işleminin nasıl engelleneceği ihtimali bana geldi.

Diyelim ki geliştirici bir üzerinde çalışıyor Audio.cppve geliştirici iki de üzerinde çalışıyor Audio.cpp, bu genel olarak büyük takımlarda üzerine yazmak için nasıl yönetiliyor? (Başka bir deyişle, geliştirici iki dosyasının geliştirici bitene kadar dosyayı açmasını durdurmak için )

project-management version-control teamwork java 2d collision-detection vector collision-resolution unity directx directx11 directx10 xna ios monogame windows-phone-8 xamarin design-patterns oop xna collision-detection collision-resolution bounding-boxes rotation collision-detection mathematics javascript algorithm separating-axis-theorem xna 2d monogame image xna directx graphics performance opengl 2d 3d c++ directx11 unity c# scale c# xna collision-detection collision-resolution leaderboards scoring glsl srgb tilemap three.js tiled unity physics xml dialog-tree xna c# .net opengl lwjgl vbo physics graphics procedural-generation simulations water opengl java textures lwjgl frame-buffer unity unity 2d collision-detection collision-resolution trigonometry java android libgdx xna c# frame-rate c++ unreal-4 procedural-generation java graphics lwjgl slick c++ software-engineering

— Ethan Webster
kaynak

Seçtiğiniz etiketlerden biri zaten cevap.

— Philipp

Aslında, 4 etiketleri 3 bir cevap vardır, ama biridir cevap.

— MS

İlgili: gamedev.stackexchange.com/q/480

— moooeeeep 13:15

Yanıtlar:

Çoğu yazılım geliştirme ekibi (yalnızca oyun geliştirme aşamasında değil) sürüm kontrol yazılımını kullanarak bu sorunu çözer . Örnekler

Tüm bu araçların bazı farklılıkları vardır, ancak temel iş akışı genellikle bu şekildedir: Proje için tam kod temeli ile merkezi bir havuz vardır. Bir geliştirici projeye katılmak istediğinde, bir "ödeme" gerçekleştirir. Sürüm kontrol yazılımı, kod tabanını yerel makinelerine kopyalar. Yazılım, kod tabanının güncel sürümünü ("revizyon") hatırlar. Bir geliştirici değişiklik yaptığında ve bunları ana depoya koymak istediğinde, bir "taahhüt" verir. Değişiklikleri merkezi depoya yüklenir ve yeni bir revizyon numarası yaratılır.

Başka bir geliştirici şimdi değişikliklerini yapmak istediğinde, ancak bir kez kontrol ettikleri revizyon artık en son sürüm değil, sürüm kontrol sistemi onlara izin vermiyor. Geliştiricinin önce bu arada olan revizyonları "çekmesi" gerekir. Bu, yerel kopyalarını merkezi depodaki en son sürüme günceller. Çakışmalar olduğunda (ara revizyonlar da değiştirdikleri bir dosyada değişiklik yapar), yazılım, çakışan dosyaları otomatik olarak yapmayı başaramaması durumunda, çakışan dosyaları manuel olarak ("birleştirme") düzenleyerek çözmelerini isteyebilir. Bunu yaptıktan sonra değişikliklerini yeni bir revizyon olarak yapabilirler.

— Philipp
kaynak

Git ve Mercurial'ın biraz farklı çalışan dağıtılmış sürüm kontrol sistemleri olduğuna dikkat edin : tek bir merkezi depo gerektirmezler, ancak teorik olarak herhangi bir geliştiricinin doğrudan başkalarından güncellemeler almasına izin verir. Tabii ki, pratikte, hala bir deponun (genellikle GitHub gibi bir kamuya açık toplantıda bulunan) “resmi” ilan etmesi ve dağıtılmamış versiyon kontrol sisteminde merkezi depo gibi az ya da çok kullanılmış olması hâlâ yaygındır.

— Ilmari Karonen

Bu cevap aynı zamanda birleştirmenin her zaman manuel olarak yapıldığını da gösterir. Bununla birlikte, çoğu zaman sürüm kontrol yazılımı farklılıkları otomatik olarak birleştirebilir ve gerçekten çok ciddi değişiklikler için yalnızca manuel olarak çalışmayı gerektirir.

— saat

Lütfen yorumlardaki uzun tartışmalardan kaçının millet. Bu bir tartışma forumu değil. Bunu yapmak istiyorsanız Oyun Geliştirme Sohbetini kullanın . Çeşitli teğet yorum konuları temizledim.

— Josh

Ayrıca, ideal olarak, her ekip üyesi neredeyse sadece belirli modüllerden sorumlu olacak ve yalnızca nadir durumlarda birden fazla kişi kısa süre içinde aynı kaynak dosyasını değiştirecekti, çünkü bu iş akışı çakışan değişiklikleri birleştirme ihtiyacını en aza indirir. Ancak bu her zaman böyle değildir.

— Nicolas Miari

Geliştiriciler aynı dosyayı kullanmaz .

Her geliştiricinin dosyanın kendi sürümü vardır ve çalışmalarını yönetmek için özel bir yazılım türü kullanırlar. İkisinde de değişiklik yaparlarsa, diğer geliştirici tarafından yapılan değişikliklerin üzerine yazmaya çalışan, çözülmesi gereken bir çatışmayla karşılaşır , aksi halde bahsettiğim yazılım şikayet etmeye başlar. Başka bir deyişle, çatışmaya neden olan geliştiricinin, çalışmalarını diğer geliştiricinin çalışmasıyla birleştirmesi gerekir ve ancak o zaman dosya "kaydedilebilir".

Bu, başka türlü basit olmayan versiyon kontrolü kavramının bir kısmı için basit bir açıklamadır .

Ayrıca iletişim denen bu yeni şeyi yaparlar ve yazılım bir boşlukta yazılmaz. Bu yüzden çatışmayı anlamıyorlarsa, diğer kişiyle konuşur veya önceden koordine ederler.

— Brian

Sürüm kontrolü ve birleştirme ile olan çatışmaların ele alınmasıyla ilgili diğer cevaplarda ortaya çıkan noktalara ek olarak, ekip üyelerinin birbirlerinin çalışmalarının üzerine yazmaktan kaçınmaları için en az iki yol daha vardır:

Bazı sürüm kontrol sistemleri (örneğin SVN) dosyaların kilitlenmesine izin verir. Bu, bir ekip üyesinin bir süre daha özel olarak sahiplenebileceği ve böylece diğer ekip üyelerinin dosyanın kilidini açıncaya kadar çakışan düzenlemeler (veya gerçekten herhangi bir düzenleme) yapmasını engelleyebileceği anlamına gelir.

Ancak, bu genellikle bir dizi soruna neden olabileceği için nadiren kullanılır. Verimliliği azaltabilir (belirli bir zamanda dosyalar üzerinde kimin çalışabileceğini sınırlandırarak) ve birisi bir dosyanın kilidini açmayı unutursa sorunlara neden olabilir. Ayrıca, en azından SVN için (diğer VCS'ler hakkında emin değilim), bir dosyayı kilitlemek başkasının çalışma kopyasında değişiklik yapmasını engellemez, yalnızca değişikliklerini taahhüt etmelerini önler - bu bir geliştiricinin boşa harcanmasına neden olabilir dosyayı yalnızca kilitlendiğinden değişiklik yapamadıklarını keşfetmek için değiştirir.
Ekipler, geliştiricilere belirli bir dosyada belirli bir dosyada çalışan birden fazla kişiyi olmayacak şekilde görevler vermeye çalışabilirler. Örneğin, geliştiricilerin her biri projenin belirli bir bölümünden (örneğin 3B oluşturma, ağ, ses vb.) Sorumlu olabilir - eğer kod temeli iyi modülerse, o zaman ağ koduna atanmış geliştiricinin dosyalara dokunması gerekmeyebilir ses ile başa çıkmak.

Tabii ki, her zaman başka bir yolla yönetilmesi gereken bazı çakışmalar olacaktır.

— Mac
kaynak

Artı tarafta, kilitleme, bir .JPEG veya başka bir düz olmayan metin dosyasını düzenleyebileceğiniz tek yoldur. Bu teorik bir sınırlama değil, sadece birleştirme araçlarının genellikle emdiği bir şey.

— MS

@ MSalters Bu araçlar emmek değil, sadece birleştirme araçlarının çoğu ikili veriler için değil, metin için oluşturulur. İki değişiklik bir dosyadaki aynı pikseli değiştirirse, bir çakışmayı nasıl çözersiniz? Daha da kötüsü, JPEG sıkıştırmasından kaynaklanan değişiklikleri nasıl etkilersiniz? Tek bir iyi çözümü bile olmayan çok karmaşık bir konudur, bu nedenle birleştirme araçlarının çoğunun desteklememesinin nedeni, bunun gerekliliğinin çok nadir olması ve uygulamanın zor olmasıdır.

— Maurycy,

@ MaurycyZarzycki: Aynı mektubu değiştirmek, aynı pikseli değiştirmeye benzer: manuel çözme gerektirir. .JPEG muhtemelen kötü bir örnekti, şimdi anlıyorum çünkü sanatçılar kayıp biçimlerde çalışmıyor. Ancak birleştirme sorunu .PNG ile de var. En azından, birleştirme araçlarının XML'i parçalamadan birleştirme yeteneğinde olup olmadığını takdir edersiniz.

— MS’e

@ MSalters Elbette, bununla daha fazla katılıyorum.

— Maurycy,

@ xorsyst: Bu şekilde deneyin: İki konumda SVN'den kontrol edin. Sonra bir dosyayı konum 1'den kilitleyin. Konum 2, işleme ya da güncelleme yapılıncaya kadar kilitli olduğunu bilmez.

— Zan Lynx,