git-annex - Git kullanıcıları için büyük dosya yönetim aracı

• git-annex, büyük dosyaların içeriğini doğrudan Git deposuna koymadan yönetmeyi sağlayan bir araçtır
• Çevrimdışı ve çevrimiçi ortamlarda senkronizasyon, yedekleme ve arşivleme yapar; sağlama toplamları ve şifreleme ile güvenliği sağlar
• Git'in dağıtık yapısını büyük dosyalara uygulayarak birden çok sürücü, sunucu ve bulut arasında konum takibini ve aktarımı basitleştirir
• CLI odaklı kullanıcılar için uygundur; genel kullanıcılar için sunulan git-annex assistant, klasör senkronizasyonuna benzer bir kullanım deneyimi sağlar
• Uzun süreli saklama için basit depo biçimi ve çeşitli special remotes ile arşivleme ve taşıma iş akışlarını genişleten bir araçtır

---

Genel bakış

• git-annex, dosyaların içeriğini Git dışında tutup yalnızca meta veri ve konum bilgisini Git ile yöneten bir büyük dosya yönetim aracıdır
  • Sonuç olarak commit geçmişi hafif kalırken büyük ikili dosyaların saklanması ve taşınması esnek biçimde yönetilir
  • Sağlama toplamları ve şifreleme desteği ile bütünlük ve gizlilik sağlanır
• Hem çevrimdışı hem çevrimiçi olarak senkronizasyon, yedekleme ve arşivleme yapar; dağıtık depolar arasında aynı dosyanın kopya sayısını yönetme ve günlük kaydı tutma işlevleri sunar
• Komut satırı kullanıcıları için optimize edilmiştir; ancak git-annex assistant sayesinde genel kullanıcılar da klasör senkronizasyonu biçiminde kolayca kullanabilir
• İlk kez kullanacaklar için kurulum ve temel akışı hızlıca öğrenmeye yardımcı olan walkthrough belgesi sunulur

Kullanım örneği: Archivist (arşiv odaklı kullanıcı)

• Birden fazla çevrimdışı arşiv sürücüsü kullanırken bile tüm dosyaları tek bir dizin ağacında sanki tek bir bütünmüş gibi gezebilir ve yeniden düzenleyebilir
  • Dosya içeriği çevrimdışı sürücülerde olsa bile dizin ve işaretçiler sayesinde gerçek silme riski olmadan yeniden yerleştirme ve commit işlemleri yapılabilir
• Belirli bir dosyaya ihtiyaç duyulduğunda bunun hangi sürücüde bulunduğunu gösterir ve kolayca erişilebilir duruma getirilmesini sağlar
  • Her sürücü karşılıklı konum bilgisini paylaşarak genel arşiv durumunun anlaşılmasına yardımcı olur
• Basit bir depo biçimi kullandığı için, git-annex ve git kullanılmasa bile uzun vadede dosya erişilebilirliği korunur
• cron işleri ile geceleri yeni dosyalar otomatik olarak arşivlenebilir; kasıtlı ve kasıtsız kopyalar kaydedilerek ne zaman çoğaltma gerektiğini belirlemek için dayanak sağlanır

Kullanım örneği: Nomad (hareket odaklı kullanıcı)

• Dizüstü bilgisayar, taşınabilir USB sürücüler/bellekler, uzak sunucular ve şifreli bulut depolama gibi heterojen depoları Git remote'ları gibi tutarlı biçimde yönetir
  • Hareket halindeyken sunucuda indirme kuyruğu oluşturup, bağlantı kalitesinin daha iyi olduğu yerde gerçek aktarımı yapan gecikmeli aktarım akışını destekler
• Pil tasarrufu gibi nedenlerle USB'den anlık kopyalama yapıp yerelde tüketme gibi çevrimdışı dostu iş akışları kurulabilir
• Kullanım bittikten sonra tutulacak veya silinecek içerik belirtildiğinde yerel alan geri kazanılır ve bir sonraki senkronizasyonda değişiklikler sunucuyla eşitlenir
• special remotes ve aktarım pipeline'ları sayesinde çeşitli depolama arka uçlarında ve ağ koşullarında esnek veri taşınabilirliği sağlanır

Temel özellikler ve faydalar

• İçerik adresleme ve sağlama toplamları temelli bütünlük güvencesi ile şifreli depolama desteği sayesinde güvenli uzun süreli saklama sağlar
• Konum takibi (location tracking) ile her dosyanın saklandığı yer, kopya sayısı ve erişilebilirliği açıkça görülebilir
• Dağıtık sürüm kontrolü modelini büyük dosyalara uygulayarak merkezi depolamaya bağımlılığı azaltır ve çevrimdışı dayanıklılık kazandırır
• assistant modu ile klasör senkronizasyonu deneyimi sunar; böylece CLI'ye aşina olmayanlar da sürükle-bırak düzeyinde kullanım kolaylığı elde eder

Avantajların özeti

• git-annex, yalnızca dosya referanslarını git ile yönettiği için büyük dosyalarla zorlanmadan çalışmaya uygundur
• Dağıtık yapı sayesinde birden fazla cihaz ve konum arasında serbest dosya taşıma, saklama, senkronizasyon-yedekleme ve sürüm yönetimi mümkündür
• Çevrimdışı ve uzun süreli saklama senaryolarında ya da birden fazla cihaz ve bulut arasında akışkan veri yönetiminde özellikle güçlü bir bütünleşme ve ölçeklenebilirlik sunar
• Hem arşiv odaklı hem hareket odaklı karma kullanıcılar için uygundur; kopya ilkesi yönetimi ve arka uç çeşitliliği ile hem kurumlar hem bireyler için faydalıdır
• Git'in dağıtıklığını ve taşınabilirliğini büyük veriye genişleterek uzun süreli saklama ve taşıma işlerinin operasyonel riskini ve emeğini azaltan bir araçtır

[GN⁺]

Hacker News görüşleri

• Ben tüm sürücülerimdeki verileri yönetmek için git-annex kullanıyorum. Her dosyanın hangi sürücüde olduğunu otomatik olarak izliyor, yeterli sayıda kopya tutulmasını sağlıyor ve tüm dosyalar için sağlama toplamlarını doğruluyor. Çevrimdışı sürücülerle de sorunsuz çalışıyor. git-annex başta anlaması biraz zor gelebilir; bu yüzden geçici bir depo oluşturup walkthrough'u takip ederek pratik yapmanızı öneririm. Ayrıca çeşitli workflow'lara da bakmaya değer

  • Ne kadar veri tuttuğunuzu merak ediyorum. Ben yaklaşık 100 bin ila 1 milyon dosyayı, birkaç TB fotoğraf verisini ZFS üzerinde git-annex ile yönetiyorum. Başta hiçbir sorun yoktu ama son zamanlarda giderek yavaşladı; her komut 5 ila 30 dakika sürüyor. Bunun ZFS'den mi, git-annex'ten mi yoksa diskten mi kaynaklandığını anlamakta zorlanıyorum

  • Uzun zamandır verilerimi git-annex ile yönetmeyi düşünüyordum ama dosyaları tamamen silerken sürtünme yaşadım ve birkaç sorunla karşılaştım. Vaktiniz olursa nasıl kullandığınızı paylaşabilir misiniz diye merak ediyorum

• Sayfada görünmüyor ama git-annex'i Joey Hess yaptı. Kendisi moreutils ve etckeeper'ı da geliştirdi

  • Bence daha da bilinen gerçek, 1996'dan beri onlarca yıldır Debian'ın çekirdek katkıcılarından biri olması. Bugün Linux diye düşündüğümüz şeyin büyük bir kısmı onun elinden çıktı

• Git'in yeni yerel büyük nesne yönetimi özelliklerine dair yakın zamanda bir tartışma burada vardı

  • Ek olarak, neden tartışmanın çok ilgili olmadığını düşündüğümü yorumda da açıkladım. annex aslında "git içinde büyük dosyalar" probleminden biraz farklı bir alanda. git-annex'i, LFS ve benzerlerinde "sunucu tarafı" depolama sorununu Git'in yerel yöntemiyle dağıtık biçimde ele almak olarak görmek daha kolay olabilir

• git-annex ile ilgili can sıkıcı nokta Haskell olması. Dili sevmediğimden değil ama kurulması gereken bağımlılık sayısı gerçekten şaşırtıcıydı. Bunların önemli bir kısmı başka hiçbir yerde gerekmiyor ve birçok uygulamada sürüm çakışmaları da çıkarıyor. Özellikle sistem paket yöneticisiyle kurunca zorlaşıyor. Sadece annex ve pandoc kursanız bile her gün onlarca Haskell paketi güncellemesi geliyor. Kaynaktan derlenen bir dağıtım kullanıyorsanız tam bir kâbus. Aslında çoğunun statik bağlanmasında sakınca olmadığını düşünüyorum. Buna rağmen Haskell çevresinde bunun ince taneli kütüphane modülerliğinin sonucu olduğu söyleniyor. Ama sistem yönetimi gibi başka öncelikler de var; Rust, Go, Zig, C ve C++'ta böyle bir sorun yaşamadım. Haskell ekosistemine ve kullanıcılarına düşman değilim, ben de öğrenmeyi düşünüyorum. Ama bu sorunun neden var olduğunu ve çözümünün ne olduğunu merak ediyorum

  • Haskell araçlarında statik bağlama zaten destekleniyor. Ben Solus için Haskell yığınını yönetiyorum; pandoc yalnızca libc'ye bağımlı ve tüm Haskell paketleri Rust'taki gibi ikili dosyanın içine statik olarak gömülüp dağıtılıyor. Yani bu gayet yapılabilir. Solus'ta bağımlılık sayısı çok fazla olduğu için doğrudan statik bağlama kullanıyoruz. Bence bu dağıtım bakımcısının kararıyla ilgili

  • “Çoğunu statik bağlamakta sakınca yok” kısmı için, dağıtım deposu söz konusuysa bunun nihayetinde paket yöneticisi politikasıyla ilgili bir mesele olup olmadığını merak ediyorum

  • Tam zamanlı bir Haskell geliştiricisi olarak ben de statik bağlanmamış Haskell paketlerine benzer bir isteksizlik duyuyorum. AUR'da zaten statik bağlanmış sürümler var, yani en azından imkânsız değil. Paketleyicilerin neden özellikle dinamik bağlamada ısrar ettiğini ben de hiç derinlemesine araştırmadım. Genelde dinamik bağlama kurum içi yazılım dağıtımı için mantıklı olabilir ama sanırım bunu gereksiz biçimde dağıtımlara da yansıtıyorlar

  • Hangi paket yöneticisini kullandığınızı merak ediyorum. apt tabanlı sistemlerde Haskell yüzünden hiç sorun yaşamadım

  • Her pacman -Syu çalıştırdığımda güncellemelerin yarısının Haskell paketleri olması can sıkıyor. Muhtemelen sebep pandoc ya da shellcheck

• git-annex gerçekten çok havalı bir teknoloji. Ama bende bıraktığı izlenim, en iyi tek kullanıcılı depolarda çalıştığı yönünde. Örneğin bir kişinin dosyalarını, belgelerini, müziklerini ve kişisel verilerini farklı cihazlar arasında yönetmesi için çok uygun. Büyük dosyalarla çalışan işbirlikçi depolarda senkronizasyon için kullanmayı denedim ama "magic" branch yaklaşımı iyi ölçeklenmiyor

  • Kullanıma göre değişebilir ama bizim kurumda tam tersine iyi çalışıyor. Biz bir dijital arşiv kurumuyuz ve 10 yılı aşkın süredir dahili depolarımızın arka ucunda git-annex kullanıyoruz. 15 ila 20 çalışanımız var ama 30 TB'tan fazla veriyle, 750 bin dosyayla (ikili+meta veri) ve yüzlerce depoyla sorunsuz çalışıyoruz

• Ben self-hosted Forgejo kullanıyorum. Şu ana kadar git-annex'in LFS'ten açıkça üstün olduğu bir yön göremedim ve kurulumu da kolay görünmüyor. git-annex'in Haskell ile yazılmış olması da hoşuma gitmiyor ve yaklaşık %50 daha yavaş olduğuna dair şeyler de gördüm; gerçi tek bir kaynaktı, o yüzden güvenilir olup olmadığını bilmiyorum. Komutların karmaşık olmasının bir nedeni olabilir ama LFS'teki gibi yalnızca .gitattributes'a bakarak neredeyse her şeyi anlayabildiğiniz bir rahatlık yok. git-annex'te de .gitattributes benzeri bir şeffaflık hissi almadım. Bir de 'git lfs ls-files' karşılığı bir komutu gösteren bir eğitim bile yoksa pek ilgimi çekmiyor. Ben 'git status' ve 'git lfs ls-files' ile kontrol etmeye alışkınım

  • Yavaşlığın nedeni Haskell değil. git-annex dağıtık bir yedekleme aracı ve yavaşlığın nedeni I/O ile veri korumaya aşırı önem veren davranışı. Örneğin drop komutu kullanıldığında, ilgili içeriğin tüm remote'larda gerçekten mevcut olup olmadığını gerçek zamanlı kontrol etmesi gerekiyor; bu da yavaşlatıyor. --fast gibi seçeneklerle yalnızca yerel meta veriye güvenip doğrulamayı atlayabilirsiniz; bu çok daha hızlı olur ama biraz risklidir

  • LFS ile git-annex'in kullanım alanları hafifçe farklı. LFS, git deposuna büyük dosyaların karıştığı geliştirme örnekleri için, mesela oyun geliştirmede daha uygun. git-annex ise önemli verileri yedeklemek, örneğin müzik klasörü gibi büyük dosya koleksiyonlarını birden fazla yerde tutmak istediğinizde daha uygun. Ben ikinci şekilde kullanıyorum

  • git-annex destekleyen bir Forgejo soft-fork'u var: forgejo-aneksajo

  • git-annex ile yönettiğim en büyük depo, birden fazla sisteme dağılmış birkaç TB büyüklüğünde; içinde 10 GB'tan büyük birçok dosya da var. Yazarın aradığı şey git-lfs-ls-files ise, git-annex tarafında git annex list --in here muhtemelen benzer bir iş görüyor

• Komut satırı belgelerinde gerçek kullanım örneklerinin en başta gelmesi takdire değer. Pek çok araç genelde neredeyse hiç kullanılmayan kafa karıştırıcı seçenek açıklamalarıyla başlıyor; bu da hep hayal kırıklığı yaratıyordu

• GitHub, LFS için Microsoft tarzı bir NIH (Not Invented Here) yaklaşımı benimsediği için git-annex'i benimsemedi

  • Ben de git-annex'in daha zarif olduğunu düşünüyorum ama çapraz platform uyumluluğu zayıf. Ayrıca LFS, GitHub ve Bitbucket'ın (tam olarak hangi forge olduğunu hatırlamıyorum) işbirliğiyle ortaya çıktı. Bir taraf uygulamayı, diğer taraf adı sağladı; sonra bir Git konferansında buluşup birleştirdiler. Bugün en üzücü taraf, GitHub'ın büyük projelere uyguladığı üst sınırlar. Bir de "push yapabilmek için tüm nesneleri yerelde bulundurmalısınız" politikası yüzünden, büyük geliştirici toplulukları hızla bu sınıra çarpıyor. Not: git-lfs'e katkıda bulunmuşluğum var

  • (Dürüst olmak gerekirse) GitHub'ın NIH yaklaşımı her açıdan kaybettiriyor. git-annex'i seven bir konuşmacının sunumu var: Staying in Control of your Scientific Data with Git Annex by Yann Büchau

• İronik biçimde, geçen hafta sonu bir günümü kendi büyük dosya sürümleme sistemimi yapmaya ayırdım. git-annex'ten o kadar nefret ediyorum. Dosyaları blob'a çevirip dosya sistemini şişiriyor. Benim asıl amacım dağıtık dosyalar arasında senkronizasyon; sürümlemeyle pek ilgilenmiyorum zaten. Büyük dosyalar için neden sürümleme gerektiğini de pek anlamıyorum. Python'u yapay zeka yardımıyla kullanınca dosyaları hash'leyip bir arama tablosu oluşturmak, kaynakları rclone ile senkronize eden yardımcı yöntemler yazmak mümkün. Çok daha basit ve verimli yollar var

• Bunu yıllarca kullandım; en büyük avantajı bulut depolama sağlayıcıları ve yedeklemeyle entegrasyonuydu. Ama bu entegrasyon hep kırılgandı ve bakımsız üçüncü taraf eklentilere dayanıyordu. Bir ara veri tutarsızlığına yol açan bir hata bile vardı, sonunda vazgeçtim. Son 5 yılda bu konuda iyileşme olup olmadığını merak ediyorum

  • Bunun biraz kullandığınız bulut depolama sağlayıcısının türüne bağlı olduğunu düşünüyorum. S3, WebDAV, SFTP gibi resmî standart protokolleri destekleyenler avantajlı. Son dönemde rclone tabanlı special remote doğrudan git-annex'e gömüldü; bu da eski üçüncü taraf remote'lara göre daha iyi bakılıyor ve rclone'un desteklediği neredeyse tüm cloud remote'larla entegrasyon sağlıyor