Live data from Hacker News

Lore – Open source version control system designed for scalability

lore.org

181–190 of 717 posts

Re: Lore – Open source version control system designed for scalability

#181
post #28

The incredible laggyness of that website does not inspire confidence. Much of the text selection is also broken, and chrome consumes nearly a full core trying to render.. something? Its remarkable that anyone thought this website was fit for release, and it gives off strong slop vibes I also have absolutely zero trust in a product like version control being provided by a for-profit company. It seems like a terrible i…

This is primarily going to be targeted at Unreal Engine users, for whom the source control tooling they use is the smallest of concerns when it comes to being tied to Epic Games.

Re: Lore – Open source version control system designed for scalability

#182

For context, since a lot of people on HN haven't worked on games - this is not intended to compete with Git for general software development. This is a competitor with Perforce for game development. Git is fine for text based files like code, but it's really bad at stuff like textures, 3D models, audio files, and other non-text files that game developers need to collaborate on. For example, one artist might need to o…

Git is certainly not great with binary assets, but calling perforce SOTA ... ouch. If perforce is the best there is out there for large binary asset management, then there is a blue ocean worth of potential improvement for git. Perforce is a piece of crap, a relic of the 20th century that must die in a fiery inferno.

I’ve spent more than a decade working in games and unfortunately perforce is the best out there for a variety of reasons. None of them are good.

Re: Lore – Open source version control system designed for scalability

#183

Just today as I pushed some changes to Github, I was thinking how user-unfriendly Git's UI is: Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 10 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 290 bytes | 290.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (2/2), completed with 2 local obje…

Every place I worked at has a git introduction where all new employees learn about how git works internally. Takes 1h, and all junior devs stops memories random commands and actually start to understand. I highly recommend to you to poking around in the .git directory.

The git support for new employees drops basically to zero.

Re: Lore – Open source version control system designed for scalability

#184

As long as Epic Games is anti Linux I will never use any Epic Games product. Count on it.

They are so anti linux that they ship a linux version of Lore.

Well, that's easy for a Rust binary. But they don't put any effort into having a great UX for Linux devs with Unreal Engine, for example. It barely works on Linux and is almost impossible to run under Wayland.

Re: Lore – Open source version control system designed for scalability

#185

Earlier quoted context omitted.

This is a very long document that says nothing about chunking at first skim. If chunking is actually wrong, then just explain why, here. Wasting space is not actually a problem if it’s optimized for other purposes instead.

When it comes to large assets, wasting large chunks of space is a problem. If your chunks are 64 kib average (from the Lore document), but changes only average 1 kib (which could be a high estimate), then you will still run out of space 64 times faster and need to read 64 times more data off of the disk for certain operations. It also makes diffing hard, as well as diff viewing.

What do you do instead of chunking your snapshots? Storing diffs is usually the other approach.

Re: Lore – Open source version control system designed for scalability

#186
The idea sounds good, even if Epic's recent track record of tools is not inspiring. But the commit messages etc. are very clearly products of vibe-coding. And version control is not the situation where "works 97% of the time" is a good-enough bar.

Passing for now.

Re: Lore – Open source version control system designed for scalability

#187

The idea sounds good, even if Epic's recent track record of tools is not inspiring. But the commit messages etc. are very clearly products of vibe-coding. And version control is not the situation where "works 97% of the time" is a good-enough bar. Passing for now.

About the recent track record, is there some technical problem or just drama with Unreal Engine that I'm not aware of? (I already have the same opinion about using AI-coded VCS.)

Re: Lore – Open source version control system designed for scalability

#188

Earlier quoted context omitted.

Something else that git isn't good at: permissions. In gamedev, you might have proprietary work that you want to restrict to certain users. In P4, you can add restrictions to certain directories for only those who have signed the required NDAs. That's not something that you can do in git: it's all or nothing. Maybe you can set something up with submodules, but that's going to upend your repository if you hadn't plann…

That's by design of git, you can't forget that git is first developed for a bazaar model of information flow, especially with a big decentrailized project like the Linux Kernel, not the silo and isolated corporate NDA and closed model you described. Git prefers open information and discourages information closures and segregation of information by placing restrictions exactly like this. Git enthusiast would often tel…

I think everyone knows that this is a consequence of git's design. Nobody's disputing that.

Unfortunately there are many people who think git is a panacea and is suitable for all version control tasks of anything.

Re: Lore – Open source version control system designed for scalability

#189

Earlier quoted context omitted.

Git does great with text files, but game development contains a lot of binary assets (textures, videos, 3d models) and correspondingly huge repos. git-lfs tries to patch around that, but that makes a complex tool that creatives struggle to understand even more complex. Perforce is a pretty popular solution, and was used by Epic in the past

Is there no git trick to turn off version control on non-text files but still store them? How does Lore handle them better?

You still want version control, and locking so that two artists don't concurrently edit the same asset.

Re: Lore – Open source version control system designed for scalability

#190

For context, since a lot of people on HN haven't worked on games - this is not intended to compete with Git for general software development. This is a competitor with Perforce for game development. Git is fine for text based files like code, but it's really bad at stuff like textures, 3D models, audio files, and other non-text files that game developers need to collaborate on. For example, one artist might need to o…

A significant part of my job, unfortunately, is helping people fix their workspaces when Perforce (p4) goes bad, or creating guardrails and wrappers to stop Perforce doing bad things.

In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace.

For example:

  - p4 tracks file metadata of client workspaces on the server (sync'ed locally, opened for edit, file revision, etc) and uses this as the basis to avoid doing unneeded work.  If this becomes desync'ed, a reconcile or force sync must be used.  A reconcile can take hours, potentially days; it tries do detect file moves by default, so likely at least O(c^n) for some c>1. I have never personally seen a default reconcile operation _complete_ over any modestly large game code base, and in practice, people accumulate a litany of workarounds and scripts to fix this for themselves.

  - Scripting p4 is a nightmare. Documentation is poor, schemas do not exist, and all the language-specific libraries are just thin wrappers over its C++ API.

  - By default, p4 "helps" you with text files by "correcting" line endings on sync or even converting between encodings. This works until you have a mixed-OS environment, and discover a part of the pipechain that _must_ have a certain style.  There are various levers to pull to make this better, but I've yet to find something fool proof.

  - By default, p4 keeps flies read-only, only unlocking them when explicitly marked as being edited.  This means, to avoid having to do this manually, every tool you use needs to be p4-aware.  Or, you can turn this off, and choose to contend reconcile instead. (See above)

  - Branching a modest game project, with, say, Unreal source code, can take hours.  And this is the quick version where you ask the server to simply create new metadata, with no file transfer to a client.

  - p4 is licensed by the user-account. Every user entity in p4 not intended exclusively for performing backups and maintenance operations counts toward this, including users required to integrate with other services.  Plus, often times, these integration users must have admin access to be useful. The security posture is horrific.
Post reply on HN