Matematik konuşması: Git revizyon kontrol sistemi hakkında teorem?

Git revizyon kontrol sistemi hakkında bir matematik konuşması yapmak istiyorum . Artık matematikte ve bilgisayar bilimi endüstrisinde yaygın olarak kullanılmaktadır. Örneğin, HoTT (Homotopy Type Theory) topluluğu bunu kullanır ve ister kaynak kodu ister lateks işaretleme olsun, metin dosyalarının birlikte düzenlenmesi için sisteme gider.

Git'in bir başlangıç ​​olan yönlendirilmiş asiklik grafik kavramını kullandığını biliyorum. Ancak, iyi bir matematik konuşmasında kanıtlar ve teoremlerden bahsedilir.

Git ile ilgili olarak gerçekten alakalı olan hangi teoremi kanıtlayabilirim?

Git deposu, kısmen sıralanmış bir revizyon seti olarak düşünülebilir (bir revizyonun, öncekinin doğrudan veya dolaylı ardılı olması durumunda sırayla bir öncekinden daha erken olduğu). Git depolarından aldığınız kısmi siparişler düşük genişliğe (karşılıklı bağımsız revizyonların en büyük setinin boyutu) sahip olma eğilimindedir, çünkü genişlik doğrudan aktif geliştiricilerin sayısı ve herhangi bir geliştiricinin çalışabileceği farklı çatalların sayısıyla doğrudan ilişkilidir. üzerinde.

Bu arka plana dayanarak, Dilworth'un herhangi bir kısmi düzenin genişliğinin, tüm sürümleri kapsamak için gereken minimum zincir sayısına (tamamen sipariş edilen alt kümeler) eşit olduğunu belirten teoremini öneririm . Ve bu tahta için konuyu yapmak için, polinom zamanında genişliği hesaplamak ve minimum sayıda zincirle bir kapak bulmak için grafik eşleme tabanlı algoritmalardan da bahsedebilirsiniz.

Bunun Git'te gerçek kullanımla ilgili olabilmesinin bir yolu, bir sistemin sürüm geçmişini görselleştirmek için bir sistemdir: Gördüğüm çoğu Git görselleştirme sistemi, dikey eksende çizim zamanı ve deponun yatay olarak bağımsız sürümleri. görselleştirmeyi az sayıda bağımsız dikey parça halinde organize etmenin bir yolunu sunar.

Alternatif olarak, daha iddialı ve gelişmiş bir şey istiyorsanız , doğrudan git benzeri sürüm kontrol sistemlerinde çatışma çözümü ile motive edilen Demaine ve arkadaşlarının suç ağacı veri yapısını deneyin .

İlginç bir şekilde, sürüm kontrol sistemlerinin yeni doğmuş bir matematiği vardır, ancak bu noktada Git için sadece kısmen uygulanabilir. Buna yama teorisi [1, 2, 3, 4, 5] denir ve DARCS versiyon kontrol sistemi bağlamında ortaya çıktı. Soyut bir dallanma ve birleşme teorisi olarak görülebilir . Son zamanlarda yama teorisine HoTT [6] ve kategorik [7] tedaviler verilmiştir.

Yama teorisi devam eden bir çalışmadır ve sürüm kontrolünün tüm yönlerini kapsamaz, ancak bakabileceğiniz birçok teorem içerir. 'Gerçek dünya' için geçerli olan açık bir teori örneğidir - şaşırtıcı değildir, çünkü yama teorisi çok somut bir şeyin soyutlanması / basitleştirilmesidir. Aynı zamanda HoTT gibi en yeni matematiğe bağlanır.

1. J. Dagit, Tip Doğru Değişiklikler - Versiyon Kontrol Uygulamasına Güvenli Bir Yaklaşım .
2. G. Sittampalam, Darcs yama teorisinin bazı özellikleri .
3. I. Lynagh, Kamp Yolu Teorisi.
4. D. Roundy, Darcs yama formalizmini uygulamak ... ve doğrulamak.
5. J. Jacobson, Ters Yarıgruplar Kullanarak Darcs Yama Teorisinin Resmileştirilmesi .
6. Angiuli, E. Morehouse, DR Licata, R. Harper, Homotopik Yama Teorisi .
7. S. Mimram, C. Di Giusto, Kategorik Yamalar Teorisi .

Başka bir alternatif, kalıcı (veya tamamen işlevsel) veri yapılarına bakmaktır. Git'in iç veri yapısı, tutarlı bir şekilde kalıcı bir ağaç olarak görülebilir :

kalıcı bir veri yapısı, değiştirildiği zaman önceki versiyonunu daima koruyan bir veri yapısıdır. Bu tür veri yapıları, operasyonları yapıyı yerinde (görsel olarak) güncellemediğinden, bunun yerine daima yeni bir güncellenmiş yapı sağladığı için etkili bir şekilde değişmezdir.

Tüm sürümlere erişilebiliyor ancak yalnızca en yeni sürüm değiştirilebilirse veri yapısı kısmen kalıcıdır. Her sürüme hem erişilebiliyor hem de değiştirilebiliyorsa, veri yapısı tamamen kalıcıdır. Ayrıca, önceki iki sürümden yeni bir sürüm oluşturabilen bir kaynak veya birleştirme işlemi varsa, veri yapısı konfluent olarak kalıcı olarak adlandırılır.

Bu soru da önemlidir.

Evet, Git'in nasıl çalıştığını matematiksel olarak tanımlayabilirsiniz. İlkel Git yapılarını ve Git işlemlerini tanımlayabilir ve daha sonra bu işlemleri belirli şekillerde kullanmanın belirli üst düzey hedeflere ulaştığını veya durumun böyle olmadığı durumları karakterize etmeye veya ölçmeye çalıştığını kanıtlayan teoremlere sahip olabilirsiniz. (Örn. Git'in karmalara güvenmesi, hata için küçük bir fark bırakır.)

Başka bir fikir de Subversion için aynı şeyi yapmak, sonra ikisini karşılaştıran teoremler üretmektir. Örneğin, Git'in birleşmelerle uğraşırken daha iyi olduğu iddia edilir; bunu nitel veya nicel olarak kanıtlayan teoremlere sahip olabilirsiniz.

Yararlılık, eleştirel olarak doğru soyutlamaların yapılmasına bağlı olacaktır. Git kaynak kodunun çalışmalarını matematiksel olarak tanımlamak anlamsızdır: kaynak kodun kendisi bunu çok daha etkili ve kısaca yapar.