Her dosyayı ayrı ayrı sürüm sürüm kontrol sistemlerinin avantajları nelerdir?

15

Son birkaç yıldır birkaç farklı versiyon kontrol sistemi ile çalıştım. Benim için aralarındaki temel farklılıklardan biri, dosyaları ayrı ayrı sürümlendirmeleri (her dosyanın kendi ayrı sürüm numaralandırmasına ve geçmişine sahip olması) veya bir bütün olarak deponun ("taahhüt" veya sürüm, tüm deponun anlık görüntüsünü temsil etmesi) olmuştur. .

Bazı "dosya başına" sürüm kontrol sistemleri:

CVS
ClearCase
Visual SourceSafe

Bazı "tam depo" sürüm kontrol sistemleri:

SVN
Git
cıvalı

Deneyimlerime göre, dosya başına sürüm kontrol sistemleri sadece sorunlara yol açtı ve doğru şekilde kullanmak için çok daha fazla yapılandırma ve bakım gerektiriyor (örneğin, ClearCase'deki "yapılandırma özellikleri"). İlişkisiz bir dosyayı değiştiren ve ideal bir şekilde izole edilmiş bir geliştirme çizgisi olacak şeyi kıran bir iş arkadaşının birçok örneğini yaşadım.

Bu dosya başına sürüm kontrol sistemlerinin avantajları nelerdir ? "Tüm havuz" sürüm kontrol sistemlerinde dosya başına sürüm kontrol sistemlerinin sahip olmadığı sorunlar nelerdir?

version-control

— Mike Daniels
kaynak

3

Bence bu sadece tarihsel olarak böyleydi ve biz artık dosya yönelimli ve değişiklik kümesi yönelimli sistemlere geçiyoruz, ama bugünün bakış açısından insanların neden dosya başına yaklaşımı denediğini anlamak zor. Mükemmel soru!

— blubb

Bu sorunun tartışmacı olarak ortaya çıkması durumunda özür dileriz. Son zamanlardaki hayal kırıklığının bir ürünü.

— Mike Daniels

1

@Mike Daniels: Avantajları açıkça istediğin gibi (en azından bana göre).

— blubb

Bu iki bakış açısı sadece farklı sözleşmelerdir. Birini diğeri lehine savunan argümanlar sadece diğer tarafın partizanlarından karşı argüman çıkarır. Örneğin, Clearcase'de "tam yanıt" davranışı istiyorsanız, yapılandırma spesifikasyonunuzu tarihe göre özelleştirebilirsiniz.

— mouviciel

SVN'nin dosya başına sürümü var mı, yoksa bu son sürümde de değişti mi?

— Klaim

12

Benim tecrübelerime göre, "tam depo" VCS kesinlikle "dosya başına" VCS hakim.

— Rein Henrichs
kaynak

3

Aynı havuzdan ürün hatları (birden çok yazılım ürünü) oluştururken dosya başına bir avantajı vardır.

Bazı müşteri sözleşme ortamları, kodlarının SADECE diğer değişikliklere değil, istedikleri değişikliklere sahip olduğuna dair kanıt gerektirir. Dosya sürüm numaraları hala aynı ise, bu oldukça kolaydır.

Ve bu ince havadan çektiğim rastgele bir örnek değil.

Bu, en son işverenimden çok sayıda satın aldıkları bir sistem için ABD ordusuna yazılım güncellemeleri gönderiyorum. Sözleşmelerin dolar değeri kesirli milyarlarca dolar olarak ölçüldü (ABD doları çok daha değerli olduğunda)

Bu yüzden birkaç kez yardımcı olur.

İşin garibi: şu anda nerede çalıştığımıza, her müşteriye farklı bir teslimat malzemesi de gönderiyoruz .... (Ve merak ediyorsanız, karar verdiğim bir şey değil.)

Savunma / havacılık alanında küçültme veya web uygulamalarından çok daha yaygın olduğundan şüpheleniyorum.

— Tim Williscroft
kaynak

3

Ancak tüm dosya havuzunun bir kolu da aynı ihtiyaçları karşılayacaktır. Örneğin, bzr'de, birleştirme işleminize (veya bir depo paylaşana) kadar şubeler ana hattan tamamen bağımsızdır.

— edA-qa mort-ora-y

1

Bir "tam havuz" sistemindeki şubenin, "dosya başına" VCS'de hangi dosyaların kullanılacağını belirlemek için VCS dışındaki duruma güvenmektense gerekli durumu daha iyi ifade edemeyeceği tek bir durumu düşünemiyorum. Uni'den sonraki ilk işim, RCS, projeyi sürümlendirmek için bir dizi komut dosyası ve sürüm komut dosyalarını sürümlemek için bir üst düzey komut dosyası kullandı - mutlak bir kabus ve evet, bu da askeri bir proje içindi. * 8 ')

— Mark Booth

@Mark Booth, müşteri istediği düzeltmeler için hangi dosyaların değiştirildiğini biliyordu. Fiziksel yapılandırma denetimi sürüm kontrol numarasına göre yapıldı

— Tim Williscroft

Dediğim şey, bir sürümün + denetlenen bir yamanın farklı yerlerde, VCS ve denetçilerde farklı bilgiler gerektirmesidir . 'Tüm depo' sistemindeki bir dalla, bu iki durum ayrı varlıklar olarak kaydedilir. Şimdi aynı bilgiler VCS ve denetim sistemi arasında çoğaltılmaktadır ve her zaman eşleşmelidir. gityazar ve tacir arasında bile ayrım yapabilir, böylece hem yamayı (yazar) hem de denetleyiciyi kimin (denetçi) denetlediğini bildiğiniz 'denetlenmiş' bir depo tutabilirsiniz. Bize örnek bir durum sağlayın ve -1'i tersine çevireceğim.

— Mark Booth

@ Mark standında hangi yamalar var? yazılımlarının bu dosya kümesi olduğunu biliyorlardı A 1.01 B 1.05 D 1.55 E 1.44 F 1.01 ve kabul ettikleri sürüm için SVD dosya-dosya değişikliği bilgisi vardı, örneğin E kusur 1104, eski sürüm 1.43, yeni sürüm 1.44 düzeltmek için değiştirildi . 1.01 sürümünden F'yi değiştirirsek cennet bize yardım eder. Durum daha karmaşıktı çünkü düzeltilen gerçek hatalar vardı, değişiklik istemiyorlardı. Bu insanlar, bir yıllık gelişimden sadece kirazın seçtiği bazı özellikleri almak için minimum değişiklik setini istiyorlardı. Post-hoc hata düzeltme seçimi.

— Tim Williscroft

3

Dosya başına sürüm oluşturmanın hiçbir avantajı yoktur.

Dezavantajlar diğer taraftan, bol ve kendilerini belli ederler.

— William Payne
kaynak

0

"Dosya başına" sürüm kontrol sistemlerinin VCS'nin uygulanmasından başka belirgin avantajları olmadığını söyleyebilirim. VCS kodlayıcıları, "dosya başına" sürümleme olduğunda kodlamaktan memnuniyet duyar. Tarihsel olarak ortaya çıktığı noktasını kabul ediyorum.

— Arvind Chinniah
kaynak

0

İlişkili dosyalarınız olduğunda dosya başına yaklaşımın bir avantajı yoktur. Bir geliştirme ayarlarında en yaygın durum budur.

Birkaç tuhaf durumda - / etc veya. Unix'teki ana dizininizdeki dosyalar rutin olarak sahip olduğum tek dosyadır - ilgisiz dosyaları (çoğunlukla) işliyorsunuz. Ve sonra ilgisiz değişiklikleri senkronize etmede ısrar eden bir sisteme sahip olmak sıkıntı yaratabilir.

— Programcı
kaynak