- Lore do Epic Games duy trì là hệ thống quản lý phiên bản mã nguồn mở thế hệ mới, hướng tới các dự án xử lý đồng thời mã nguồn và tài sản nhị phân dung lượng lớn
- Có thể khởi động nhanh ở môi trường cục bộ rồi mở rộng khi cần, hỗ trợ kho lưu trữ và đội ngũ quy mô lớn nhờ dữ liệu chia sẻ/tái sử dụng và cơ chế tải xuống đúng thời điểm cần thiết
- Sử dụng kho lưu trữ định địa chỉ theo nội dung tập trung, biểu diễn trạng thái kho và lịch sử thay đổi bằng Merkle tree và chuỗi revision bất biến
- Tệp dung lượng lớn được lưu dưới dạng chunk có thể tái sử dụng, và với sparse workspace cùng on-demand hydration, không cần tải toàn bộ dữ liệu ngay từ đầu
- Được phát hành theo giấy phép MIT, cung cấp CLI, API cho C/C++, C#, Rust, Go, Python, JavaScript và nhiều kho SDK
Quản lý phiên bản cho cả mã nguồn và tài sản dung lượng lớn
- Lore là hệ thống quản lý phiên bản mã nguồn mở thế hệ mới do Epic Games duy trì
- Được thiết kế với mục tiêu mở rộng cao về quy mô dữ liệu, quy mô đội ngũ, mức độ phân tán của đội ngũ và quy mô kho lưu trữ
- Tối ưu cho các dự án sử dụng đồng thời mã nguồn và tài sản nhị phân dung lượng lớn
- Ví dụ được nêu là các dự án trong ngành game và giải trí
- Đồng thời đáp ứng nhu cầu cộng tác giữa lập trình viên và nghệ sĩ
- Có thể bắt đầu ở chế độ cục bộ chỉ trong vài phút, sau đó mở rộng theo nhu cầu
- Cung cấp nền tảng để các nhóm xây dựng quy trình cộng tác nhanh, trực quan và thực tế
Cấu trúc cho khả năng mở rộng và xử lý tệp lớn
-
Dữ liệu chia sẻ và API
- Các tính năng chính được xây dựng xoay quanh khả năng mở rộng và xử lý tài sản dung lượng lớn
- Hướng tới việc mở rộng mà không làm giảm tốc độ nhờ dữ liệu chia sẻ/tái sử dụng và tải xuống vào đúng thời điểm cần thiết
- Có thể tạo, quản lý và đồng bộ nhánh nhanh chóng
- Có thể truy cập toàn bộ tính năng của Lore theo tương ứng một-một thông qua CLI
- Hỗ trợ mở rộng, tùy biến và tích hợp qua API cho C/C++, C#, Rust, Go, Python và JavaScript
-
Kho lưu trữ định địa chỉ theo nội dung
- Cấu trúc kho là hệ thống quản lý phiên bản content-addressed tập trung
- Dữ liệu trong kho được lưu trữ/tham chiếu bằng hash nội dung và được biểu diễn bằng Merkle tree
- Hỗ trợ so sánh nhanh, kiểm tra tính toàn vẹn, cũng như tái sử dụng dữ liệu giữa lịch sử và các nhánh
- Chữ ký hash của revision được suy ra từ trạng thái revision, bao gồm hash của revision cha và hash của dữ liệu được chứa bên trong
- Cấu trúc này hình thành một chuỗi bất biến có tính toàn vẹn mật mã
-
Lưu trữ theo chunk và tải xuống khi cần
- Việc xử lý tệp lớn và workspace sử dụng lưu trữ theo chunk và on-demand hydration
- Tệp được lưu dưới dạng các chunk có thể tái sử dụng và sử dụng truy vấn dựa trên chỉ mục
- Giảm trùng lặp và tối ưu việc cập nhật cũng như truyền tải tài sản nhị phân dung lượng lớn
- Workspace có thể được giữ gọn nhẹ bằng cách chỉ lấy dữ liệu tệp cần thiết
- Với sparse workspace, không cần tải toàn bộ dữ liệu ngay từ đầu
-
Mô hình máy chủ và nhánh
- Cấu trúc máy chủ là kiến trúc dựa trên dịch vụ có bao gồm cơ chế cache
- Việc cache phía trước durable storage hỗ trợ mở rộng thông lượng cho đội ngũ lớn và kho lưu trữ lớn
- Nhánh hoạt động như mutable reference nhẹ, nên chi phí tạo và chuyển đổi thấp, không có trùng lặp dữ liệu nền tảng
Kho công khai và tài liệu
- Epic Games đã phát hành Lore dưới dạng mã nguồn mở hoàn toàn theo giấy phép MIT
- Lore Library, Server & CLI
- Javascript SDK
- Python SDK
- C# SDK
- Go SDK
- Tài liệu và tài liệu thiết kế hệ thống được cung cấp tại Lore docs và system design doc
2 bình luận
Ý kiến trên Hacker News
Thêm chút ngữ cảnh cho độc giả HN chưa từng chơi game: đây không phải công cụ nhằm cạnh tranh với Git trong phát triển phần mềm nói chung, mà là công cụ nhằm cạnh tranh với Perforce trong phát triển game
Git ổn với các tệp dựa trên văn bản như mã nguồn, nhưng rất yếu khi cộng tác trên các tệp phi văn bản như texture, mô hình 3D, hay tệp âm thanh. Ví dụ, không có cách hợp lý để gộp các bản chỉnh sửa không đồng bộ từ hai nghệ sĩ, nên có thể phải đặt khóa độc quyền lên asset mà một nghệ sĩ đang chỉnh sửa
Kẻ dẫn đầu trên thực tế trong lĩnh vực này là hệ thống độc quyền Perforce(https://www.perforce.com/products/helix-core). Theo bạn bè là lập trình viên game của tôi, Perforce rất tuyệt khi chạy tốt, nhưng cũng có đủ nhiều điểm vướng để cần kỹ sư công cụ quản lý và thỉnh thoảng sửa thủ công. Git LFS cũng là một lựa chọn thay thế, nhưng với các dự án đội nhóm từ 3–4 người trở lên thì mọi người vẫn thích Perforce hơn
Trong P4, có thể giới hạn quyền truy cập vào các thư mục cụ thể chỉ cho những người đã ký NDA cần thiết, còn với Git thì либо cho toàn bộ либо chặn toàn bộ. Có thể dựng gì đó bằng submodule, nhưng nếu ban đầu không thiết kế như vậy thì sẽ phải lật lại cấu trúc repository khá lớn
git clone, tứcp4 sync, có thể lên tới hàng terabyteGit yếu trong việc xử lý asset nhị phân, texture, model, âm thanh... ở quy mô như vậy
Nếu có những asset được cập nhật thường xuyên ở giai đoạn đầu phát triển, bạn sẽ phải gánh chi phí lưu trữ đó suốt vòng đời của repository. Trong phát triển game, chuyện này rất thường gặp. Phần lớn asset được chỉnh đi sửa lại nhiều lần lúc đầu, rồi khi hoàn thiện thì không bao giờ động tới nữa
Ngay cả hôm nay khi push thay đổi lên Github, tôi vẫn nghĩ về việc UI của Git thiếu thân thiện với người dùng đến mức nào
Những dòng output như
Enumerating objects,Counting objects,Delta compression,Writing objects,pack-reused,Resolving deltascó thể truyền tải điều gì đó với người dùng Git kỳ cựu, nhưng với đa số mọi người thì hoàn toàn là nói nhảm. “Nén delta” rốt cuộc là gì, tại sao phải biết đang dùng bao nhiêu thread, và “object”, object “local”, hay “pack-reused” nghĩa là gì thì rất khó hiểuTheo tài liệu, có vẻ Lore xử lý phần này tốt hơn một chút. Nó trông như
Pushing 1 fragment(s),Pushed 1 fragment(s), 124.00 bytes,Pushed revision 1 -> a3f8c2d1... to branch main-v. Chắc chỉ là chưa ai đụng tới, và trong vài chục năm qua mọi người đã học cách mặc kệ nóObject được tree tham chiếu tới, còn tree thì đơn giản là thư mục. Tree lại được commit hoặc tag tham chiếu tới để tạo thành DAG, và các con trỏ có tên trỏ vào nhiều điểm trong đó chính là branch và tag ref: https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Việc để quá nhiều object rời rạc là cực kỳ kém hiệu quả, nên Git định kỳ gom các object lại thành pack. Để tiết kiệm dung lượng, nó so sánh và nén các object với nhau bên trong pack, đó chính là nén delta: https://git-scm.com/docs/git-pack-objects, https://github.com/git/git/blob/master/Documentation/technic...
Khi push hoặc pull, giao thức truyền tải của Git sẽ liệt kê object mà hai bên đang có và chỉ truyền phần khác biệt. Ngoài ra, các object chưa được đóng pack cũng sẽ được nén delta ở cả hai phía để tiết kiệm dung lượng: https://github.com/git/git/blob/master/Documentation/technic...
Git là một dự án mã nguồn mở do dân mê kỹ thuật tạo ra nên nó hiển thị toàn bộ những thông tin này. Bạn cứ bỏ qua cũng được. Nếu thực sự muốn biết, mọi thứ đều đã được tài liệu hóa trong cuốn sách Git và thư mục tài liệu được liên kết ở trên
Dần dần tôi đã thấy hợp lý hơn. Xét về UI thì đó là một cải tiến lớn so với Git. Tuy vậy, quy trình làm việc với branch vẫn cần chút thời gian để quen
Tôi cực kỳ khuyến nghị tự mở thư mục
.gitra xem trực tiếp. Làm vậy thì nhu cầu hỗ trợ Git cho nhân viên mới gần như về 0Thông báo này đặc biệt rất hứa hẹn cho phát triển game với Unreal. Nếu là mục đích khác thì tôi không thấy hứng thú đến vậy.
Perforce rõ ràng cần có đối thủ cạnh tranh. Lý do Perforce là thế lực mạnh sẵn có không phải vì nó đặc biệt đơn giản để dùng hay quản trị. Ví dụ chỉ xét riêng thao tác branch thì Git thực ra đơn giản hơn nhiều.
Trong phát triển game, lý do P4 thường được ưa chuộng là hỗ trợ dự án lớn, phân quyền, khóa file... như các bình luận khác đã nói. Một lý do cốt lõi nữa là P4 được hỗ trợ rất tốt bên trong Unreal Engine. Dù không hoàn hảo, đây là hệ thống quản lý phiên bản được hỗ trợ tốt nhất vì Epic dùng nó nội bộ. Plugin Git thì Epic không dùng nội bộ, nên còn dang dở đến mức gây đau khổ.
Vì vậy tôi kỳ vọng Lore sẽ nhận được hỗ trợ hạng nhất. Nếu Unreal hỗ trợ tốt hơn thì có lẽ tôi đã khuyến nghị Git nhiều hơn rất nhiều. Nói thêm về bối cảnh, tôi đã làm game gần 20 năm, qua các công ty từ 2 người đến 200 người, với đủ loại engine và hệ thống quản lý phiên bản. Ở nơi nào dùng được thì tôi thích Git, nhưng với Unreal thì chỉ khi dự án nhỏ hoặc thành viên trong nhóm rất rành kỹ thuật. Cứ chọn công cụ phù hợp với công việc và đội ngũ là được.
https://github.com/EpicGames/UnrealEngine/pull/14630
Ở studio game trước đây, chúng tôi phải dùng Perforce, chính xác là Helix Core Cloud, một tiêu chuẩn thực tế của ngành mà phần lớn các vị trí sáng tạo đã quen dùng. Lập trình viên thì không thích, nhưng trong ngành game, bên nắm quyền quyết định không phải là lập trình viên. Đây cũng là lựa chọn mặc định an toàn và đã được kiểm chứng khi dùng với Unreal Engine 5.
Dù vậy, nó vẫn để lộ cảm giác cũ kỹ. Vì nhóm chúng tôi nhỏ và không muốn tự host, nên đã dùng dịch vụ đám mây Perforce từ khá sớm, và trải nghiệm khá lộn xộn. Muốn truy cập dịch vụ thì phải đăng ký tài khoản Azure, còn muốn thay đổi thứ gì như trigger thì phải nhờ đội hỗ trợ. Nếu bạn đến từ thế giới GitHub hay các sản phẩm SaaS khác, sẽ cảm nhận rõ đây là một nỗ lực khoác vỏ mới lên một mô hình cũ.
Hướng đi với Git LFS cũng có một chút hỗ trợ không chính thức, nhưng nếu mọi thứ rối tung lên thì bạn phải tự xử. Epic không giúp được nhiều ở đó. Đặc biệt nếu mục tiêu là hỗ trợ chính thức đầy đủ ngay trong engine, thì cạnh tranh trong mảng này là điều đáng hoan nghênh.
Tôi đã viết một bài giải thích vì sao việc merge file không phổ biến trong thế giới phát triển game cho những người đến từ môi trường phát triển dựa trên văn bản: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
Tôi vừa tiếp quản một đội đang dùng Git, và dù tôi biết Git là hệ thống quản lý phiên bản mà ai cũng thích, nó gần như là một trong những lựa chọn tệ nhất cho game. Với Git, thời gian review asset phải tính bằng giờ; với Perforce thì tính bằng giây. Không hề đùa.
Những công cụ thú vị mà UE5 dùng, như Horde hay UBA, đều yêu cầu Perforce.
Nhưng Perforce thì dựa vào vị thế trong ngành mà chẳng làm gì. Nó cực kỳ đắt mà cũng chẳng phải không tốn chi phí vận hành host. Bạn phải tự host, và xét về hiệu năng thì tự làm vẫn tốt hơn, nhưng sau lần cài đặt đầu tiên thì việc bảo trì thực sự là cực hình. Có vẻ họ vẫn đang thử gì đó nhưng không có định hướng rõ ràng, và gần như mọi thứ họ làm đều lệch khỏi lẽ thường hoặc nhu cầu người dùng. Sản phẩm cốt lõi thì cứ đổi tên liên tục mà không có cải thiện thực chất.
Đây là một bài học cho thấy phần mềm độc quyền có thể trở thành nhà tù như thế nào. Tôi muốn dùng công cụ review code tốt hơn Swarm, muốn tích hợp SSO mà không cần những hook LUA kỳ quặc gây segfault trên máy tôi, và muốn chạy backend lưu trữ phân tán thay vì phụ thuộc vào SSD khổng lồ và sao lưu journal. Thậm chí giấy phép còn bị khóa với địa chỉ IP của máy chủ chính nên không thể khôi phục từ bản sao lưu.
Đây là một công nghệ bị lãng quên, và nơi điều hành công ty đó chẳng khác gì xác sống.
Tôi không rõ các vấn đề về phân quyền đã được giải quyết chưa, hoặc mô hình lai giữa phân tán/tập trung này — nơi checkout theo từng file tương tác với quy trình làm việc dựa trên branch truyền thống — đã được giải quyết chưa.
Xem FAQ thì thực ra đây không phải là một sản phẩm hoàn toàn mới, mà là thứ giờ mới được công khai mã nguồn mở
Có đoạn giải thích rằng: “Lore, trước đây được gọi là Unreal Revision Control, là hệ thống quản lý phiên bản tích hợp trong UEFN (Unreal Editor for Fortnite), đã được các creator dùng để quản lý phiên bản đảo của họ. Các nhóm nội bộ của Epic cũng đang dần áp dụng nó, và nó đang được triển khai làm kho lưu trữ backend cho pipeline cook của UEFN, thay thế lớp lưu trữ trung gian hiện có để loại bỏ việc truyền tệp trùng lặp và giảm đáng kể thời gian từ khi publish thay đổi đến lúc có thể vào chơi.”
Điều đáng ngạc nhiên là nó dùng Rust chứ không phải Epic C++ hay Verse. Khá tò mò về lý do
Còn lý do là Rust chứ không phải Verse có lẽ đơn giản là vì công việc này không hợp với Verse. Kể cả khi Simon có làm Verse thì cũng vậy. Lý do không phải Haskell mà là Rust có lẽ là vì hiệu năng. DARCS cũng từng phần nào không thể phổ biến rộng vì vấn đề hiệu năng
Hơn nữa còn tự trói mình vào đủ thứ vấn đề và sự chậm chạp của engine. Epic đã từng mắc sai lầm này với Epic Games Launcher. Về cơ bản nó chạy như một instance của engine, và đó là nguồn gốc lớn của nhiều vấn đề
Nếu so Verse với Rust, thì Verse được dùng bên trong trải nghiệm UEFN nhưng vẫn còn rất xa mới đạt trạng thái production. Ngoài ra nó về bản chất bị gắn chặt với UEFN. Bạn cũng không thể tải về một compiler hay REPL độc lập để chạy
Tất nhiên ngoại lệ là nếu họ mã nguồn mở nó vì quyết định ngừng phát triển, nhưng ở đây có vẻ không phải trường hợp đó
Full-surface API là một tính năng mà chưa ai ở đây nhắc tới. Tôi tò mò không biết đó có phải là cách ám chỉ Git vì Git cố tình không cung cấp thư viện có thể link vào hay không. Trước đây tôi đã đọc bài này: https://news.ycombinator.com/item?id=48470604
porcelainđể các chương trình tương tác. Dù không ở dạng có thể link, nó vẫn là một APITiền đề ở đây là Git-LFS không ổn, nên cần xây dựng từ đầu một hệ thống quản lý phiên bản dữ liệu mới bằng Rust. Tôi phần lớn đồng ý với tiền đề này, nhưng cũng đã có khá nhiều hệ thống quản lý phiên bản dữ liệu trưởng thành sẵn có, nội bộ dùng các kỹ thuật tương tự
Pachyderm(Go): https://github.com/pachyderm/pachyderm
XetHub(HuggingFace đã mua lại): https://huggingface.co/blog/xethub-joins-hf
LakeFS(Go): https://github.com/treeverse/lakeFS
Oxen(Rust): https://github.com/Oxen-AI/Oxen
Chắc giờ là thời đại mà nhờ AI, ai cũng có thể vibe coding một hệ thống quản lý phiên bản bằng địa chỉ nội dung, khử trùng lặp theo từng chunk, viết bằng Rust
Nói đùa vậy thôi, Lore trông thực sự rất ấn tượng. Điều thú vị là dù các domain và ngành khác nhau đang gặp những vấn đề rất giống nhau, dường như việc trao đổi ý tưởng lại không nhiều. Trong trường hợp này, cả AI lẫn game đều cần hệ thống lưu trữ để quản lý phiên bản các tệp nhị phân lớn ở quy mô lớn. Có vẻ có rất nhiều cơ hội để chia sẻ ý tưởng, và chính việc hiện tại còn thiếu chia sẻ cũng có thể tạo ra cơ hội
Chỉ riêng khác biệt này thôi cũng có thể dẫn tới việc cần các kiến trúc kho lưu trữ khác nhau
Tôi nghĩ một phần vấn đề là do chính Git và những thỏa hiệp cần có để duy trì kho lưu trữ hybrid. Vì vậy tôi rất mừng khi thấy hệ thống quản lý phiên bản này không dùng Git. xethub cũng đã bắt đầu tung ra phiên bản sản phẩm không dùng Git, nhưng tôi chưa có dịp thử
Tôi cũng đã dùng oxen, ban đầu thấy không tệ, nhưng rồi nhanh chóng gặp các vấn đề kỳ lạ liên quan đến trạng thái repository và không đào sâu debug. Trải qua tất cả các hệ thống này, tôi thấy không cái nào làm mình hài lòng 100%, và rõ ràng Git cho dữ liệu không phải là một bài toán nhỏ nhặt
Tôi nghi ngờ không biết công ty nào sẽ thực sự triển khai hệ thống này trong vòng 2 năm tới
Helix và Perforce đã làm việc này hàng chục năm và vì đây là một phần của hoạt động kinh doanh cốt lõi nên có thể tin cậy. Ta biết họ sẽ còn duy trì sản phẩm này thêm một thời gian dài
Nhưng nếu ngày mai Epic bỏ hẳn dự án này thì hoạt động kinh doanh của họ cũng chẳng hề hấn gì. Thậm chí lấy lại nguồn lực phát triển còn có thể có lợi cho công ty
Nó khá giống câu hỏi vì sao phải tin Cloudflare sẽ tiếp tục đầu tư dài hạn vào EmDash. Cloudflare không quan tâm đến CMS. Mang lại trải nghiệm tốt nhất cho độc giả, tác giả và chủ website không phải là hoạt động kinh doanh của họ. Nó gần như chỉ là một dự án phụ bên lề, hầu như không liên quan tới mảng chính
Trong mảng này từ trước đến nay vẫn luôn có một đối thủ khá ổn là PlasticSCM. Vài năm trước Unity đã mua lại nó, nhưng Unity không phải một nhà quản lý giỏi
Họ đáng ra nên mã nguồn mở nó như Epic đang làm, nhưng thay vào đó lại chọn cách buộc nó phải tự chịu trách nhiệm lời lỗ. Tôi khá tò mò không biết nó đang đóng góp được bao nhiêu vào tài chính của Unity
Ý kiến trên Lobste.rs
Vì họ nói hệ thống này được tối ưu cho các dự án game/giải trí xử lý cả mã nguồn lẫn tài sản nhị phân dung lượng lớn, nên có vẻ cuối cùng cũng có ai đó chán ngấy với thế độc quyền nhiều thập kỷ của Perforce và bắt tay làm thứ gì đó
Lúc mới thấy thì hình như chưa có, nên tôi thắc mắc vì sao giờ lại bị gắn tag vibecoding
Ví dụ, kiểu mô tả như “Mercurial và Sapling tập trung vào lịch sử văn bản còn Lore ưu tiên nhị phân” là sai. Mercurial cũng là một cấu trúc mà các tính năng văn bản được đặt trên mô hình đối tượng nhị phân
Với tư cách là người từng tham gia phát triển Mercurial/Sapling, tôi tin rằng LLM có thể giúp tăng tính chặt chẽ bằng cách chỉ ra các phương án thay thế mà nhóm đã bỏ sót, nhưng tài liệu này khiến tôi thất vọng. Bản thân các quyết định có nhiều điểm mạnh, nhưng tôi ước đây là một tài liệu được viết chặt chẽ hơn
2026-06-17 12:56 (Users)
Story: Epic Games announces Lore version control system
Action: changed tags from "release vcs" to "release vcs vibecoding"
Reason: Automatically changed from user suggestions
Không biết đây có phải là dự án Rust đầu tiên mà Epic Games công khai phát triển không?
Nhìn cả cái này lẫn tin về hệ thống quản lý phiên bản mới nhất của Cursor, có cảm giác dạo này ai cũng muốn làm VCS
Hay chỉ mình tôi mà suy nghĩ đầu tiên là “chẳng phải cái này nên được host trên lore sao?”