SQLite neden Git kullanmıyor

 (sqlite.org)
2 puan yazan GN⁺ 2023-07-24 | 1 yorum | WhatsApp'ta paylaş
  • SQLite kaynak kodu Git yerine Fossil ile yönetiliyor; Fossil, SQLite’ı desteklemek için özel olarak tasarlanıp yazılmış bir sürüm kontrol sistemi
  • Fossil, tüm branch’lerdeki son değişiklikleri tek ekranda gösteren durumsal farkındalık (situational awareness) özelliği sunuyor ve telefondan da erişilebiliyor
  • Git, check-in’lerin yalnızca önceki geçmişini izler ve sonraki devamlarını (descendants) takip etmek zorken, Fossil sonraki check-in’leri ve branch yapısını kolayca gösteriyor
  • Git’te çalışma dizini, staging, yerel/uzak head gibi 5 durumu akılda tutmak gerekirken, Fossil yalnızca çalışma dizini ve check-in’i dikkate alarak %60 daha az yük getiriyor
  • Git’e alışkın kullanıcılar da GitHub mirror’ı, web indirme veya Fossil kurulumu üzerinden SQLite kaynak koduna aynı şekilde erişebiliyor

Genel bakış ve yazının ön kabulleri

  • SQLite, Git yerine Fossil kullanıyor ve Fossil, SQLite desteği amacıyla doğrudan oluşturulmuş bir sürüm kontrol sistemi
  • Bu yazı Fossil ile Git’in genel bir karşılaştırması değil ve Git’i bırakmayı da önermiyor
    • Git’ten memnunsanız kullanmaya devam etmenizde sakınca yok
    • Git size uygun gelmiyorsa ya da iyileştirme ve alternatifleri düşünüyorsanız, burada faydalı bir bakış açısı bulunabilir
  • Bu belge, açıklığı artırmak ve hataları düzeltmek için birçok kez gözden geçirildi; tüm düzenleme geçmişi görüntülenebiliyor

SQLite’ın Git kullanmama nedenleri

Git iyi bir durumsal farkındalık sağlamıyor

  • Fossil’in timeline görünümü, tüm branch’lerdeki son değişikliklerin özetini tek ekranda sunuyor; birkaç tıklamayla ayrıntılara inilebiliyor ve bu görünüm telefonda da kullanılabiliyor
  • GitHub ve GitLab’da bununla kıyaslanabilecek bir özellik yok
    • network görünümü yavaş render ediliyor (önbellek öncesi), az ayrıntı sunuyor ve mobilde neredeyse hiç çalışmıyor
    • commits görünümü hızlı ve mobilde çalışıyor, ancak aynı anda yalnızca tek bir branch’i gösterdiği için tüm değişiklikleri görüp görmediğinizi anlamak zorlaşıyor
    • GitHub ve GitLab, Git’in çekirdek bileşenleri değil, üçüncü taraf hizmetler; bu da ek bağımlılık yaratıyor
  • Git kullanıcıları sık sık üçüncü taraf grafik görüntüleyiciler kuruyor, ancak bunlar ayrı kurulum ve bakım gerektiriyor ve platforma bağlı kalıyor
    • iyi araçlardan biri olan GitUp yalnızca Mac’te çalışıyor
    • tüm araçlar yerel depoyu eşitledikten sonra masaüstü GUI çalıştırmayı gerektiriyor; dışarıdayken telefondan proje durumunu kontrol etmek mümkün olmuyor

Git’te bir check-in’in devamını (soyunu) bulmak zor

  • Git geçmişe bakmayı sağlıyor, ancak sonrasında neler geldiğini izlemek zor
    • belirli bir eski check-in için önceki geçmiş görülebiliyor ama sonrasında ne geldiğini görmek zahmetli
  • Fossil, son büyük sürümden türeyen tüm check-in’leri gösteren bir ekran sunuyor
  • Git’te de soy takibi imkânsız değil, ama zor
    • Stack Overflow’da Unix için bir komut dizisi bulunuyor, ancak bu komut branch yapısı olmadan yalnızca bir soy listesi veriyor
    • bu komut yalnızca yerel clone varsa çalışıyor; GitHub veya GitLab gibi web arayüzlerinde soy takibi yapılamıyor
  • Fossil’de soy bilgisi web sayfalarının geneline yansıyor
    • her check-in bilgi sayfasında, bir önceki ve bir sonraki check-in’i gösteren küçük bir "Context" grafiği yer alıyor
    • bir sonraki check-in’e tıklayarak ilerleme gibi, durumsal farkındalığı artıran özellikler sunuluyor
  • Git’te de uygun eklenti, araç veya komutlarla teorik olarak mümkün olsa da kolay değil ve bu yüzden neredeyse hiç yapılmıyor; sonuç olarak geliştiricilerin kod değişikliklerine dair farkındalığı düşüyor

Git’in zihinsel modeli gereksiz yere karmaşık

  • Git kullanıcılarının sürekli şu 5 şeyi akılda tutması gerekiyor
    1. çalışma dizini (working directory)
    2. "index" veya staging alanı
    3. yerel head
    4. uzak head’in yerel kopyası
    5. gerçek uzak head
  • Fossil kullanıcıları ise yalnızca çalışma dizinini ve üzerinde çalıştıkları check-in’i düşünmek zorunda; bu da %60 daha az dikkat dağılması anlamına geliyor
    • geliştiricinin sınırlı dikkatini (brain-cycles) koruyarak sürüm kontrol sistemi yerine geliştirdiği yazılıma odaklanmasına yardımcı oluyor
  • Hem Git hem Fossil kullanan bir kullanıcı, HN’de şöyle diyor: "Fossil tek komutla her şeyin sunucuyla senkronize olduğuna dair iç rahatlığı veriyor, git’te ise bu rahatlığı bulamıyorum"

Git geçmiş branch adlarını takip etmiyor

  • Git, check-in dizisinin tüm DAG yapısını koruyor, ancak branch etiketleri yerel bilgi olarak kalıyor; eşitlenmiyor ve branch kapandıktan sonra da korunmuyor, bu yüzden eski branch’leri incelemek zahmetli hale geliyor
  • Örnek: 2 yıl önceki 'prefer-coroutine-sort-subquery' branch’inin ne olduğunun sorulması
    • Fossil: bu branch’in sonunda trunk’a merge edildiğini, nerede başladığını ve trunk değişikliklerinin iki kez branch’e merge edildiğini açıkça gösteriyor
    • GitHub: bu bilgileri hiç göstermiyor ve ne olduğunu anlamakta fiilen işe yaramıyor
  • Üçüncü taraf GUI’ler daha iyi olabilir, ancak Git’in senkronizasyon sırasında eski branch adlarını korumaması sınırına takılıyorlar
    • istenen bilgiyi almak için üçüncü taraf araca ihtiyaç duyulması, çekirdek sistemin zayıflığını zaten gösteriyor

Git daha fazla yönetim desteği gerektiriyor

  • Git karmaşık bir yazılım; iş istasyonlarına kurulup yükseltilmesi için yükleyici gerekiyor ve Git sunucusu kurmak da kolay değil
    • çoğu durumda GitHub veya GitLab gibi üçüncü taraf hizmetler kullanılıyor ve bu da ek bağımlılık yaratıyor
  • Fossil ise $PATH içine konduğunda kurulumu tamamlanan tek bir bağımsız çalıştırılabilir dosya
    • bu tek dosya, Git’in çekirdek işlevleriyle birlikte GitHub ve GitLab’in sunduğu özellikleri de içeriyor
    • wiki, hata takibi, forum içeren topluluk sunucusu yönetimi, paket indirme sunumu ve giriş yönetimi gibi işleri ek yazılım olmadan yapabiliyor
    • bir topluluk sunucusu kurmak yalnızca birkaç dakika sürüyor
    • aylık 5 dolarlık bir VPS veya Raspberry Pi üzerinde rahat çalışırken, GitLab gibi araçlar daha yüksek sistem gereksinimi istiyor
  • Yönetim yükü ne kadar azsa, geliştiriciler de sürüm kontrol sistemi yerine yazılımın kendisine (SQLite) o kadar fazla zaman ayırabiliyor

Git kötü bir kullanıcı deneyimi sunuyor

  • xkcd 1597 çizgi romanı abartılı olsa da gerçeğe yakın
  • Git’in vasat bir kullanıcı deneyimi sunduğu konusunda çok az itiraz var ve iç uygulama ayrıntıları doğrudan arayüze yansıyor
    • sahte git man sayfaları üreten bir parodi sitesinin var olması bile arayüzün ne kadar kötü olduğuna işaret ediyor
  • İyi bir sürüm kontrol sistemi, hayal kırıklığı değil destek sunmalı; Git son 10 yılda iyileşti ama hâlâ gidecek yolu var

Git kullanıcıları için SQLite kaynak koduna erişim rehberi

Resmî GitHub mirror’ı

  • 2019-03-20’den bu yana GitHub’da SQLite kaynak kodunun resmî Git mirror’ı bulunuyor
  • Bu mirror, resmî Fossil deposundan artımlı dışa aktarımla besleniyor; bir cron görevi GitHub deposunu saatte bir güncelliyor
    • tek yönlü, salt okunur bir mirror olduğu için pull request veya değişiklik kabul etmiyor
    • tüm değişiklikler yalnızca Fossil üzerinden giriliyor
  • Check-in ve dosya tanımlayıcı hash’leri Git mirror’ında ve Fossil’de birbirinden farklı
    • bunun ana nedeni Fossil’in SHA3-256, Git’in ise SHA1 hash kullanması
    • dışa aktarma sırasında özgün Fossil hash’i check-in yorumunun sonuna ekleniyor; SQLite check-in’lerine atıf yaparken karışıklığı önlemek için her zaman özgün Fossil hash’inin kullanılması öneriliyor

Web erişimi

  • SQLite Fossil deposu, herhangi bir eski sürüm için Tarball, ZIP Archive ve SQLite Archive indirme bağlantıları sunuyor
  • URL biçimi basit olduğu için otomasyon araçlarına kolayca entegre edilebiliyor
    • temel biçim: https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz
    • VERSION alanında hash öneki, branch adı veya etiket (ör. "version-3.23.1") kullanılabiliyor
    • en son sürüm için "release", en güncel trunk için "trunk" kullanılabiliyor
    • ZIP ve SQLite Archive için "/tarball/" kısmı "/zip/" veya "/sqlar/" ile değiştiriliyor

Fossil erişimi

  • Fossil’in kurulumu ve kullanımı kolay; Unix için süreç aşağıda verilmiş durumda (Windows’ta da benzer)
    • fossil çalıştırılabilir dosyasını indirip $PATH içine yerleştirin
    • fossil clone ile depoyu kopyalayıp fossil open ile açın
    • ardından ./configure; make (Windows MSVC için nmake /f Makefile.msc) çalıştırılabilir
  • fossil update VERSION komutuyla farklı bir sürüme geçilebiliyor (VERSION alanında trunk, hash öneki, branch veya etiket kullanılabilir)
  • Checkout içinde fossil ui komutuyla yerel bir web sitesi başlatılabiliyor
    • giriş yapılmadan değişiklik push edilemediği için projeye zarar verme riski yok; bu yüzden rahatça gezip deney yapabilirsiniz

Kaynak kod bütünlüğünün doğrulanması

  • Kaynak ağacının kökünde bir "manifest" dosyası bulunuyor
    • bu dosya tüm dosya adlarını ve her dosyanın SHA1 veya SHA3-256 hash’ini içeriyor (eski dosyalar SHA1, yeni dosyalar SHA3-256)
    • bir script ile hash’ler çıkarılıp kaynak dosyalarla karşılaştırılarak doğrulama yapılabiliyor
  • Bir check-in’in hash adı, "manifest" dosyasının kendisinin SHA3-256 hash’idir; son satır "# Remove this line..." ile başlıyorsa o satır göz ardı edilebilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-07-24
Hacker News görüşleri

  • Onlarca yıl boyunca kullandığım sürüm kontrol araçlarını, yapıldıkları yılı ve son kullandığım yılı sıraladım: sccs 1973~2000, rcs 1982~2000, cvs 1990~2004, clearcase 1992~2004, perforce 1995~2011, subversion 2000~2015, mercurial 2005~2015, git 2005~günümüz
    En azından benim için bu araçların ömrü kabaca 15 yıl civarındaydı
    Ama gençlere “siz benim yaşıma geldiğinizde git uzak ve tuhaf bir hatıra olacak” dediğimde bana garip bakıyorlar
    git harika bir araç ve başarılı olmayı hak etti ama bu sorunun git ile son bulması biraz üzücü olurdu

    • Adil olmak gerekirse, yeterince iyi anlaşılan bir problem alanında her tür aracın değişim hızı yavaşlar
      Joel on Software'da yazılımın genelde yaklaşık 4 sürümde neredeyse tamamlandığını söyleyen bir yazı vardı; örnek olarak da ofis yazılımları, özellikle Excel verilmişti
      Şu an Excel 4'ü açsanız bile, temel işlevler açısından özünde yapması gereken her şeyi yaptığını söylemek mümkün
      git'in önceki sürüm kontrol araçlarına kıyasla en az iki kat daha uzun ömürlü olacağını düşünüyorum
    • Subversion temelde CVS'nin düzgün yapılmış hali
      Sorun, CVS'nin dağıtık geliştirme modeline genişleyemeyen bir çıkmaz sokak olmasıydı
      Git, yerel RCS modeline geri döndü ve buna atomik commit'leri ekledi; böylece Subversion denilen yerel optimumdan çıkabildi
      İsim değişikliklerini takip etmemek ya da doğrusal revizyon numaralarının olmaması gibi tartışmalı tercihler vardı ama bunlar büyük sorun olmadı; ayrıca darcs türü performans sorunları olmadan çok verimli çalışma imkânı sağladı
      1995~2010 arasında sürüm kontrolünü düzeltmeye yönelik bu kadar çok girişim olmuş olması, git'in temel veri modelinin git-lfs gibi ek özellikler hesaba katılsa bile geliştirilmesinin çok zor göründüğünü düşündürüyor
      Yeni komut satırı arayüzleri çıkabilir ama mevcut güçlü oyuncuyu yerinden etmek giderek zorlaştı; aşırı yüklü ve kafa karıştırıcı git checkout yerine git switch ve git restore kullanan kimseyi etrafımda görmüyorum
    • 15 yıl sonra ne kullanıyor olacağımızı bilmiyorum ama o listedeki gerçekten üzücü şey, 2015'te mercurial kullanmayı bırakmış olmam ve hâlâ git kullanıyor olmam
    • İlk şirketimde bir projeyi clearcase'den git'e taşıdık; clearcase'i sevmeyen biri olarak ben bile o zamana kadar özellikle başka bir şeye geçmek için güçlü bir neden olmadığını düşünüyordum
      Şirketin diğer bölümlerinde biraz svn vardı ama o kadardı
      Sürüm kontrol sistemleri o kadar hızlı değişmiyor
      Dağıtık sürüm kontrolü ortaya çıkmadan önce listedeki araçların aslında oldukça fazla ortak noktası vardı ve git'in epey uzun süre kalacağını düşünüyorum
    • İnternet, bir şeyi sabitleme eğiliminde
      Tarih boyunca pek çok dil baskın oldu ama İngilizce nihai dil olacak; birçok script dili vardı ama javascript nihai dil olacak; birçok ağ protokolü vardı ama TCP/IP nihai protokol olacak
      Bence git için de durum aynı
      git'i yerinden edebilecek şey, glitch[1] örneğinde olduğu gibi yeni programcılara yönelik bir ortamın kendi sürüm kontrol sistemini beraberinde getirmesi olabilir
      [1]: https://medium.com/glitch/reinventing-version-control-with-g...

  • Bence git'in kötü bir üne sahip olmasının nedeni, kimsenin nasıl kullanılacağı konusunda uzlaşamaması
    Sadece GitHub PR'leri ve branch'e push etme, rebase ve merge'e bakınca bile, özünde aynı işi tamamen farklı şekillerde yapan araçlar görüyoruz
    Sorun şu ki iki taraf da yanlış değil
    Küçük commit'leri rebase etmek, kayıttaki gereksiz karmaşıklığı azaltıyor; merge ise gerçekte ne olduğunu koruyarak değişikliğin nedenini anlamaya yardımcı oluyor
    Tabii ters yönde merge en kötüsü ama bu da ayrı bir baş belası
    Bir branch'e push ederken hiç force push yapmayabilirsiniz ama PR branch'lerinde neredeyse her zaman force push yapılır
    Hatta kolay şeyler bile çözülemez ayrılıklar yaratıyor
    Ben ana depoya origin, kendi fork'uma fork demeyi öğrendim ama bazıları ana depoya upstream, kendi fork'una origin diyor
    İkisi de mutlaka yanlış değil ama origin tamamen farklı iki yeri gösterebiliyorsa açık ve net iletişim kurmak çok zorlaşıyor

    • Bjarne Stroustrup'u uyarlarsak, sadece iki tür sürüm kontrol sistemi vardır: insanların şikâyet ettiği ve kimsenin kullanmadığı
    • Faydalı bulduğum yaklaşım şu: “şu anki doğrudan hedefe uygun olanı yap, sonra yeniden değerlendirip uyum sağla”
      Pratikte bu, PR içindeki commit'leri “incelemeyi en kolay ne yapar?” sorusuna odaklanarak agresif biçimde rebase etmek anlamına geliyor
      İnceleme bittikten sonra da “ileride işletmesi ve anlaması en kolay biçim ne olur?” diye soruyorum; hepsini squash edebilirim ya da rollback'i kolaylaştırmak için bağımsız dağıtılabilir parçalara yeniden düzenleyebilirim
      Kilit nokta, bu işlerin farklı ihtiyaçlara sahip olabileceği ve zamana göre farklı yaklaşımlar kullanmanın sorun olmadığı
      Ancak bu, daha fazla kişisel muhakeme gerektiriyor ve büyük bir ekibin tamamına öğretip zorunlu kılmak daha zor
    • Yerel tutarsızlık ile sosyal tutarsızlık arasındaki farkı ayırmak önemli
      İlki başkalarını etkilemeyen şeylerdir
      Örneğin uzak depo adlarını origin ve upstream ya da fork ve origin yapmanız takım arkadaşlarınızı ilgilendirmez
      İkincisi ise başkalarıyla koordinasyon gerektiren şeylerdir
      Örneğin nihai git geçmişinin nasıl bir biçimde bırakılacağı gibi konular
    • git'in kötü bir üne sahip olmasının nedeni komut satırı arayüzünün korkunç derecede dağınık olması
      Apple git'in komut satırı arayüzünü tasarlasaydı, kullanıcı deneyimi açısından muhtemelen milyar kat daha iyi olurdu ve gücü de yalnızca %10 kadar azalırdı

  • Fossil’in onlara çok uygun olmasına sevindim ama şu ifade gözüme batıyor: “Fossil, yalnızca $PATH içine koyarak kurulabilen tek bir bağımsız çalıştırılabilir ikili dosyadır ve bunun içinde hem temel Git işlevleri hem de GitHub/GitLab işlevleri bulunur…”
    Git’in pek çok sorunu olsa da mutfak evyesini bile aynı pakete tıkıştırma yaklaşımı değil
    Ben “tek bir işi iyi yap” yaklaşımını daha iyi buluyorum

    • Aslında Git de insanların pek fark etmediği birçok şeyi içinde barındırıyor
      Örneğin git instaweb çalıştırırsanız, çok basit bir web UI sunmak için yerel bir CGI sunucusu ve Perl CGI betikleri ayağa kaldırır: https://git-scm.com/docs/git-instaweb
      Bu açıdan Fossil’in sunduğu çekirdek işlevlerden çok da farklı değil
      Sadece GitHub kullananlar muhtemelen varlığından bile, neden var olduğundan da habersizdir ama Git’te e-posta istemcisi entegrasyonu ile ilgili birçok özellik var
      Örneğin Git içinden doğrudan e-posta yaması göndermeyi sağlayan git send-email: https://git-scm.com/docs/git-send-email
    • “Tek bir şey”in yalıtılabileceği ve onun başlı başına “başka şeylerin birleşimi” olmadığı fikri, programlama dünyasındaki epey zararlı mitlerden biri
      Her şey bileşiktir, her şey komutların bir pipeline’ıdır, her şey birden çok parçadan oluşur
      “Yapılması gereken iş” mutlak değildir; bakan kişinin perspektifine bağlıdır
      Tek sorumluluk ilkesi gerçeğe birebir uygulanmaz; yalnızca bağlaşıklık ve modülerlik arasında denge kurmaya çalışan bir uzlaşmadır
      Nereden kesip buna “tek” diyeceğimiz bize ve ihtiyaçlarımıza bağlıdır
      Birçok kişi için GitHub araçları iş akışlarına o kadar entegre olmuş durumda ki Git tek başına hiç kullanışlı değil
      Onlar için GitHub “tek şey”dir; SQLite için de SQLite’ın kendi “tek şeyi” vardır
    • SQLite harika ve Richard’ın bir dahi olduğu da açık, ama tek ikili dosyalı monolit takıntısı bana hep tuhaf gelmiştir
      Dediğiniz gibi, bu yaklaşım tek bir işi iyi yapmaya dayanan Unix felsefesiyle çelişiyor
      Bana göre bir sistemi, daha sonra bağımsız biçimde değiştirilebilecek ya da düzeltilebilecek bileşenlere ayırmak açıkça daha temiz
    • Git, asıl *nix ortamında mutfak evyesini pakete katmıyor ama Git for Windows bunu yapıyor
      Kurulum dosyası 50MB’ı aşıyor ve yanlış hatırlamıyorsam terminali de içeriyor
      Buna karşılık Fossil için desteklenen her platform adına 3.3MB’lık bağımsız bir ikili dosya indirilebiliyor
    • Git bunları paketlemediği için, modern bir kaynak kodu yönetim sistemi için gerçekte gereken eksik parçaları sağlayan GitHub veya GitLab’a bağımlı hale geliyorsunuz

  • https://git-man-page-generator.lokaltog.net uzun zamandır gördüğüm en komik şeylerden biri

    • git-erase-working-tree açıklaması şöyle: “upstream root’u ve ayarın geçerli çalışma ağacını dikkatlice silmek ve bunu etkin GUI ile quiltimport etmek istediğinizde kullanılmalıdır”; kulağa faydalı geliyor
    • git-molest-head için de “uzaktaki indeksi kullanarak upstream head’i uygunsuz biçimde rahatsız eder ve verilen head’i tabloya dönüştürmek için uygun hook’ları çalıştırır” deniyor; biraz fazla kışkırtıcı
    • Bunun gerçek olmadığını fark etmem gereğinden fazla uzun sürdü
      Git’te zaten yeterince tuhaf komut var; artık şaşırtmıyor
    • En sevdiğim komutlar git-tease-chain, git-scrub-dangling-object, git-seize-mailmap, git-dress-graft, git-strangle-tree, git-satisfy-daemon, git-pat-tree-object
    • Pek inandırıcı gelmiyorlar
      Daha iyi saçmalamak için biraz daha LLM baharatı lazım

  • Önceki tartışmalar:
    2021, 356 yorum: https://news.ycombinator.com/item?id=29125934
    2018, 608 yorum: https://news.ycombinator.com/item?id=16806114
    Başkaları da vardır muhtemelen; ama aynı belge www alan adı olmadan da, /drafts/ yolu olmadan da, /matrix/ yolu olmadan da birden fazla yoldan bulunabildiği için önceki gönderileri bulmak daha da zorlaşıyor

  • Burada Git’e yönelik haklı eleştiriler de var ama bazıları biraz tuhaf görünüyor
    Yerel kişisel depolardan çok büyük şirket depolarına kadar çeşitli ortamlarda Git kullandım ve dürüst olmak gerekirse bu sorunların yaklaşık yarısını hiç yaşamadım
    “network yavaş render ediliyor, çok daha az ayrıntı gösteriyor ve mobilde neredeyse hiç çalışmıyor” kısmı da öyle; ekibimizin branch durumunu kontrol etme aracı olarak mobil cihazları dikkate almamız gereken günün hiç gelmemesini umuyorum
    Böyle bir kullanım senaryosu aklıma bile gelmemişti
    Bu başkalarının sık yaşadığı bir şey mi?

    • Sürekli oluyor
      Kod gezintisinin en az %50’sini telefondan yapıyor gibiyim
      Bunun için mobil GitHub web arayüzünü çok kullanıyorum ve referans bulma desteği gerçekten büyük yardımcı oldu
      Arama hâlâ pek iyi değil ve SPA’ye özgü takılmalar yüzünden sayfa içi temel bulma özelliğinin sürekli bozulmasından nefret ediyorum
      Firefox kodunu kurcalamam gerektiğinde Searchfox [0] kullanıyorum; hızlı ve harika, neredeyse hiç şikâyetim yok
      Yine de mobilde blame daha iyi olabilir
      Bağlam vermek gerekirse, yüksek lisans öğrencisiyim; programlama dilleri ve sistemler araştırması yapıyorum, boş zamanlarımda da epey IoT hack’liyorum
      Nesil sınırını nereye koyduğunuza bağlı olarak ya yaşlı bir Gen Z’yim ya da mümkün olan en genç Millennial
      [0] https://searchfox.org
    • İşe gidip gelirken trende projeleri kontrol edip çalışma saatlerimi uzatmaya çalıştığım oldu
      Veri kapsamasının kararsız olması dışında GitHub iyi çalışıyordu ve hafif kod incelemeleri yapmak da kolaydı
      GitHub pulse[1], son etkinlikleri görmek için iyi bir UI
      SQLite mirror’ı GitHub’da geliştirilmediği için yalnızca commit geçmişi var ve bu sayfa boş, ama bağlantısı verilen Caddy projesi daha iyi bir örnek
      Bana kişisel olarak timeline’dan daha kullanışlı görünüyor
      git/GitHub için buna denk bir görünümü birilerinin yapıp yapmadığını merak ediyorum
      Çok zor görünmüyor
      [1] https://github.com/caddyserver/caddy/pulse
    • Blogumu yönetmek için git kullanıyorum
      GitHub’da düzenleme yapabilmek için bir Android editörü yaptım, sonra onu GitLab’de de çalışacak şekilde uyarladım
      Sebebi çok ama büyük ölçüde bunun nedeni, git’in ister GitHub’da ister GitLab’de olsun mobilde kullanmanın neredeyse imkânsız olması
      Durumu kontrol edebiliyorsunuz ama onun ötesi neredeyse çok zor
      Bu yazı başka açılardan da bana çok dokundu
      GitHub hakkında bir O’Reilly kitabı yazmış olmama rağmen, 10 yılı aşkın süredir git kullanıyor olsam da hâlâ onu tam olarak anladığımı söyleyemem
      Buradaki eleştirilere katılıyorum
    • O özelliğin mobilde çalışmaması için bir neden yok
      Daha iyi tasarlanıp uygulanmış olsaydı elbette mobilde de çalışırdı
      İnsanlar diğer platformlarda GitHub’a erişmelerine neden olan aynı sebeplerle mobilde de GitHub’a sık sık erişiyor
      Ben de kesinlikle yaptım
      git hakkındaki bu tür gözlemler ille de birer “sorun” değil, daha çok özelliklerle ilgili değer yargıları
      Katılabilirsiniz ya da katılmayabilirsiniz; bunlar mutlaka herkesin yaşaması gereken türden şeyler değil
    • En iyi çözüm olmasa da seçenek olarak açık bırakıldığında değerli olan pek çok yaklaşım var ve böyle seçeneklerin mümkün olduğunca iyi çalışması, hiç seçenek olmamasından daha iyidir
      Bu, kademeli bozulma ile anında başarısızlık arasındaki fark gibi
      Ne kadar iyi olursa olsun, kusursuz ve lüks bir seçenek tek seçenekse kırılgandır; bu yüzden de çöptür

  • Birkaç gün önce Git alternatiflerini anlatan bir video izledim ve elbette Fossil de onlardan biriydi
    Bazı projelerde Fossil kullandım ve fena değildi
    Bu sunumda anlatılan Pijul https://pijul.org/ çok ilginçti; daha önce HN’de de tartışılmıştı
    Kaynak: https://www.youtube.com/watch?v=M4KktA_jbOE

    • Hâlâ anlamaya çalışıyorum ama jj de ilginç görünüyor: https://github.com/martinvonz/jj
    • Pijul bana hep büyüleyici gelmiştir
      Sürüm kontrolünün kutsal kâsesi gibi hissettiriyor
      Ama kişisel projelerde zaten doğrusal geliştiriyorum, işte ne kullanıldığına da benim sözüm geçmediği için pratikte hiç kullanmadım
    • Pijul’un, belirli bir hizmet hesabı oluşturmak istemeyen insanların da upstream’e yama gönderebilmesi için genel bir geri dönüş seçeneği olarak e-posta ile yama gönderimini desteklediğinde hazır sayılabileceğini düşünüyorum

  • Kişisel yerel projede Fossil kullandım
    Oldukça yetenekli bir sürüm kontrol sistemi ve web arayüzü de epey iyi
    Yalnız dikkat edilmesi gereken nokta, temelindeki SQLite depo veritabanını sık sık yedeklemek
    Fossil’i yükseltip birkaç commit attıktan sonra yanlışlıkla daha eski bir Fossil sürümüyle commit yapınca Fossil depo veritabanı geri döndürülemez biçimde bozuldu ve birkaç günlük çalışmamı kaybettim
    Git ise 10 yıl boyunca her gün kullanmama rağmen, sürümden bağımsız olarak depoyu bir kez bile bozmadı

    • Karşı örnek olarak, ben Fossil’i tamamen ölçüsüz biçimde kullandım
      Farklı sistemlerde yıllarca aralıklı sürümler rastgele bulunuyor ve sistemi kurarken hangi ikili dosya varsa onu kullanmaya devam ediyorum
      macOS da var, çeşitli Linux türevleri de var, FreeBSD kutuları da var; daha da geriye gidersek sanırım Windows da vardı
      Bunlar arasında doğaçlama yöntemlerle senkronizasyon yapıyorum
      Bazı depolar 10 yılı geçti, birinde 10 binden fazla commit var, bir diğeri ise tüm geliştirme ortamı check-in edildiği için birkaç GB boyutunda
      Arada bir yeniden derleme gerektiğini söyledi ve her seferinde başarılı oldu
      Commit sırasında yazım hatası fark edersem alışkanlık olarak ctrl-c ile iptal de ediyorum
      Buna rağmen beni bir kez bile yarı yolda bırakmadı
      Fossil, kullandığım programlar arasında açık ara en güvenilir program
    • Bu iddiaya katılmak zor
      Fossil’in temel artifact biçimi en baştan bugüne uyumlu kaldı
      İyileştirmeler oldu ama kırıcı değişiklikler olmadı ve çok sayıdaki Fossil Forum kullanıcısı arasında da böyle bir bozulma bildirimi çıkmadı
      Tahminimce, daha yeni bir Fossil ile gelişmiş bir özelliği kullanarak bir şeyi check-in ettiniz ve sonra bu yeni özelliği anlamayan eski bir Fossil ile çıkarmaya çalışınca hata aldınız
      Örneğin Fossil başlangıçta yalnızca SHA1 hash kullanıyordu, ama SHAttered saldırısından sonra hem SHA1 hem SHA3 destekleyecek şekilde geliştirildi
      Elbette bu bir tahmin ama en makul açıklama bu görünüyor
      SQLite deposu, Fossil’in kendi kendini barındırdığı depo ve elimdeki 100’den fazla Fossil deposu için tek bir saf yedek bile hiç oluşturmadım
      Felaket kurtarma amacıyla başka makinelerde klonlar tutuyorum
      Hatta dünyanın farklı yerlerindeki makinelerde çalışan cron işleri, SQLite gibi önemli Fossil depolarını her saat sync edecek şekilde dönüyor
      Ama saf yedek hiç almadım
      Birkaç yıl önce varsayılan SQLite depom bir kez bozuldu
      Bir şekilde dosya tanımlayıcısı 2 kapanmıştı ve depo olan SQLite veritabanı açılırken dosya tanımlayıcısı 2 olarak açıldı
      Sonrasında Fossil’deki bir bug yüzünden assert() oluştu ve dosya tanımlayıcısı 2’ye yazarken veritabanının bir kısmının üstüne yazdı
      Depoyu klondan kurtardım, Fossil’deki assertion kusurunu düzelttim ve SQLite’ın 3’ten küçük dosya tanımlayıcılarını kullanmaması için sertleştirme yaptım
      Birlikte bakılabilecek kaynak: https://fossil-scm.org/home/doc/trunk/www/selfcheck.wiki
    • Bu bilinen bir davranış mı?
      SQLite geliştiricilerinin güvenilirlik yaklaşımını düşününce, düzeltilmesi gereken ciddi bir bug gibi görünüyor
    • Git depolarım bozulduğu oldu
      Ama genelde geri döndürülemez olmuyordu

  • Vay canına, bu konuya bayağı daldım
    Uzun zamandır gördüklerim arasında muhtemelen en iyisiydi
    Görünüşe göre Fossil kullanırken Git/GitHub’a da mirror yapmak mümkün: https://fossil-scm.org/home/doc/trunk/www/inout.wiki
    Yerleşik arayüz iyi görünüyor, gerçekten kullanılabilir ve gezinmesi kolay
    Yalnız arayüzden commit desteği de olmasını isterdim ama bulamadım
    Böylece işi tamamlamak için komut satırı ile web arayüzünü karıştırmak gerekmezdi
    Fossil’in üstüne open, init, commit, sync, sync-with-git, start-web-interface destekleyen bir wrapper arayüz yapılabilirse, ya da doğrudan Fossil’in içine eklenebilirse, daha az teknik olan ya da geliştirici olmayıp yine de kodla uğraşan kişiler için — örneğin biyoloji, matematik, veri bilimi alanlarında Jupyter notebook yönetenler için — oldukça faydalı olabilir
    Elbette basit bir git arayüz istemcisi de bu amaçla kullanılabilir, ama o zaman yerleşik wiki ve ticket özellikleri kaybolur
    Yerelde çalışabilme yeteneği de faydalı, ama git de bunu yapabiliyor
    Her hâlükârda, daha az teknik kişilerin git’ten ya da genel olarak sürüm kontrolden çekindiğini gördüm
    Aynı depoda yerleşik wiki ve ticket bulunmasının bir potansiyeli var
    Yedeklenecek dosyanın tek bir dosya olması da ilginç

  • Yazılım geliştiriciler için sürüm kontrol sistemi, IDE ya da temel işletim sistemi gibi bir araçtır
    Bu tür araçlarla ne kadar az uğraşırsanız o kadar üretken olursunuz
    Birçok sürüm kontrol sistemi kullanmış biri olarak Fossil, benim için tam doğru sweet spot’a oturuyor
    Gerçekten kurup unutabiliyorsunuz