Nice, this seems sort of like Git-but-for-giant-monorepos. That has been a gap in the opensource VCS market
Lore – Open source version control system designed for scalability
131–140 of 717 posts
Re: Lore – Open source version control system designed for scalability
#132Just 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…
Git as a data structure is clever, but Git as a CLI is atrocious.
Obligatory: https://git-man-page-generator.lokaltog.net/
Re: Lore – Open source version control system designed for scalability
#133For 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…
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…
I once worked in a git repository that required those kinds of restrictions.
This was within a bank and the code in question was related to enabling Apple Pay from within the banking application. The consequences of that information and code leaking or being seen by anyone who had not signed the NDA were very serious (don't remember the details but it made the lawyers were extremely stressed about it).
Needing to figure out a way to protect those parts of the codebase it was decided in the end that the "easiest" way of doing this was to split the repository in half, with the actual artifact building taking place from the half that had the NDA code. The rest of the application (basically the whole application) was then used as a dependency by it.
Still didn't quite solve the issue, but access to that repository was heavily controlled.
Re: Lore – Open source version control system designed for scalability
#134Just 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…
Git as a data structure is clever, but Git as a CLI is atrocious.
I feel like, everyone near Git has decided, "Well, all abstractions leak - so we might as well stand in the rain like Andy Dufresne when he escaped from Shawshank Prison!"
Re: Lore – Open source version control system designed for scalability
#135For 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…
I wonder how useful this could be as a generalized version control for regular user systems, as a way to rollback, or scrub through history. Presumably if this is designed to work at Epic and Big Game studio scale, it should work at home computer scale
This presumption has destroyed far, far more companies and projects than the opposite assumption (that something built for small will scale to big, then doesn't).
Re: Lore – Open source version control system designed for scalability
#136Just 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…
Objects are your files. Underlying git is a content-addressable filesystem.
The objects are referenced by trees. A tree is just a directory.
The trees are then referenced by commits and/or tags into a DAG with named pointers into various parts of it (which are your branch and tag references):
https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Because it would be terribly in-efficient to have a bunch of loose objects, git periodically groups them together into packs. To save space, the objects are compressed against one another (delta compression) within the packs.
https://git-scm.com/docs/git-pack-objects
https://github.com/git/git/blob/master/Documentation/technic...
When pushing or pulling, the git transfer protocol basically enumerates what objects each side has so that it only needs to transfer the difference. On top of that, it delta compresses the objects on each side that aren't already grouped into packs against each other to save space.
https://github.com/git/git/blob/master/Documentation/technic...
Because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it!
But if you really want to know, it's all documented both in the git book and git documentation directory, both linked above.
(Caveat: I'm working from memory and surely got some detail at least slightly wrong.)
Re: Lore – Open source version control system designed for scalability
#137This is just going to become another way to lock developers into UE. Then they will start charging for licenses, same as Unity did for its versioning feature. It might be open source but that doesn’t stop the commercial use of it being charged for.
It has an MIT License
Re: Lore – Open source version control system designed for scalability
#138Earlier quoted context omitted.
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…
Git submodules aren’t convenient either. For the silo and corporate development use case, just use multiple repositories and make your build tool aware of multiple repositories. It is slightly less painful than submodules.
I feel like submodules could be a lot easier to work with if the git command made it easy to update all submodules in one go based on branch head for the submodule.
Re: Lore – Open source version control system designed for scalability
#139Earlier quoted context omitted.
All Data is Lore. I mean lore is a superset of data. I mean data is lore with a special attribute. I'm not just picking nits here. And this is not cynicism. so there you go.
I'm not the parent, but I suppose it was a joke reference to Star Trek where Data (an android character) discovers he has a brother named Lore [0]. [0] https://en.wikipedia.org/wiki/List_of_minor_Star_Trek:_The_N...
Oh, so that's why JetBrains data thing is called DataLore. TIL
Re: Lore – Open source version control system designed for scalability
#140For 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…
I am building a small asset heavy game. Ran into a similar problem. Built a storage cost efficient tool for exactly this [1].