Kaynak kontrol sistemleri neden hala çoğunlukla dosyalarla destekleniyor?

Daha fazla kaynak kontrol sistemi hala sürüm verilerini depolamak için dosya kullanıyor gibi görünüyor. Vault ve TFS, Sql Server'ı veri deposu olarak kullanıyor, ki veri tutarlılığı ve hız için daha iyi olacağını düşünüyorum.

Öyleyse neden SVN, GIT, CVS, vb. Hala hala dosya sistemini temelde bir veritabanı olarak kullanıyor, (SVN sunucumuzu normal bir işlem sırasında sadece bozuk bıraktığımız için bu soruyu soruyorum) soruyorum. MSSQL, Oracle, Postgre, vb.)

EDIT: Sorumu sormanın bir başka yolu da "VCS geliştiricileri neden mevcut olanı kullanmak yerine kendi yapılandırılmış veri depolama sistemlerini kullanıyorlar?"

TL; DR: Çok az sürüm kontrol sistemi gerekli olmadığından bir veritabanı kullanır.

Bir soruya cevap olarak, neden olmasınlar? Bu bağlamda "gerçek" veritabanı sistemlerinin bir dosya sistemi üzerinden sağladığı faydalar nelerdir?

Gözden geçirme kontrolünün çoğunlukla küçük bir meta veri ve çok sayıda metin farklılığını takip ettiğini düşünün. Metin veritabanlarında daha verimli depolanmaz ve içeriğin endekslenebilirliği bir faktör olmayacak.

Diyelim ki Git (argüman uğruna) veri depolamak için arka ucu için bir BDB veya SQLite DB kullandı. Bu konuda daha güvenilir ne olabilir? Basit dosyaları bozabilecek herhangi bir şey de veritabanını bozabilir (çünkü bu aynı zamanda daha karmaşık bir kodlamaya sahip basit bir dosyadır).

Programcı paradigmasından, gerekli olmadığı sürece optimizasyon yapılmadığı için, revizyon kontrol sistemi yeterince hızlı ve yeterince güvenilir çalışıyorsa, neden tüm tasarımı daha karmaşık bir sistem kullanacak şekilde değiştirdi?

Muhtemelen SVN ve CVS konusundaki deneyimlerinize dayanarak çok fazla varsayımda bulunmuş gibi görünüyorsunuz.

Git ve Mercurial temelde SVN ve CVS'e benzer

Git ve CVS'i karşılaştırmak, iPad ve Atari karşılaştırmak gibidir. Dinazorlar Dünya'yı dolaştığında CVS geri döndü . Yıkılma temel olarak CVS'nin geliştirilmiş bir versiyonudur. Git ve Mercurial gibi modern versiyon kontrol sistemlerinin onlar gibi çok az anlamlı olduğunu varsayarsak.

İlişkisel bir veritabanı, tek amaçlı bir veritabanından daha verimlidir

Niye ya? İlişkisel veritabanları gerçekten karmaşıktır ve tek amaçlı veritabanları kadar verimli olmayabilir. Başımın üstündeki bazı farklılıklar:

• Versiyon kontrol sistemlerinin karmaşık bir şekilde kilitlenmesi gerekmez, çünkü zaten aynı anda birden fazla işlem yapamazsınız.
• Dağıtılmış sürüm kontrol sistemlerinin çok fazla alan verimli olması gerekir, çünkü yerel veritabanı deponun tam bir kopyasıdır.
• Sürüm kontrol sistemlerinin yalnızca birkaç özel yolla verileri araması gerekir (yazara göre, revizyon kimliğine göre, bazen tam metin araması). Yazar / revizyon ID aramalarını yapabilen kendi veritabanınızı yapmak önemsizdir ve tam metin aramaları, denediğim hiçbir ilişkisel veritabanında çok hızlı değildir.
• Sürüm kontrol sistemlerinin birden fazla platformda çalışması gerekir. Bu, bir servis olarak kurulması ve çalıştırılması gereken bir veritabanının kullanılmasını zorlaştırır (MySQL veya PostgreSQL gibi).
• Yerel makinenizdeki sürüm kontrol sistemlerinin yalnızca bir şey yaparken (bir taahhüt gibi) çalışıyor olması gerekir. Sadece bir taahhütte bulunmak istemeniz durumunda , MySQL gibi bir hizmeti her zaman çalışır durumda bırakmak israf demektir.
• Çoğunlukla, sürüm kontrol sistemleri asla geçmişi silmek istemezler, sadece buna ekleyin. Bu farklı optimizasyonlara ve bütünlüğü korumanın farklı yöntemlerine yol açabilir.

İlişkisel veritabanları daha güvenlidir

Yine neden? Verilerin dosyalarda depolandığından, git ve Mercurial gibi sürüm kontrol sistemlerinin atomik taahhütleri olmadığını varsayıyor gibi görünüyorsunuz . İlişkisel veritabanları ayrıca veritabanlarını dosya olarak saklar. CVS'nin atomik bir taahhütte bulunmaması dikkat çekicidir , ancak bu muhtemelen karanlık çağlardan kaynaklanmaktadır çünkü ilişkisel veritabanları kullanmıyorlar.

Veritabanına girdikten sonra verileri yolsuzluklardan koruma sorunu da var ve yine cevap aynı. Dosya sistemi bozuksa, hangi veritabanını kullandığınız önemli değildir. Dosya sistemi bozuk değilse, veritabanı motorunuz bozulabilir. Sürüm kontrol veritabanının neden buna ilişkisel bir veritabanından daha eğilimli olduğunu anlamıyorum.

Dağıtılmış sürüm kontrol sistemlerinin (git ve Mercurial gibi) veritabanınızı korumak için merkezi sürüm kontrolünden daha iyi olduğunu, çünkü tüm repoyu herhangi bir klondan geri yükleyebileceğinizi iddia ediyorum. Merkezi sunucu kendiliğinden yandığı yüzden, eğer tüm yedeklerini birlikte çalıştırmakta tarafından geri yükleyebilirsiniz git initsonra yeni sunucuda git pushgelen herhangi geliştiricinin makine .

Tekerleği yeniden icat etmek kötüdür

Eğer sırf edebilirsiniz herhangi bir depolama sorunu için ilişkisel veritabanını kullanmak size anlamına gelmez gerekir . İlişkisel veritabanı yerine neden yapılandırma dosyalarını kullanıyorsunuz? Verileri ilişkisel bir veritabanında saklarken görüntüleri neden dosya sisteminde saklıyorsunuz? Bunları ilişkisel bir veritabanında saklayabiliyorken kodunuzu neden dosya sisteminde tutuyorsunuz?

"Sahip olduğun tek şey bir çekiçse, her şey bir çiviye benziyor."

Açık kaynaklı projelerin, uygun olduğunda, tekerleği yeniden icat etmeyi göze alabilecekleri gerçeği de var, çünkü ticari projelerle aynı türde kaynak kısıtlamalarına sahip değilsiniz. Veritabanları yazma konusunda uzman bir gönüllünüz varsa, neden kullanmıyorsunuz?

Neden olarak, revizyon kontrol sistemlerinin yazarlarına ne yaptıklarını bilmeleri konusunda güveneceğimiz konusunda .. Diğer VCS'ler için konuşamam, ancak Linus Torvalds'ın dosya sistemlerini anladığından eminim .

Neden bazı ticari sürüm kontrol sistemleri o zaman ilişkisel bir veritabanı kullanıyor?

Büyük olasılıkla aşağıdakilerin bir kombinasyonu:

• Bazı geliştiriciler veritabanı yazmak istemiyor .
• Ticari versiyon kontrol sistemlerinin geliştiricileri zaman ve kaynak kısıtlamalarına sahiptir, bu yüzden zaten istediklerine yakın bir şeyleri olduğunda bir veritabanı yazmayı göze alamazlar. Ayrıca, geliştiriciler pahalıdır ve çoğu kişi bu tür bir deneyime sahip olmadığından, veritabanı geliştiricileri (veritabanlarında yazan insanlar gibi) büyük olasılıkla daha pahalıdır.
• Ticari versiyon kontrol sistemlerinin kullanıcılarının zaten bir ilişkisel veritabanı kurmanın ve çalıştırmanın genel giderini umursamadıkları daha azdır.
• Ticari versiyon kontrol sistemlerinin kullanıcılarının, revizyon verilerini destekleyen ilişkisel bir veri tabanı istemeleri daha muhtemeldir , çünkü bu, işlemleriyle daha iyi bütünleşebilir (örneğin yedeklemeler gibi).

Aslında svndepolarda BDB kullanmak için kullanılır. Bu sonunda çözüldü, çünkü kırılmaya meyilliydi.

Şu anda bir DB (SQLite) kullanan başka bir VCS fossil. Aynı zamanda bir hata izci entegre eder.

Tahminime göre asıl sebep VCS'lerin birçok dosyayla çalışması. Dosya sistemleri başka bir veritabanı türüdür (hiyerarşik, CLOB / BLOB depolama verimliliğine odaklanmış). Normal veritabanları bununla iyi başa çıkmaz çünkü hiçbir sebep yoktur - dosya sistemleri zaten vardır.

1. Bir dosya sistemi olan bir veri tabanı. Tabii ki ilişkisel bir veritabanı değil, fakat çoğu çok verimli anahtar / değer depolarıdır. Ve eğer erişim düzenleriniz bir anahtar-değer deposu (örneğin, git depo formatı) için iyi tasarlanmışsa, bir veritabanı kullanmak muhtemelen dosya sistemini kullanmaktan daha fazla avantaj sağlamıyordur. (Aslına bakarsan, bu yolla girilebilecek başka bir soyutlama katmanıdır.)

2. Veritabanı özelliklerinin çoğu sadece ekstra bagajlardır. Tam metin araması? Tam metin araması kaynak kodu için anlamlı mı? Yoksa farklı şekilde belirtmek mi istiyorsunuz? Bu, aynı zamanda, tüm dosyaları her yayında nadiren saklamanızı gerektirir. Birçok sürüm kontrol sistemi, yerden tasarruf etmek için aynı dosyanın revizyonları arasında depolar, örneğin Subversion ve Git (en azından paket dosyaları kullanırken).

3. Platformlar arası gereksinimleri bir veritabanı kullanarak daha zorlaştırır.

   Çoğu sürüm kontrol aracı birden fazla platformda çalışacak şekilde üretilmiştir. Merkezi sürüm kontrol araçları için bu yalnızca sunucu bileşenini etkiler, ancak Unix kullanıcıları Microsoft SQL Server'ı yükleyemediğinden ve Windows kullanıcıları PostgreSQL veya MySQL'i kurmak istemeyeceklerinden, tek bir veritabanı sunucusuna güvenmek hala zordur. Dosya sistemi en az kullanılan paydadır. Ancak, sunucunun bir Windows makinesine yüklenmesi gerektiği ve bu nedenle SQL Server, örneğin SourceGear Vault ve Microsoft Team Foundation Server gibi bazı araçlar vardır .

   Dağıtılmış versiyon kontrol sistemleri, her kullanıcı havuzun bir kopyasını aldığı için bunu daha da zorlaştırmaktadır. Bu, her kullanıcının depoyu koymak için bir veritabanına ihtiyacı olduğu anlamına gelir. Bu, yazılımı ima eder:

   1. Belirli bir veritabanının bulunduğu bir platform alt kümesiyle sınırlıdır
   2. Çapraz platform olan tek bir veritabanı arka ucunu hedefler (örneğin, SQLite).
   3. Takılabilir bir depolama arka ucunu hedefler, böylece istedikleri veritabanını kullanabilirler (muhtemelen dosya sistemi dahil).

   Bu nedenle çoğu dağıtılmış sürüm kontrol sistemi sadece dosya sistemini kullanır. Bir istisna sourcegear en olduğunu doğruluğu da (yerel depoları için yararlıdır) veya SQL Server gibi bir ilişkisel veritabanı bir SQLite veritabanında saklayabilir, (bir sunucu için muhtemelen yararlı.) Onların bulut çözümü barındırılan olabilir Amazon SimpleDB gibi olmayan bir ilişkisel depolama panelini kullanabilirsiniz , ama bunun doğru olduğunu bilmiyorum.

Pek çok teklifte gördüğüm kadarıyla, dosyalar, iş için "yeterince iyi" görünüyor, günün sonunda VCSes çıktısının da dosyalar olduğunu göz önünde bulundurarak makul bir şey.

Bir svn / git / etc ara yüzü ile bir RDBMS arka ucu sunan birçok şirket var.

Bunun bir sürüm kontrol sisteminin birincil veri yapısının veritabanlarını çok zayıf eşleyen bir DAG olduğu için olduğunu söyleyebilirim. Verilerin çoğu da içerik olarak adreslenebilir ve bu da veritabanlarını çok zayıf eşler.

Veri bütünlüğü bir VCS'nin tek kaygısı değildir, aynı zamanda veritabanlarının çok iyi olmadığı sürüm geçmişi bütünlüğü ile de ilgilidir . Başka bir deyişle, bir sürüm aldığınızda, yalnızca sürümün mevcut kusurlarının olmadığından emin olmanız gerekmez, aynı zamanda tüm tarihi boyunca hiçbir şeyin gizlice değiştirilmediğinden emin olmanız gerekir.

VCS ayrıca bir kurumsal ürüne ek olarak bir tüketici ürünüdür. İnsanlar bunları küçük, tek kişilik hobi projelerinde kullanıyor. Bir veritabanı sunucusu kurma ve yapılandırma zorluğunu eklerseniz, pazarın o bölümünü yabancılaştırırsınız. Evde çok fazla Vault ve TFS kurulumu göremediğini tahmin ediyorum. Elektronik tabloların ve sözcük işlemcilerin veritabanlarını kullanmalarının nedeni aynıdır.

Ayrıca, bu DVCS için bir nedendir, ancak bir veritabanı kullanmamak onu son derece taşınabilir kılar. Kaynak ağacımı bir başparmak sürücüsüne kopyalayabilir ve herhangi bir makinede, bir veritabanı sunucusu işlemi yapılandırmak zorunda kalmadan yeniden kullanabilirim.

Bildiğim kadarıyla kaydedilmesini sırasında bozulmasını olarak VCS hem Yolsuzluklar çok nadirdir vb eşzamanlı erişimi, atomik yapmak işlemleri önlemek için veritabanları ile tam olarak aynı teknikleri kullanır, ancak do olur . Tüm niyet ve amaçlar için, bir VCS veri deposu olan bir veri tabanı.

• Daha iyi felaket kurtarma (en kötü durum senaryosu: eski zamanlardaki gibi gözle ayrıştırırız)

• Muhtemelen VCS sistemindeki arızalardan kaynaklanan bu tür felaketlerin takibi ve hata ayıklamasını kolaylaştırmak.

• Bağımlılık sayısının azaltılması. (Unutmayalım ki bu sistemlerden birini idare ediyor) çekirdek ve diğer gerekiyordu)

• Bir metin editörü her zaman kullanılabilir. (MS SQL Server lisansları ... çok değil)

Fosil , mükemmel bir Dağıtılmış Sürüm Kontrol Sistemidir (DVCS) ve depolama için SQLite kullanır, düz metin dosyaları içermez.

Entegre etmekten gerçekten hoşlanıyorum: hata izleme, Wiki ve gerçekten dağıtılmış. Yani gerçekten çevrimdışı çalışıp hataları düzeltebilirsin.

Fosil, Sqlite'ı uygulama dosyası formatı olarak kullanır. In PgCon de açılış Dr Richard Hipp bir Uygulama Dosyası Sistemi olarak sqlite kullanmanın avantajları nelerdir açıklar ve dosya sistemi gibi bir veritabanı kullanmanın faydalarından oldukça inandırıcı argümanlar.

İkinci ana konu, SQLite'ın kendi dosya formatlarını icat etmeye ya da ZIPped XML'leri kullanmaya alternatif bir uygulama dosya formatı olarak görülmesiydi. “SQLite” ifadesi PostgreSQL'in yerine geçmez. SQLite (21) slayt fopen () ”çiviler yerine geçer. Sonunda, Richard, SQLite'ın verilerinize dikkat ettiği ( çökmeye karşı güvenli, ACID) kullanımına çok dikkat çekti - use-the-index.com

Şimdi Dr. Hipp , bir veritabanında kod kaydetme konusundaki endişeleri dile getirdi

• Fosil neden dağıtılmış bir NoSQL veritabanı yerine SQLite'a dayanmaktadır?

Fosil, SQLite'a dayanmamaktadır. Fosil'in şu anki uygulaması, SQLite'yi dağıtılmış veritabanının içeriği için yerel bir mağaza olarak ve hızlı ve kolay sunum için önceden hesaplanan dağıtılmış veritabanı hakkında meta bilgiler için bir önbellek olarak kullanır. Ancak bu rolde SQLite kullanımı bir uygulama detayıdır ve tasarım için temel değildir. Fossil'in gelecekteki bazı sürümleri SQLite ile başa çıkabilir ve bir dosya yığını veya SQLite yerine anahtar / değer veritabanını kullanabilir. (Aslında, SQLite şu anki rolünde şaşırtıcı derecede iyi çalıştığı için gerçekleşmesi pek mümkün değil, ama nokta, SQLite’i Fosil’den çıkarmak teorik bir olasılık.)