Vì sao SQLite không dùng Git
(sqlite.org)- Mã nguồn của SQLite được quản lý bằng Fossil, không phải Git; Fossil là một hệ thống quản lý phiên bản được thiết kế và viết riêng để hỗ trợ SQLite
- Fossil cung cấp tính năng nhận biết tình huống (situational awareness), hiển thị các thay đổi gần đây trên mọi nhánh trong một màn hình duy nhất, và có thể truy cập cả trên điện thoại
- Git chỉ theo dõi lịch sử trước đó của một check-in và khó theo dõi các hậu duệ (descendents) sau đó, trong khi Fossil dễ dàng hiển thị các check-in tiếp theo và cấu trúc phân nhánh
- Với Git, bạn phải luôn để ý 5 trạng thái như thư mục làm việc, staging, head cục bộ/từ xa; còn Fossil chỉ cần xét thư mục làm việc và check-in, giúp giảm 60% gánh nặng
- Người dùng quen Git vẫn có thể truy cập mã nguồn SQLite theo cách tương đương qua mirror GitHub, tải xuống từ web, hoặc cài Fossil
Tổng quan và tiền đề của bài viết
- SQLite dùng Fossil thay vì Git, và Fossil là hệ thống quản lý phiên bản được tự xây dựng với mục đích hỗ trợ SQLite
- Bài viết này không phải là so sánh giữa Fossil và Git, cũng không khuyến nghị ngừng dùng Git
- Nếu hài lòng với Git, bạn cứ tiếp tục dùng
- Nếu Git không phù hợp hoặc bạn đang cân nhắc cải tiến/giải pháp thay thế, bài viết đưa ra một góc nhìn để tham khảo
- Tài liệu này đã được sửa đổi nhiều lần để cải thiện độ rõ ràng và sửa lỗi; có thể xem toàn bộ lịch sử chỉnh sửa
Những lý do SQLite không dùng Git
Git không cung cấp khả năng nhận biết tình huống tốt
- timeline của Fossil cung cấp tóm tắt các thay đổi gần đây trên mọi nhánh trong một màn hình duy nhất, cho phép xem chi tiết chỉ sau vài cú nhấp, và dùng được cả trên điện thoại
- GitHub và GitLab không có tính năng nào tương đương
- Chế độ xem network render chậm (trước khi được cache), ít chi tiết và hầu như không hoạt động trên di động
- Chế độ xem commits nhanh và hoạt động trên di động, nhưng chỉ hiển thị một nhánh tại một thời điểm, nên khó biết bạn đã xem hết mọi thay đổi hay chưa
- GitHub và GitLab là dịch vụ bên thứ ba, không phải thành phần cốt lõi của Git, nên tạo thêm phụ thuộc
- Người dùng Git thường cài trình xem đồ họa của bên thứ ba, nhưng các công cụ này cần cài đặt/quản lý riêng và phụ thuộc vào nền tảng
- GitUp, một trong những công cụ tốt, chỉ hoạt động trên Mac
- Mọi công cụ đều yêu cầu đồng bộ repository cục bộ rồi chạy GUI desktop; không thể kiểm tra trạng thái dự án từ bên ngoài bằng điện thoại
Git khó tìm các check-in tiếp theo (hậu duệ)
- Git có thể nhìn lại quá khứ, nhưng khó theo dõi những gì diễn ra về sau
- Với một check-in cũ cụ thể, có thể thấy lịch sử trước đó nhưng rất khó xác định những gì xuất hiện sau đó
- Fossil cung cấp màn hình hiển thị mọi check-in bắt nguồn từ bản phát hành major mới nhất
- Trong Git, tìm hậu duệ không phải là không thể, nhưng khó
- Trên stackoverflow có một chuỗi lệnh cho unix, nhưng lệnh này chỉ in danh sách hậu duệ, không có cấu trúc phân nhánh
- Lệnh đó chỉ hoạt động khi có clone cục bộ; không thể kiểm tra hậu duệ qua giao diện web như GitHub hay GitLab
- Fossil phản ánh thông tin hậu duệ trên khắp các trang web
- Mỗi trang thông tin check-in đều hiển thị một đồ thị "Context" nhỏ cho thấy check-in ngay trước và ngay sau
- Cung cấp các tính năng hỗ trợ nhận biết tình huống, như nhấp để chuyển sang check-in tiếp theo
- Với Git, về lý thuyết có thể làm được bằng extension/công cụ/lệnh phù hợp, nhưng không dễ nên hầu như không ai làm; kết quả là nhận thức của nhà phát triển về các thay đổi mã bị giảm
Mô hình tư duy của Git phức tạp không cần thiết
- Người dùng Git phải luôn để ý 5 thứ sau
- Thư mục làm việc (working directory)
- "index" hoặc vùng staging
- head cục bộ
- Bản sao cục bộ của head từ xa
- head từ xa thực sự
- Người dùng Fossil chỉ cần xét thư mục làm việc và check-in đang làm việc, tức là ít phân tán chú ý hơn 60%
- Giúp tiết kiệm năng lực tập trung hữu hạn (brain-cycles) của nhà phát triển để họ tập trung vào phần mềm đang phát triển
- Một người dùng cả Git lẫn Fossil từng nói trên HN rằng: "Fossil cho tôi sự yên tâm rằng mọi thứ đã được đồng bộ lên server chỉ bằng một lệnh duy nhất, còn với git thì tôi không có được sự yên tâm đó"
Git không theo dõi tên nhánh trong quá khứ
- Git duy trì toàn bộ DAG của chuỗi check-in, nhưng tag nhánh là thông tin cục bộ, không được đồng bộ và không được giữ lại khi nhánh bị đóng, khiến việc xem lại các nhánh cũ trở nên phiền phức
- Ví dụ: khi hỏi nhánh 'prefer-coroutine-sort-subquery' từ 2 năm trước đã đi đâu
- Fossil: hiển thị rõ rằng nhánh đó cuối cùng đã được merge vào trunk, điểm bắt đầu, và bối cảnh các thay đổi từ trunk đã được merge vào nhánh hai lần
- GitHub: hoàn toàn không hiển thị các thông tin này và trên thực tế vô dụng trong việc hiểu chuyện gì đã xảy ra
- GUI bên thứ ba có thể tốt hơn, nhưng vẫn bị giới hạn bởi việc Git không bảo tồn tên nhánh cũ khi đồng bộ
- Việc cần công cụ bên thứ ba để có được thông tin mong muốn tự thân đã là điểm yếu của hệ thống cốt lõi
Git đòi hỏi nhiều hỗ trợ quản trị hơn
- Git là phần mềm phức tạp; việc cài đặt/nâng cấp trên workstation cần trình cài đặt, và dựng Git server cũng không đơn giản
- Phần lớn sử dụng dịch vụ bên thứ ba như GitHub hoặc GitLab, tạo thêm phụ thuộc
- Fossil là một binary độc lập duy nhất; chỉ cần đặt vào $PATH là cài xong
- Binary duy nhất này bao gồm cả tính năng của Git cốt lõi lẫn GitHub/GitLab
- Quản lý server cộng đồng có wiki, theo dõi lỗi, diễn đàn; cung cấp tải xuống gói; quản lý đăng nhập... mà không cần phần mềm bổ sung
- Dựng server cộng đồng chỉ mất vài phút
- Hoạt động trơn tru cả trên VPS $5/tháng hoặc Raspberry Pi, trong khi GitLab và các hệ thống tương tự đòi hỏi cấu hình cao hơn
- Gánh nặng quản trị càng thấp, nhà phát triển càng có nhiều thời gian làm việc trên phần mềm (SQLite) thay vì hệ thống quản lý phiên bản
Git mang lại trải nghiệm người dùng không tốt
- Truyện tranh xkcd 1597 có phóng đại, nhưng khá gần thực tế
- Ít ai phản đối việc Git mang lại trải nghiệm người dùng dưới mức tối ưu, và phần triển khai nội bộ bị lộ nguyên ra giao diện
- Giao diện tệ đến mức có cả website nhại tạo các trang man giả cho git
- Một hệ thống quản lý phiên bản tốt nên hỗ trợ thay vì gây bực bội; Git đã cải thiện trong 10 năm qua nhưng vẫn còn một chặng đường dài
Hướng dẫn truy cập mã nguồn SQLite cho người dùng Git
Mirror GitHub chính thức
- Từ 2019-03-20, trên GitHub có mirror Git chính thức của mã nguồn SQLite
- Đây là bản xuất tăng dần từ repository Fossil chính thức; một cron job cập nhật repository GitHub mỗi giờ một lần
- Là mirror một chiều, chỉ đọc, không nhận pull request hay thay đổi
- Mọi thay đổi chỉ được đưa vào thông qua Fossil
- Hash định danh check-in và file khác nhau giữa mirror Git và Fossil
- Lý do chính là Fossil dùng hash SHA3-256, còn Git dùng SHA1
- Khi xuất, hash Fossil gốc được thêm vào footer của comment check-in; để tránh nhầm lẫn khi tham chiếu check-in SQLite, nên luôn dùng hash Fossil gốc
Truy cập qua web
- Repository Fossil của SQLite cung cấp liên kết tải xuống Tarball, ZIP Archive, SQLite Archive cho bất kỳ phiên bản cũ nào
- Định dạng URL đơn giản nên dễ tích hợp vào công cụ tự động hóa
- Định dạng cơ bản:
https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz - VERSION có thể dùng tiền tố hash, tên nhánh, tag (ví dụ: "version-3.23.1")
- Bản phát hành mới nhất dùng "release", trunk mới nhất dùng "trunk"
- Với ZIP hoặc SQLite Archive, đổi "/tarball/" thành "/zip/" hoặc "/sqlar/"
- Định dạng cơ bản:
Truy cập bằng Fossil
- Fossil dễ cài đặt và sử dụng; dưới đây là quy trình cho unix (Windows cũng tương tự)
- Tải file thực thi fossil rồi đặt vào $PATH
- Clone repository bằng
fossil clone, sau đó mở bằngfossil open - Sau đó có thể chạy
./configure; make(với MSVC trên Windows:nmake /f Makefile.msc)
- Dùng lệnh
fossil update VERSIONđể đổi checkout sang phiên bản khác (VERSION có thể là trunk, tiền tố hash, nhánh hoặc tag) - Trong checkout, chạy lệnh
fossil uiđể khởi chạy website cục bộ- Vì không đăng nhập thì không thể push thay đổi, nên bạn không thể làm hỏng dự án và có thể tự do khám phá/thử nghiệm
Kiểm chứng tính toàn vẹn của mã nguồn
- Ở root của cây mã nguồn có file "manifest"
- File này chứa tên mọi file và hash SHA1 hoặc SHA3-256 của từng file (file cũ dùng SHA1, file mới dùng SHA3-256)
- Có thể dùng script để trích xuất hash và đối chiếu với file nguồn nhằm xác minh
- Tên hash của một check-in là hash SHA3-256 của chính file "manifest"; nếu dòng cuối bắt đầu bằng "# Remove this line..." thì có thể bỏ qua dòng đó
1 bình luận
Ý kiến trên Hacker News
Tôi đã thử tổng hợp các công cụ quản lý phiên bản mà mình dùng trong nhiều thập kỷ, cùng năm chúng được tạo ra và năm cuối cùng tôi còn dùng: sccs 1973~2000, rcs 1982~2000, cvs 1990~2004, clearcase 1992~2004, perforce 1995~2011, subversion 2000~2015, mercurial 2005~2015, git 2005~nay
Ít nhất với tôi, vòng đời của các công cụ này vào khoảng 15 năm
Nhưng khi tôi nói với các bạn junior rằng “đến khi các bạn bằng tuổi tôi, git sẽ chỉ còn là một ký ức xa xôi và kỳ lạ”, họ lại nhìn tôi rất lạ
git là một công cụ tuyệt vời và xứng đáng thành công, nhưng sẽ hơi đáng tiếc nếu vấn đề này kết thúc ở git
Joel on Software từng có bài viết nói rằng phần mềm thường gần như hoàn thiện sau khoảng 4 phiên bản, và ví dụ là phần mềm văn phòng, đặc biệt là Excel
Ngay cả khi mở Excel 4 lên bây giờ, các chức năng cốt lõi về cơ bản vẫn đều có đủ, nên điều đó có vẻ đúng
git có lẽ sẽ tồn tại ít nhất lâu gấp đôi các công cụ quản lý phiên bản trước đó
Vấn đề là CVS là ngõ cụt, không thể mở rộng sang mô hình phát triển phân tán
Git quay lại mô hình RCS cục bộ rồi thêm commit nguyên tử vào, nhờ đó thoát khỏi điểm tối ưu cục bộ mang tên Subversion
Nó có những lựa chọn gây tranh cãi như không theo dõi đổi tên hoặc không có số revision tuyến tính, nhưng đó không thành vấn đề lớn, và nó cho phép làm việc rất hiệu quả mà không gặp vấn đề hiệu năng kiểu darcs
Nhìn vào hàng loạt nỗ lực sửa quản lý phiên bản trong giai đoạn 1995~2010, mô hình dữ liệu nền tảng của git có vẻ cực kỳ khó cải tiến hơn nữa, kể cả khi tính cả các phần bổ sung như git-lfs
Có thể sẽ xuất hiện giao diện dòng lệnh mới, nhưng ngày càng khó đẩy được kẻ thống trị hiện tại ra ngoài, và tôi không quen ai dùng
git switchhaygit restorethay chogit checkoutvốn quá tải và dễ gây nhầm lẫnỞ các bộ phận khác trong công ty cũng có dùng một ít svn, nhưng chỉ đến thế thôi
Hệ thống quản lý phiên bản không thay đổi nhanh đến vậy
Các công cụ trong danh sách trước khi quản lý phiên bản phân tán xuất hiện thực ra có khá nhiều điểm chung, và git có vẻ sẽ còn tồn tại rất lâu
Trong lịch sử từng có nhiều ngôn ngữ thống trị, nhưng tiếng Anh sẽ là ngôn ngữ cuối cùng; từng có nhiều ngôn ngữ scripting, nhưng javascript sẽ là ngôn ngữ cuối cùng; từng có nhiều giao thức mạng, nhưng TCP/IP sẽ là giao thức cuối cùng
Tôi nghĩ git cũng vậy
Thứ có thể thay thế git chắc chỉ là các môi trường dành cho lập trình viên mới có kèm sẵn hệ thống quản lý phiên bản riêng, như glitch[1]
[1]: https://medium.com/glitch/reinventing-version-control-with-g...
Tôi nghĩ git bị mang tiếng xấu là vì chẳng ai thống nhất được cách dùng
Chỉ riêng GitHub PR với push lên branch, rebase với merge, cũng đã là những công cụ làm về bản chất cùng một việc nhưng theo các cách hoàn toàn khác nhau
Vấn đề là không bên nào sai cả
Rebase các commit nhỏ giúp giảm bớt sự phức tạp không cần thiết của lịch sử, còn merge thì giữ lại những gì thực sự đã xảy ra, giúp hiểu vì sao thay đổi được tạo ra
Tất nhiên merge ngược là thứ tệ nhất, nhưng đó lại là một cơn đau đầu khác
Khi push lên branch, bạn có thể tuyệt đối không force push, nhưng với branch PR thì gần như lúc nào cũng force push
Ngay cả những thứ đơn giản cũng tạo ra những rạn nứt không thể dung hòa
Tôi học rằng kho chính là origin, còn fork của tôi là fork, nhưng có người lại học rằng kho chính là upstream, còn fork của họ là origin
Cả hai đều không hẳn sai, nhưng nếu origin có thể chỉ đến hai nơi hoàn toàn khác nhau thì việc giao tiếp rõ ràng sẽ rất khó
Trên thực tế, tôi chủ động rebase các commit trong PR chỉ với một câu hỏi duy nhất: “làm sao để việc review dễ nhất?”
Khi review xong, tôi lại hỏi: “hình thức nào sẽ dễ vận hành và dễ hiểu nhất về sau?” rồi có thể squash tất cả lại, hoặc tái cấu trúc chúng thành những phần có thể triển khai độc lập để dễ rollback
Cốt lõi là những việc này có thể có các nhu cầu khác nhau, và dùng các cách khác nhau ở từng thời điểm cũng không sao
Chỉ là cách đó đòi hỏi nhiều năng lực phán đoán cá nhân hơn, và khó dạy cũng như áp dụng bắt buộc cho cả một đội ngũ lớn
Loại đầu là những thứ không ảnh hưởng đến người khác
Ví dụ, bạn đặt tên remote là
originvàupstream, hay làforkvàorigin, thì đồng nghiệp cũng không quan tâmLoại sau là những thứ cần phối hợp với người khác
Ví dụ như việc cuối cùng muốn để lại lịch sử git theo hình dạng nào
Nếu Apple thiết kế giao diện dòng lệnh của git thì xét về trải nghiệm người dùng, nó có lẽ sẽ tốt hơn gấp 10 tỷ lần, và mức độ mạnh mẽ chỉ giảm khoảng 10%
Fossil hợp với họ thì tốt thôi, nhưng câu này khá chướng tai: “Fossil là một tệp nhị phân thực thi độc lập duy nhất, chỉ cần đưa vào
$PATHlà coi như cài xong, và trong đó có cả các tính năng cốt lõi của Git lẫn các tính năng kiểu GitHub/GitLab…”git dù có nhiều vấn đề đi nữa thì cũng không phải kiểu nhét cả bồn rửa chén vào một chỗ
Tôi thích cách tiếp cận “làm tốt một việc” hơn
Ví dụ, chạy
git instawebsẽ khởi chạy một máy chủ CGI cục bộ cùng script Perl CGI để cung cấp một giao diện web cực kỳ đơn giản: https://git-scm.com/docs/git-instawebXét ở điểm này thì cũng không khác mấy so với các tính năng cốt lõi của Fossil
Git cũng có nhiều tính năng tích hợp với ứng dụng email mà những người chỉ dùng GitHub có lẽ còn không biết là tồn tại, chứ chưa nói đến biết vì sao lại có
Chẳng hạn như
git send-email, dùng để gửi patch qua email ngay từ git: https://git-scm.com/docs/git-send-emailMọi thứ đều là tổ hợp, mọi thứ đều là pipeline của các lệnh, đều được tạo thành từ nhiều phần
“Việc cần làm” không phải thứ tuyệt đối mà phụ thuộc vào góc nhìn của người quan sát
Nguyên tắc trách nhiệm đơn nhất không được áp dụng nguyên xi vào thực tế; nó chỉ là một sự đánh đổi để giữ cân bằng giữa tính kết dính và tính mô-đun
Cắt ở đâu để gọi là “một” là tùy vào chúng ta và nhu cầu của chúng ta
Với nhiều người, các công cụ của GitHub đã tích hợp vào quy trình làm việc đến mức Git đơn thuần hoàn toàn không dùng được
Với họ thì GitHub mới là “một việc”, còn SQLite cũng có “một việc” của riêng SQLite
Như đã nói, điều đó đi ngược lại triết lý Unix là làm tốt một việc
Với tôi, rõ ràng sạch sẽ hơn nếu chia hệ thống thành các thành phần có thể thay thế hoặc chỉnh sửa độc lập về sau
Bộ cài nặng hơn 50MB và nếu tôi nhớ không nhầm còn kèm cả terminal
Trong khi đó, Fossil cho tải xuống một tệp nhị phân độc lập 3.3MB cho từng nền tảng được hỗ trợ
https://git-man-page-generator.lokaltog.net là thứ buồn cười nhất tôi thấy trong một thời gian dài
git-erase-working-treelà “hãy dùng khi bạn muốn cẩn thận xóa cây làm việc hiện tại của root thượng nguồn và cấu hình, rồi quiltimport nó bằng GUI đang hoạt động” nghe hữu ích ghêgit-molest-headthì “quấy rối sai cách head thượng nguồn bằng cách dùng chỉ mục từ xa, và thực hiện các hook phù hợp để lập bảng head đã cho”, nghe hơi kích thích quá đàGit có nhiều lệnh kỳ quặc đến mức giờ chuyện đó cũng chẳng còn làm tôi ngạc nhiên
git-tease-chain,git-scrub-dangling-object,git-seize-mailmap,git-dress-graft,git-strangle-tree,git-satisfy-daemon,git-pat-tree-objectMuốn bịa cho ra hồn hơn chắc phải nêm thêm gia vị LLM
Các thảo luận trước đó:
Năm 2021, 356 bình luận: https://news.ycombinator.com/item?id=29125934
Năm 2018, 608 bình luận: https://news.ycombinator.com/item?id=16806114
Chắc còn nữa, nhưng cùng một tài liệu lại có thể được tìm thấy qua nhiều đường dẫn, cả khi không có miền
www, không có đường dẫn/drafts/, hoặc không có đường dẫn/matrix/, nên việc tìm các bài đăng trước đây khó hơnỞ đây có cả những phê bình chính đáng về Git, nhưng một vài điểm thì hơi lạ.
Tôi đã dùng Git trong đủ loại tình huống, từ kho lưu trữ cá nhân cục bộ đến kho của các công ty rất lớn, và thành thật mà nói tôi chưa từng gặp khoảng một nửa số vấn đề này.
Đoạn “network render chậm, ít thông tin chi tiết hơn nhiều, và trên di động thì gần như không hoạt động” cũng vậy, và tôi hy vọng sẽ không bao giờ đến ngày đội của chúng tôi phải tính đến thiết bị di động như một phương tiện để kiểm tra trạng thái nhánh.
Tôi chưa từng nghĩ đến kiểu trường hợp sử dụng đó.
Với người khác thì chuyện này có xảy ra thường xuyên không?
Có vẻ ít nhất 50% việc khám phá code của tôi là trên điện thoại.
Tôi dùng giao diện web GitHub trên di động khá nhiều cho việc đó, và hỗ trợ tìm tham chiếu thực sự rất hữu ích.
Tìm kiếm thì vẫn chưa tốt lắm, và tôi ghét việc độ giật đặc trưng của SPA cứ phá hỏng tính năng tìm trong trang mặc định.
Khi cần lục code Firefox thì tôi dùng Searchfox [0]; nó nhanh, tuyệt vời và tôi hầu như không có gì để phàn nàn.
Chỉ là
blametrên di động có thể làm tốt hơn nữa.Nói thêm cho có bối cảnh, tôi là nghiên cứu sinh, làm nghiên cứu về ngôn ngữ lập trình và hệ thống, đồng thời cũng nghịch hack IoT khá nhiều trong thời gian riêng.
Tùy bạn đặt ranh giới thế hệ ở đâu, tôi là Gen Z lớn tuổi hoặc Millennial trẻ nhất có thể.
[0] https://searchfox.org
Trừ việc vùng phủ dữ liệu không ổn định, GitHub hoạt động tốt và cũng dễ làm review code nhẹ.
GitHub pulse[1] là một UI tốt để xem hoạt động gần đây.
Mirror SQLite không làm việc trên GitHub nên chỉ có lịch sử commit và trang này để trống, nhưng dự án Caddy được liên kết là một ví dụ tốt hơn.
Cá nhân tôi thấy nó hữu ích hơn timeline.
Tôi tự hỏi đã có ai làm một view tương đương cho git/GitHub chưa.
Có vẻ cũng không quá khó.
[1] https://github.com/caddyserver/caddy/pulse
Tôi đã làm một trình soạn thảo Android để chỉnh sửa trên GitHub, rồi sau đó sửa để nó cũng chạy với GitLab.
Có nhiều lý do, nhưng phần lớn là vì git, dù là trên GitHub hay GitLab, gần như không thể dùng trên di động.
Kiểm tra trạng thái thì được, nhưng hơn thế nữa thì gần như rất khó.
Bài viết này còn chạm đúng ở nhiều khía cạnh khác.
Dù tôi từng viết sách O’Reilly về GitHub, sau hơn 10 năm dùng git tôi vẫn cảm thấy mình chưa hiểu nó hoàn toàn.
Những điểm được nêu ở đây rất đáng đồng cảm.
Nếu được thiết kế và triển khai tốt hơn thì dĩ nhiên nó cũng đã hoạt động trên di động.
Mọi người truy cập GitHub trên di động vì cùng những lý do họ truy cập GitHub trên các nền tảng khác.
Tôi chắc chắn cũng đã làm vậy.
Những nhận xét kiểu này về git không hẳn là vấn đề, mà gần với đánh giá giá trị của tính năng hơn.
Bạn có thể đồng ý hoặc không đồng ý, chứ không nhất thiết phải là kiểu thứ bạn buộc phải trực tiếp gặp mới được.
Có vẻ đây là khác biệt giữa suy giảm hiệu năng dần dần và thất bại ngay lập tức.
Dù một lựa chọn dát vàng chuẩn chỉnh có tốt đến đâu, nếu đó là lựa chọn duy nhất thì nó sẽ mong manh và vì thế trở thành đồ bỏ.
Vài ngày trước tôi xem một video giải thích các lựa chọn thay thế Git, và tất nhiên Fossil cũng là một trong số đó.
Tôi đã dùng Fossil ở một vài dự án và thấy ổn.
Pijul https://pijul.org/ được giải thích trong bài thuyết trình này rất thú vị, và trước đây cũng từng được thảo luận trên HN.
Nguồn: https://www.youtube.com/watch?v=M4KktA_jbOE
Nó giống như chén thánh của quản lý phiên bản vậy.
Nhưng trong các dự án cá nhân thì dù sao tôi cũng phát triển theo đường thẳng, còn ở chỗ làm thì tôi không kiểm soát được dùng gì, nên thực tế chưa từng dùng nó.
Tôi đã dùng Fossil cho các dự án cá nhân trên máy cục bộ
Đây là một hệ thống quản lý phiên bản khá năng lực và giao diện web cũng khá ổn
Tuy vậy, điều cần lưu ý là hãy thường xuyên sao lưu cơ sở dữ liệu kho lưu trữ SQLite nền tảng của nó
Sau khi nâng cấp Fossil, thực hiện vài lần commit, rồi vô tình commit bằng một phiên bản Fossil cũ hơn, cơ sở dữ liệu kho Fossil đã bị hỏng không thể khôi phục và tôi mất vài ngày làm việc
Trong 10 năm dùng hằng ngày, Git chưa từng một lần làm hỏng kho lưu trữ bất kể phiên bản nào
Tôi có các phiên bản chênh nhau vài năm nằm rải rác tùy ý trên nhiều hệ thống khác nhau, và cứ tiếp tục dùng nguyên các binary có sẵn khi thiết lập hệ thống
Có macOS, nhiều biến thể Linux, vài máy FreeBSD, và nếu nhớ xa hơn thì có lẽ cả Windows nữa
Tôi đồng bộ giữa chúng theo kiểu chắp vá tạm bợ
Có kho đã hơn 10 năm tuổi, một kho có hơn 10.000 commit, và một kho khác thì check in cả môi trường phát triển nên nặng tới vài GB
Thỉnh thoảng người ta nói cần phải rebuild, và lần nào cũng thành công
Nếu phát hiện lỗi gõ trong lúc commit, tôi còn có thói quen bấm
ctrl-cđể hủy giữa chừngVậy mà nó chưa từng làm tôi thất vọng
Fossil là chương trình đáng tin cậy nhất tôi từng dùng, bỏ xa các chương trình khác
Định dạng artifact nền tảng của Fossil vẫn tương thích từ lúc ban đầu cho đến nay
Đã có cải tiến, nhưng không có thay đổi phá vỡ tương thích, và cũng không có báo cáo hỏng kiểu đó từ rất nhiều người dùng trên Fossil Forum
Phỏng đoán của tôi là có lẽ bạn đã check in thứ gì đó bằng một Fossil mới hơn có dùng tính năng nâng cao, rồi sau đó cố extract bằng một Fossil cũ không hiểu được tính năng mới đó nên gặp lỗi
Ví dụ, lúc đầu Fossil chỉ dùng băm SHA1, nhưng sau cuộc tấn công SHAttered thì đã được nâng cấp để hỗ trợ cả SHA1 lẫn SHA3
Tất nhiên đây chỉ là suy đoán, nhưng có vẻ hợp lý nhất
Tôi chưa từng tạo một bản sao lưu thuần túy nào cho kho SQLite, kho tự host của chính Fossil, hay hơn 100 kho Fossil mà tôi đang có
Tôi có tạo clone trên máy khác để phòng thảm họa
Thực tế, trên nhiều máy khắp thế giới đang có các tác vụ cron chạy
syncmỗi giờ cho những kho Fossil quan trọng như SQLiteNhưng tôi chưa từng tạo bản sao lưu thuần túy nào
Vài năm trước kho SQLite gốc từng bị hỏng một lần
Không hiểu sao file descriptor 2 bị đóng, và khi mở cơ sở dữ liệu SQLite là kho lưu trữ thì nó được mở bằng file descriptor 2
Sau đó, một lỗi nào đó trong Fossil kích hoạt
assert(), ghi vào file descriptor 2 và ghi đè lên một phần cơ sở dữ liệuChúng tôi đã phục hồi kho từ clone, sửa lỗi assertion của Fossil, và tăng cường SQLite để không dùng file descriptor nhỏ hơn 3
Tài liệu liên quan: https://fossil-scm.org/home/doc/trunk/www/selfcheck.wiki
Xét theo cách tiếp cận về độ tin cậy của các nhà phát triển SQLite, tôi nghĩ nên xem đây là một lỗi nghiêm trọng cần được sửa
Nhưng thường thì không đến mức không thể khôi phục
Wow, cái này làm tôi đọc say mê luôn
Có lẽ là thứ hay nhất tôi đọc được trong một thời gian dài
Có vẻ bạn có thể dùng Fossil đồng thời mirror sang Git/GitHub: https://fossil-scm.org/home/doc/trunk/www/inout.wiki
Giao diện tích hợp sẵn trông khá ổn, thực sự dùng được và cũng dễ khám phá
Tuy nhiên tôi có hy vọng UI cũng hỗ trợ commit, nhưng không tìm thấy
Như vậy sẽ không phải trộn lẫn dòng lệnh với giao diện web chỉ để hoàn tất công việc
Nếu có thể làm một UI bọc trên Fossil hỗ trợ
open,init,commit,sync,sync-with-git,start-web-interface, hoặc đưa thẳng vào chính Fossil, thì có lẽ sẽ khá hữu ích cho những người ít thiên về kỹ thuật hoặc không phải lập trình viên nhưng vẫn làm việc với mã nguồn, ví dụ trong sinh học, toán học, hay khoa học dữ liệu để quản lý Jupyter notebook v.v.Tất nhiên, một client UI đơn giản cho git cũng có thể dùng cho mục đích đó, nhưng như vậy sẽ mất wiki và hệ thống ticket tích hợp sẵn
Khả năng làm việc cục bộ cũng hữu ích, nhưng git cũng làm được điều đó
Dù sao thì tôi cũng từng thấy những người kém kỹ thuật hơn ngại dùng git, hoặc ngại cả quản lý phiên bản nói chung
Tôi thấy có tiềm năng ở việc wiki và ticket tích hợp sẵn trong cùng một kho
Việc chỉ có đúng một tệp để sao lưu cũng khá thú vị
Với lập trình viên phần mềm, hệ thống quản lý phiên bản là một công cụ giống như IDE hay hệ điều hành nền tảng
Càng ít phải loay hoay với những công cụ này thì càng làm việc hiệu quả hơn
Sau khi đã dùng nhiều hệ thống quản lý phiên bản khác nhau, Fossil với tôi nằm đúng vào sweet spot hoàn hảo
Thực sự chỉ cần thiết lập xong rồi quên nó đi