SQLite Git का उपयोग क्यों नहीं करता
(sqlite.org)- SQLite का source code Git नहीं बल्कि Fossil से प्रबंधित होता है, और Fossil एक version control system है जिसे खास तौर पर SQLite को support करने के लिए डिज़ाइन और लिखा गया था
- Fossil एक ही स्क्रीन पर सभी branches के हालिया बदलाव दिखाने वाली situational awareness सुविधा देता है, और इसे मोबाइल फ़ोन पर भी access किया जा सकता है
- Git check-in की पिछली history ही track करता है और उसके बाद के descendants को ट्रैक करना मुश्किल है, जबकि Fossil बाद के check-ins और branch structure को आसानी से दिखाता है
- Git में working directory, staging, local/remote head आदि 5 states को ध्यान में रखना पड़ता है, जबकि Fossil में केवल working directory और check-in पर ध्यान देना होता है, जिससे 60% कम mental load होता है
- Git से परिचित users भी GitHub mirror, web download, और Fossil install के ज़रिए SQLite source तक उसी तरह पहुँच सकते हैं
अवलोकन और लेख की भूमिका
- SQLite Git की जगह Fossil का उपयोग करता है, और Fossil एक version control system है जिसे SQLite support के उद्देश्य से सीधे बनाया गया था
- यह लेख Fossil और Git की तुलना नहीं है, और न ही Git छोड़ने की सलाह देता है
- अगर आप Git से संतुष्ट हैं, तो उसका उपयोग जारी रखने में कोई समस्या नहीं
- अगर Git आपके workflow के लिए उपयुक्त नहीं है, या आप सुधार/विकल्प पर विचार कर रहे हैं, तो यह कुछ उपयोगी दृष्टिकोण देता है
- स्पष्टता सुधारने और त्रुटियाँ ठीक करने के लिए इस दस्तावेज़ को कई बार संशोधित किया गया है, और पूरी edit history देखी जा सकती है
SQLite Git का उपयोग क्यों नहीं करता
Git अच्छी situational awareness नहीं देता
- Fossil की timeline एक ही स्क्रीन पर सभी branches के हालिया बदलावों का सारांश देती है, कुछ clicks में details तक पहुँचा जा सकता है, और यह मोबाइल फ़ोन पर भी usable है
- GitHub·GitLab में इसके बराबर की सुविधा नहीं है
- network view render होने में धीमा है (cache से पहले), details कम दिखाता है, और मोबाइल पर लगभग काम नहीं करता
- commits view तेज़ है और मोबाइल पर चलता है, लेकिन एक बार में सिर्फ़ एक branch दिखाता है, इसलिए यह जानना कठिन होता है कि क्या आपने सभी बदलाव देख लिए हैं
- GitHub·GitLab, Git के core components नहीं बल्कि third-party services हैं, इसलिए वे अतिरिक्त dependency पैदा करते हैं
- Git users अक्सर third-party graphical viewers install करते हैं, लेकिन इनके लिए अलग installation/maintenance चाहिए और ये platform-dependent होते हैं
- बेहतर tools में से एक GitUp केवल Mac पर काम करता है
- सभी tools में local repository sync करने के बाद desktop GUI चलाना पड़ता है, इसलिए बाहर रहते हुए फ़ोन से project status देखना संभव नहीं
Git में check-in के descendants ढूँढना मुश्किल है
- Git में अतीत की ओर देखना आसान है, लेकिन आगे बढ़ी हुई history को track करना कठिन है
- किसी पुराने check-in के लिए पहले क्या था यह दिखता है, लेकिन उसके बाद क्या आया यह देखना कठिन होता है
- Fossil ऐसी screen देता है जो latest major release से निकले सभी check-ins दिखाती है
- Git में descendants ढूँढना असंभव नहीं है, लेकिन कठिन है
- stackoverflow पर unix के लिए command sequence मौजूद है, लेकिन वह command branch structure के बिना केवल descendants की list देती है
- वह command तभी काम करती है जब आपके पास local clone हो; GitHub·GitLab जैसे web interface में descendants नहीं देखे जा सकते
- Fossil में descendant information पूरे web interface में दिखाई देती है
- हर check-in information page पर पिछले और अगले check-in को दिखाने वाला छोटा "Context" graph होता है
- अगले check-in पर click करके जाना जैसी सुविधाएँ situational awareness बेहतर बनाती हैं
- Git में भी सही extensions, tools, और commands के साथ सिद्धांततः यह संभव है, लेकिन यह आसान नहीं है और लगभग कभी किया नहीं जाता; नतीजतन developers की code changes के प्रति जागरूकता कम हो जाती है
Git का mental model अनावश्यक रूप से जटिल है
- Git users को हमेशा इन 5 चीज़ों को ध्यान में रखना पड़ता है
- working directory
- "index" या staging area
- local head
- remote head की local copy
- वास्तविक remote head
- Fossil users को केवल working directory और जिस check-in पर वे काम कर रहे हैं उसी पर ध्यान देना होता है, यानी 60% कम ध्यान बँटता है
- इससे developers की सीमित एकाग्रता बचती है और वे version control system की बजाय उस software पर ध्यान दे पाते हैं जिसे वे बना रहे हैं
- Git और Fossil दोनों इस्तेमाल करने वाले एक user ने HN पर कहा कि "Fossil एक ही command से यह भरोसा देता है कि सब कुछ server पर sync हो गया है, जबकि git में ऐसा भरोसा नहीं मिलता"
Git पुराने branch names को track नहीं करता
- Git पूरे DAG of check-ins को बनाए रखता है, लेकिन branch tags local information होते हैं, sync नहीं होते, और branch बंद होने पर बने नहीं रहते; इसलिए पुराने branches की समीक्षा करना असुविधाजनक हो जाता है
- उदाहरण: अगर पूछा जाए कि 2 साल पहले की 'prefer-coroutine-sort-subquery' branch का क्या हुआ
- Fossil: साफ़ दिखाता है कि वह branch अंततः trunk में merge हुई, कहाँ से शुरू हुई, और trunk के बदलाव दो बार branch में merge हुए
- GitHub: यह जानकारी बिल्कुल नहीं दिखा पाता, इसलिए क्या हुआ यह समझने में लगभग बेकार है
- third-party GUI शायद बेहतर हो, लेकिन Git sync के दौरान पुराने branch names को preserve नहीं करता, इस सीमा से वे भी बँधे रहते हैं
- मनचाही जानकारी के लिए third-party tool की ज़रूरत पड़ना ही core system की कमज़ोरी है
Git को अधिक प्रशासनिक समर्थन चाहिए
- Git एक जटिल software है; workstation पर install/upgrade के लिए installer चाहिए और Git server बनाना भी आसान नहीं है
- ज़्यादातर लोग GitHub·GitLab जैसी third-party services का उपयोग करते हैं, जिससे अतिरिक्त dependency बनती है
- Fossil एक single standalone binary है जिसे $PATH में रख दें तो installation पूरी हो जाती है
- यही एक binary core Git और GitHub·GitLab जैसी सुविधाओं को साथ में समाहित करती है
- wiki, bug tracking, forum सहित community server management, package downloads, login management आदि बिना अतिरिक्त software के कर सकती है
- community server कुछ ही मिनटों में तैयार किया जा सकता है
- यह $5/माह VPS या Raspberry Pi पर भी आराम से चलता है, जबकि GitLab आदि को अधिक resources चाहिए
- प्रशासनिक बोझ जितना कम होगा, developers version control system की बजाय software (SQLite) पर उतना अधिक समय दे पाएँगे
Git अच्छा user experience नहीं देता
- xkcd 1597 comic अतिशयोक्ति है, लेकिन वास्तविकता के काफ़ी करीब है
- Git second-rate user experience देता है, इस पर बहुत कम असहमति है, और इसकी internal implementation interface में साफ़ दिखाई देती है
- interface इतना खराब है कि नकली git man pages बनाने वाली parody site तक मौजूद है
- एक अच्छा version control system निराशा नहीं बल्कि सहायता दे; Git पिछले 10 वर्षों में बेहतर हुआ है, लेकिन अभी भी लंबा रास्ता बाकी है
Git users के लिए SQLite source code access guide
आधिकारिक GitHub mirror
- 2019-03-20 से GitHub पर SQLite source का official Git mirror मौजूद है
- यह आधिकारिक Fossil repository के incremental export से बनता है, और cron job हर घंटे GitHub repository को update करती है
- यह one-way, read-only mirror है; pull request या changes स्वीकार नहीं किए जाते
- सभी बदलाव केवल Fossil के माध्यम से ही स्वीकार किए जाते हैं
- check-in और file identifier hashes Git mirror और Fossil में अलग होते हैं
- मुख्य कारण यह है कि Fossil SHA3-256 और Git SHA1 hash का उपयोग करते हैं
- export के समय मूल Fossil hash को check-in comment footer में जोड़ा जाता है, और SQLite check-ins का reference देते समय भ्रम से बचने के लिए हमेशा मूल Fossil hash का उपयोग करने की सलाह दी जाती है
web access
- SQLite Fossil repository किसी भी पुराने version के लिए Tarball, ZIP Archive, और SQLite Archive download links देती है
- URL format सरल है, इसलिए automation tools में इसे आसानी से जोड़ा जा सकता है
- मूल format:
https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz - VERSION में hash prefix, branch name, या tag (जैसे "version-3.23.1") उपयोग किया जा सकता है
- latest release के लिए "release" और latest trunk के लिए "trunk" उपयोग करें
- ZIP·SQLite Archive के लिए "/tarball/" को "/zip/" या "/sqlar/" से बदलें
- मूल format:
Fossil access
- Fossil को install और उपयोग करना आसान है, और unix के लिए प्रक्रिया दी गई है (Windows पर भी लगभग समान)
- fossil executable download करें और उसे $PATH में रखें
fossil cloneसे repository clone करें औरfossil openसे उसे खोलें- उसके बाद
./configure; make(Windows MSVC मेंnmake /f Makefile.msc) चलाया जा सकता है
fossil update VERSIONcommand से दूसरे version पर checkout बदला जा सकता है (VERSION में trunk, hash prefix, branch, या tag इस्तेमाल करें)- checkout के भीतर
fossil uicommand से local website चलाई जा सकती है- login के बिना changes push नहीं किए जा सकते, इसलिए project को नुकसान पहुँचाए बिना स्वतंत्र रूप से explore और experiment किया जा सकता है
source code integrity verification
- source tree root में "manifest" file मौजूद होती है
- इस file में सभी file names और हर file का SHA1 या SHA3-256 hash होता है (पुरानी files के लिए SHA1, नई files के लिए SHA3-256)
- script के जरिए hashes निकालकर source files से मिलान करके verification किया जा सकता है
- check-in का hash name, "manifest" file के अपने SHA3-256 hash के बराबर होता है, और यदि आख़िरी line "# Remove this line..." से शुरू होती है, तो उस line को नज़रअंदाज़ किया जा सकता है
1 टिप्पणियां
Hacker News की राय
मैंने दशकों में इस्तेमाल किए गए version control tools और उनके बने/आखिरी बार इस्तेमाल किए गए सालों की सूची बनाई: sccs 1973~2000, rcs 1982~2000, cvs 1990~2004, clearcase 1992~2004, perforce 1995~2011, subversion 2000~2015, mercurial 2005~2015, git 2005~वर्तमान
कम-से-कम मेरे लिए इन tools की उम्र लगभग 15 साल रही है
लेकिन जब मैं जूनियर्स से कहता हूँ, “जब तुम मेरी उम्र के हो जाओगे, git बस एक दूर और अजीब-सी याद रह जाएगा,” तो वे मुझे अजीब नज़रों से देखते हैं
git एक शानदार tool है और इसकी सफलता बनती थी, लेकिन अगर यह समस्या git पर ही खत्म हो जाए, तो वह थोड़ी निराशाजनक बात होगी
Joel on Software पर एक लेख था कि software आम तौर पर version 4 तक आते-आते लगभग पूरा हो जाता है, और उदाहरण office software, खासकर Excel, था
आज भी अगर आप Excel 4 चलाएँ, तो उसकी core functionality मूल रूप से सब कर लेती है—इस मायने में बात सही लगती है
git शायद पिछले version control tools की तुलना में कम-से-कम दोगुना ज़्यादा टिकेगा
समस्या यह थी कि CVS distributed development model तक फैल नहीं सकता था; वह एक dead end था
Git फिर से local RCS model पर लौटा, उसमें atomic commits जोड़े, और इस तरह Subversion वाले local optimum से बाहर निकल आया
rename tracking न होना या linear revision numbers न होना जैसे कुछ विवादास्पद चुनाव थे, लेकिन वे बड़े मुद्दे नहीं बने, और darcs जैसी performance problems के बिना इसने बहुत efficient काम करना संभव किया
1995~2010 के बीच version control को सुधारने की इतनी कोशिशें हुईं कि git का बुनियादी data model, यहाँ तक कि git-lfs जैसे extensions जोड़कर भी, सुधारना बहुत मुश्किल लगता है
नया command-line interface आ सकता है, लेकिन मौजूदा दिग्गज को हटाना लगातार कठिन होता गया है, और overloaded व भ्रमित करने वाले
git checkoutकी जगहgit switchऔरgit restoreइस्तेमाल करने वाला मुझे आसपास कोई नहीं दिखताकंपनी के दूसरे विभागों में थोड़ा-बहुत svn था, बस उतना ही
version control systems इतनी जल्दी नहीं बदलते
distributed version control के आने से पहले इस सूची के tools में वास्तव में काफी समानताएँ थीं, और git शायद काफी लंबे समय तक रहेगा
ऐतिहासिक रूप से कई भाषाएँ प्रभावशाली रही हैं, लेकिन अंग्रेज़ी अंतिम भाषा बन जाएगी; कई scripting languages रही हैं, लेकिन javascript अंतिम भाषा बन जाएगी; कई network protocols रहे हैं, लेकिन TCP/IP अंतिम protocol बन जाएगा
मेरे हिसाब से git भी ऐसा ही है
git को पीछे छोड़ने वाली चीज़ शायद glitch[1] जैसे नए programmers के environment ही हो सकते हैं, जिनमें अपना built-in version control system साथ आता है
[1]: https://medium.com/glitch/reinventing-version-control-with-g...
git की खराब reputation की वजह यह है कि इसे कैसे इस्तेमाल किया जाए, इस पर कोई सहमति नहीं बन पाई है
सिर्फ GitHub PR, branch push, rebase और merge को ही देखें तो ये मूल रूप से एक ही काम को पूरी तरह अलग तरीकों से करने वाले tools हैं
समस्या यह है कि इनमें से कोई भी सचमुच गलत नहीं है
छोटे commits को rebase करने से history की अनावश्यक जटिलता घटती है, और merge वास्तव में क्या हुआ था उसे सुरक्षित रखता है, जिससे बदलाव की वजह समझने में मदद मिलती है
हाँ, reverse merge सबसे बुरा है, लेकिन वह एक अलग सिरदर्द है
branch पर push करते समय आप शायद कभी force push न करें, लेकिन PR branch पर तो लगभग हमेशा force push करना पड़ता है
यहाँ तक कि आसान चीज़ें भी ऐसे मतभेद पैदा कर देती हैं जिन्हें सुलझाना मुश्किल हो जाता है
मैंने main repository को origin और अपनी fork को fork कहना सीखा, लेकिन कुछ लोग main repository को upstream और अपनी fork को origin कहते हैं
दोनों में से कोई भी पूरी तरह गलत नहीं है, लेकिन अगर origin दो बिल्कुल अलग जगहों को दर्शा सकता है, तो साफ़-साफ़ संवाद करना बहुत कठिन हो जाता है
व्यवहार में, मैं PR के अंदर commits को इस आधार पर सक्रिय रूप से rebase करता हूँ कि “review सबसे आसान किससे होगा?”
review खत्म होने के बाद मैं पूछता हूँ, “आगे maintain और समझने के लिए सबसे आसान रूप क्या होगा?” और फिर या तो सब कुछ squash किया जा सकता है, या rollback आसान बनाने के लिए उन्हें स्वतंत्र रूप से deploy किए जा सकने वाले हिस्सों में फिर से व्यवस्थित किया जा सकता है
मुख्य बात यह है कि इन कामों की ज़रूरतें अलग-अलग हो सकती हैं, और अलग समय पर अलग तरीका अपनाना ठीक है
बस इसमें व्यक्ति की judgment ज़्यादा चाहिए होती है, और पूरी बड़ी team को यह सिखाना और लागू करवाना कठिन है
पहला वे चीज़ें हैं जिनका असर दूसरों पर नहीं पड़ता
उदाहरण के लिए, आप remote repository का नाम
originऔरupstreamरखें याforkऔरorigin, आपके teammates को उससे फर्क नहीं पड़तादूसरा वे चीज़ें हैं जिनके लिए दूसरों के साथ समन्वय करना पड़ता है
उदाहरण के लिए, अंतिम git history कैसी दिखेगी, यह ऐसा मुद्दा है
अगर Apple ने git का command-line interface design किया होता, तो user experience के लिहाज़ से वह 10 अरब गुना बेहतर होता, और उसकी ताकत शायद सिर्फ 10% कम होती
यह अच्छा है कि Fossil उनके लिए ठीक बैठता है, लेकिन यह वाक्य खटकता है: “Fossil एक single standalone executable binary है जिसे बस `$PATH`` में डालने से install किया जा सकता है, और उसी एक में core Git functionality के साथ GitHub/GitLab functionality भी शामिल है…”
git में भले कई समस्याएँ हों, लेकिन यह kitchen sink तक सब कुछ बाँधकर ठूँस देने वाला तरीका नहीं है
मुझे “एक काम अच्छे से करो” वाला approach ज़्यादा बेहतर लगता है
उदाहरण के लिए
git instawebचलाने पर यह local CGI server और Perl CGI script उठाकर बहुत साधारण web UI देता है: https://git-scm.com/docs/git-instawebइस मायने में यह Fossil की core functionality से बहुत अलग नहीं है
सिर्फ GitHub इस्तेमाल करने वाले लोगों को शायद Git में मौजूद email client integration फीचर्स के अस्तित्व का भी, और उनके होने की वजह का भी, पता न हो
जैसे
git send-email, जिससे git से सीधे email patch भेजे जा सकते हैं: https://git-scm.com/docs/git-send-emailहर चीज़ composite है, हर चीज़ commands की pipeline है, हर चीज़ कई हिस्सों से बनी है
“जो काम किया जाना है” वह कोई absolute चीज़ नहीं, बल्कि देखने वाले के नज़रिये पर निर्भर है
single responsibility principle वास्तविक दुनिया में ज्यों-का-त्यों लागू नहीं होता, यह बस cohesion और modularity के बीच संतुलन बनाए रखने वाला एक समझौता है
कहाँ काटकर उसे “एक” कहा जाए, यह हम और हमारी ज़रूरतों पर निर्भर करता है
बहुत-से लोगों के लिए GitHub tools उनके workflow में इतने integrated हैं कि Git अपने-आप में बिल्कुल उपयोगी नहीं है
उनके लिए GitHub ही “एक चीज़” है, और SQLite के लिए SQLite की अपनी “एक चीज़” है
जैसा कहा, यह Unix philosophy के “एक काम अच्छे से करो” विचार से टकराता है
मेरे लिए सिस्टम को ऐसे components में बाँटना, जिन्हें बाद में स्वतंत्र रूप से बदला या संशोधित किया जा सके, साफ़ तौर पर ज़्यादा सुथरा है
installer 50MB से बड़ा है और, अगर मुझे सही याद है, उसमें terminal भी शामिल है
वहीं Fossil के लिए हर supported platform पर 3.3MB की standalone binary डाउनलोड की जा सकती है
https://git-man-page-generator.lokaltog.net काफी समय में देखी गई सबसे मज़ेदार चीज़ों में से एक है
git-erase-working-treeका वर्णन है: “जब आप upstream root और configuration के current working tree को सावधानी से मिटाकर active GUI के साथ quiltimport करना चाहें, तब इसका उपयोग करें” — काफ़ी उपयोगी लगता हैgit-molest-headका वर्णन है: “यह remote index का उपयोग करके upstream head को ग़लत तरीके से परेशान करता है, और दिए गए head को table में बदलने के लिए उचित hook चलाता है” — थोड़ा ज़्यादा उकसाने वाला हैGit में इतने अटपटे commands हैं कि अब कुछ भी चौंकाने वाला नहीं लगता
git-tease-chain,git-scrub-dangling-object,git-seize-mailmap,git-dress-graft,git-strangle-tree,git-satisfy-daemon,git-pat-tree-objectबेहतर बकवास के लिए शायद थोड़ा और LLM मसाला चाहिए
पिछली चर्चाएँ:
2021, 356 comments: https://news.ycombinator.com/item?id=29125934
2018, 608 comments: https://news.ycombinator.com/item?id=16806114
और भी होंगी, लेकिन वही दस्तावेज़
wwwdomain के बिना,/drafts/path के बिना, और/matrix/path के बिना भी कई रास्तों से मिल जाता है, इसलिए पिछली posts ढूँढना और मुश्किल हो जाता हैइसमें Git की कुछ जायज़ आलोचनाएँ हैं, लेकिन कुछ बातें थोड़ी अजीब भी लगती हैं
मैंने local personal repos से लेकर बहुत बड़े company repos तक अलग-अलग स्थितियों में Git इस्तेमाल किया है, और ईमानदारी से कहूँ तो इनमें से लगभग आधी समस्याएँ मैंने कभी झेली ही नहीं
“network रेंडर होने में धीमा है, detail बहुत कम देता है, और mobile पर लगभग काम ही नहीं करता” वाली बात भी वैसी ही है, और मैं उम्मीद करता हूँ कि वह दिन कभी न आए जब हमारी team को branch की स्थिति जाँचने के साधन के रूप में mobile device को ध्यान में रखना पड़े
मैंने ऐसा use case कभी सोचा भी नहीं
क्या दूसरों के साथ यह अक्सर होता है?
लगता है code exploration का कम से कम 50% मैं phone पर ही करता हूँ
इसके लिए मैं mobile GitHub web interface बहुत इस्तेमाल करता हूँ, और find references support सच में बहुत मददगार रहा है
search अभी भी खास नहीं है, और SPA की वजह से आने वाली अटकन से page के अंदर की basic find बार-बार टूट जाती है, यह मुझे पसंद नहीं
जब Firefox code खंगालना होता है, तो मैं Searchfox [0] इस्तेमाल करता हूँ; यह तेज़ और शानदार है, और मुझे लगभग कोई शिकायत नहीं
बस mobile पर blame थोड़ा और बेहतर हो सकता है
संदर्भ के लिए, मैं graduate student हूँ, programming languages और systems research करता हूँ, और अपने समय में काफी IoT hacking भी करता हूँ
आप पीढ़ियों की सीमा कहाँ खींचते हैं, इस पर निर्भर करता है कि मैं उम्रदराज़ Gen Z हूँ या जितना संभव हो उतना कम उम्र का Millennial
[0] https://searchfox.org
data coverage अस्थिर होने के अलावा GitHub ठीक से काम करता था, और हल्का code review भी आसानी से हो जाता था
GitHub pulse[1] हाल की activity देखने के लिए अच्छा UI है
SQLite mirror पर GitHub में काम नहीं होता, इसलिए वहाँ सिर्फ commit history है और यह page खाली है, लेकिन linked Caddy project बेहतर उदाहरण है
मुझे व्यक्तिगत रूप से यह timeline से ज़्यादा उपयोगी लगता है
सोच रहा हूँ कि git/GitHub के लिए ऐसा समान view क्या किसी ने पहले से बनाया है
यह इतना मुश्किल नहीं होना चाहिए
[1] https://github.com/caddyserver/caddy/pulse
GitHub पर edit करने के लिए मैंने एक Android editor बनाया था, और बाद में उसे GitLab पर भी चलने लायक बदला
वजहें कई हैं, लेकिन ज़्यादातर इसलिए कि git, चाहे GitHub हो या GitLab, mobile पर इस्तेमाल करना लगभग असंभव है
status देखना संभव है, लेकिन उसके आगे जाना लगभग मुश्किल है
यह लेख मुझे दूसरे मायनों में भी बहुत असरदार लगा
मैंने GitHub पर O’Reilly की एक किताब लिखी है, फिर भी 10 साल से ज़्यादा git इस्तेमाल करने के बाद भी लगता है कि मैं इसे अब तक पूरी तरह नहीं समझ पाया हूँ
यहाँ की बातें काफ़ी relatable हैं
अगर इसे बेहतर तरीके से design और implement किया गया होता, तो यह निश्चित रूप से mobile पर भी काम करता
लोग mobile पर भी GitHub उतनी ही वजहों से देखते हैं जितनी किसी दूसरे platform पर
मैंने भी यह ज़रूर किया है
git के बारे में ऐसी टिप्पणियाँ ज़रूरी नहीं कि “समस्याएँ” हों; ये ज़्यादा features के मूल्यांकन जैसी हैं
आप बस सहमत या असहमत हो सकते हैं, यह ऐसी चीज़ नहीं जिसे हर हाल में खुद झेलना पड़े
यह जैसे graceful degradation और immediate failure के बीच का फ़र्क है
चाहे कोई properly gold-plated option कितना भी अच्छा क्यों न हो, अगर वही एकमात्र option है तो वह नाज़ुक है, और इसलिए बेकार है
कुछ दिन पहले मैंने Git alternatives समझाने वाला एक वीडियो देखा, और Fossil भी स्वाभाविक रूप से उनमें से एक था
मैंने कुछ projects में Fossil इस्तेमाल किया है, और वह ठीक लगा
इस presentation में समझाया गया Pijul https://pijul.org/ बहुत दिलचस्प लगा, और इस पर पहले HN में भी चर्चा हो चुकी है
स्रोत: https://www.youtube.com/watch?v=M4KktA_jbOE
यह version control की पवित्र कंघी जैसा लगता है
लेकिन personal projects में मैं वैसे भी सीधी रेखा में development करता हूँ, और काम पर क्या इस्तेमाल होगा यह मेरे नियंत्रण में नहीं, इसलिए मैंने इसे वास्तव में कभी इस्तेमाल नहीं किया
मैंने व्यक्तिगत लोकल प्रोजेक्ट्स में Fossil इस्तेमाल किया है
यह काफ़ी सक्षम version control system है और इसका web UI भी काफ़ी अच्छा है
लेकिन ध्यान रखने वाली बात यह है कि आधार SQLite repository database का बार-बार backup लेते रहें
मैंने Fossil को upgrade किया, कुछ commits किए, और फिर गलती से उससे भी पुराने Fossil version से commit कर दिया; इसके बाद Fossil repository database ऐसी तरह से corrupt हो गया कि उसे recover नहीं किया जा सका, और कई दिनों का काम खो गया
10 साल तक रोज़ इस्तेमाल करने पर भी Git ने version की परवाह किए बिना repository को एक बार भी corrupt नहीं किया
अलग-अलग systems पर कई साल पुराने versions मनमाने ढंग से पड़े हैं, और system setup के समय जो binary मौजूद थी, उसी को लगातार इस्तेमाल करता रहता हूँ
macOS भी है, कई Linux variants भी हैं, FreeBSD boxes भी हैं, और और पीछे जाएँ तो शायद Windows भी था
इनके बीच मैं अस्थायी जुगाड़ से sync करता हूँ
कुछ repositories 10 साल से भी पुरानी हैं, एक में 10,000 से ज़्यादा commits हैं, और दूसरी इतनी बड़ी है कि उसमें पूरा development environment check in किया गया है और उसका आकार कई GB है
मैंने कभी-कभी कहा है कि rebuild की ज़रूरत होगी, और हर बार वह सफल रहा
commit के दौरान टाइपो दिख जाए तो आदतन
ctrl-cसे बीच में रोक भी देता हूँफिर भी इसने मुझे एक बार भी निराश नहीं किया
Fossil उन सभी programs में से सबसे विश्वसनीय program है जिन्हें मैंने कभी इस्तेमाल किया है
Fossil का आधार artifact format शुरुआत से अब तक compatible रहा है
सुधार हुए हैं, लेकिन कोई breaking change नहीं हुई, और Fossil Forum के असंख्य users के बीच भी ऐसे corruption की reports नहीं आई हैं
मेरा अनुमान है कि आपने नए Fossil में उपलब्ध किसी enhanced feature का उपयोग करके कुछ check in किया, और फिर उसे ऐसे पुराने Fossil से extract करने की कोशिश की जो उस नई feature को समझ नहीं पाता था, इसलिए error मिला
उदाहरण के लिए, Fossil शुरू में सिर्फ़ SHA1 hash इस्तेमाल करता था, लेकिन SHAttered attack के बाद इसे SHA1 और SHA3 दोनों को support करने के लिए बेहतर बनाया गया
यह निश्चित रूप से अनुमान है, लेकिन सबसे संभावित यही लगता है
मैंने SQLite repository, Fossil के self-hosting repository, और अपने पास मौजूद 100 से अधिक Fossil repositories के लिए कभी एक भी शुद्ध backup नहीं बनाया
disaster recovery के लिए दूसरी machines पर clones ज़रूर बनाए हैं
वास्तव में दुनिया भर की कई machines पर cron jobs चलती हैं जो SQLite जैसी महत्वपूर्ण Fossil repositories को हर घंटे
syncकरती हैंलेकिन शुद्ध backup मैंने कभी नहीं बनाया
कुछ साल पहले default SQLite repository एक बार corrupt हुआ था
किसी तरह file descriptor 2 बंद हो गया था, और repository वाली SQLite database खुलते समय file descriptor 2 पर खुल गई
उसके बाद Fossil के किसी bug से
assert()हुआ और उसने file descriptor 2 पर लिखते हुए database के कुछ हिस्से को overwrite कर दियामैंने clone से repository को recover किया, Fossil की assertion defect को ठीक किया, और SQLite को इस तरह सख़्त किया कि वह 3 से छोटे file descriptors का उपयोग न करे
साथ में देखने लायक सामग्री: https://fossil-scm.org/home/doc/trunk/www/selfcheck.wiki
SQLite developers के reliability approach को देखते हुए, यह ऐसा गंभीर bug लगता है जिसे ठीक किया जाना चाहिए
हालाँकि आम तौर पर वे irrecoverable नहीं थीं
वाह, इसने तो मुझे काफ़ी गहराई तक खींच लिया
शायद काफ़ी समय में देखी गई सबसे बेहतरीन चीज़ों में से एक थी
लगता है Fossil इस्तेमाल करते हुए Git/GitHub पर mirror भी किया जा सकता है: https://fossil-scm.org/home/doc/trunk/www/inout.wiki
built-in UI ठीक लगती है, वास्तव में उपयोगी है और navigate करना भी आसान है
लेकिन मैं चाहता था कि UI से commit करना भी supported हो, जो मुझे नहीं मिला
ऐसा हो तो काम पूरा करने के लिए command line और web interface को मिलाकर इस्तेमाल नहीं करना पड़ेगा
अगर Fossil के ऊपर
open,init,commit,sync,sync-with-git,start-web-interfaceको support करने वाला wrapper UI बनाया जा सके, या इसे Fossil में ही जोड़ा जा सके, तो कम technical लोग या non-developers जो code के साथ काम करते हैं—जैसे biology, mathematics, या data science के लोग—उनके लिए Jupyter notebook वगैरह manage करना काफ़ी उपयोगी हो सकता हैबेशक, साधारण git UI clients भी उस काम के लिए इस्तेमाल किए जा सकते हैं, लेकिन तब built-in wiki और tickets खो जाते हैं
local में काम कर पाने की क्षमता भी उपयोगी है, हालाँकि git में भी यह संभव है
वैसे भी, मैंने कम technical लोगों को git, या सामान्य रूप से version control, से बचते हुए देखा है
उसी repository में built-in wiki और tickets होने की संभावना दिखती है
backup के लिए सिर्फ़ एक file होना भी दिलचस्प है
software developers के लिए version control system एक ऐसे tool की तरह है जैसे IDE या आधार operating system
ऐसे tools को जितना कम छेड़ना पड़े, उतनी अधिक productive रहा जा सकता है
कई version control systems इस्तेमाल करने के बाद, Fossil मेरे लिए बिल्कुल सही sweet spot पर बैठता है
सचमुच इसे set करके भूल सकते हैं