Engine projects and asset packs
Textures, meshes, audio banks, and level data version through the same verified path as source, so a build is one checkout of one repository.
The model · binary parity
No LFS. No pointers.
No second storage system.
Large binary content takes the same content-addressed, integrity-verified path as source. Not a bolt-on for big files — the same object store, with chunking that makes it practical.
- Chunking
- FastCDC, content-defined
- Addressing
- BLAKE3-256
- Pointer files
- none
- Filters to install
- none
- Verification
- re-hashed on read and on receipt
The LFS tax
What the workaround actually costs.
Git LFS is a reasonable answer to a real constraint. It is also five recurring costs that a team pays for the entire life of the repository.
- A second storage systemLFS is a separate server, a separate quota, a separate backup story, and a separate thing to be down.
- Pointers instead of contentThe repository tracks a text stub. Checkout correctness now depends on smudge and clean filters running on every machine, forever.
- Onboarding failure modesA clone that succeeds and a working copy that is full of pointer files is the most common new-hire support ticket in an asset-heavy repository.
- Migration is one-way and loudRetrofitting LFS rewrites history. Removing it rewrites history again. Both are org-wide events.
- Rules nobody remembersWhich extensions are tracked lives in .gitattributes, and the day someone adds a new asset type without updating it is the day the repository quietly doubles.
How chunking changes the arithmetic
Edit a 400 MB asset; store what actually changed.
Content-defined chunking splits a file at boundaries determined by the bytes themselves, not at fixed offsets. Insert data near the front and the boundaries after it stay where they were, so the unchanged chunks are still the chunks you already have.
revision 1
revision 2
already stored, referenced again new chunks written
Diagram, not a measurement. Actual deduplication depends entirely on the file format and on how the tool that produced it rewrites bytes; a container that reflows its whole payload on save will dedupe poorly no matter what the version control system does.
Who this is for
Repositories where the code is the small part.
Datasets, weights, and evaluation fixtures
Content-defined chunking deduplicates across revisions of large files, and behavioral versioning gives model-driven systems a versioning surface of their own.
Firmware images and board files
Binary artifacts that must be reproducible and attributable get change identity and integrity verification rather than a filename convention.
Source files and rendered output
Design and video sources live beside the code that consumes them instead of in a separate drive with its own naming scheme.
Before you plan a migration, read these two limits
- File locking is partial today. The client and the server arbitrate lock grants, which is what a team needs to coordinate who is editing an unmergeable asset. No push or land path consults a lock store yet, so a lock is a coordination signal rather than a server-side write barrier. The specification records this precisely.
- Scale evidence is open work. The storage model is implemented and tested; published evidence at the declared repository and asset ceilings is part of the remaining Phase 5 assurance work, tracked on the roadmap. Evaluate against your own repository rather than against a number on a marketing page.
The storage format is specified, not just described.
Chunking parameters, object framing, and the verification rules are in the public specification, with a conformance corpus behind them.