Guessing Tim Sweeney is a Star Trek fan?
Lore – Open source version control system designed for scalability
321–330 of 717 posts
Re: Lore – Open source version control system designed for scalability
#322Earlier quoted context omitted.
Isn't this just the same thing as `git mv`?
They're actually saying it's better than `git mv`, because it actually records the move, unlike Git.
I think they're saying the opposite. It won't detect a filesystem-level move. It will simply record a delete and create without the relationship. Git does record the rename, though:
~/work/tmp/repo git init . --quiet
~/work/tmp/repo master echo 'foo' > foo.txt
~/work/tmp/repo master? git add .
~/work/tmp/repo master+ git commit -m "create" --quiet
~/work/tmp/repo master mv foo.txt bar.txt # no `git mv`
~/work/tmp/repo master*? git add .
~/work/tmp/repo master+ git status --porcelain
R foo.txt -> bar.txt
~/work/tmp/repo master+ git commit -m "rename"
[master a06c680] rename
1 file changed, 0 insertions(+), 0 deletions(-)
rename foo.txt => bar.txt (100%)
Maybe lore does the same, but the docs imply that it doesn't.
--
To summarize: lore will record relationship metadata only when performed with `lore stage move `, so you will have to intervene if your other tooling moves files.
Re: Lore – Open source version control system designed for scalability
#323Earlier quoted context omitted.
The way I usually solve this is by using git submodules.
AFAIK the issue with using submodules is you still need the rights to pull the other source repo. However, you can use submodules or LFS to pull a specific build artifact from a build artifact repo or source instead of the source repo, which provides a neat way to manage the dep without fattening the main repo and allows the source repo to be kept separate and high security. I'd certainly do this before changing RCS/…
You can set up submodules to not pull the other source repo by default tho
Re: Lore – Open source version control system designed for scalability
#324Just 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 ob…
Do you know what a rhetorical situation is? Do you understand that the parent was not actually seeking answers to these questions, but was using the questions themselves to make a point about the Git UI?
Re: Lore – Open source version control system designed for scalability
#325For 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…
Has nothing to do with Perforce being the Oracle of VCS because it’s baked into the big 3? Riiiight.
Perforce is more the IBM of VCS. Older than it has any right to be. Has quiet "dark matter" support contracts with a lot of companies you wouldn't think need Perforce, but they've been using it for long enough they aren't going to change. Some of those support contracts included complicated forks and homegrown solutions that are so sunk cost as to be nearly black holes (and sometimes so different from baseline Perforce as to be evolutionarily different species).
Re: Lore – Open source version control system designed for scalability
#326For 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…
That always seemed crazy to me about git. Permissions are a pretty basic enterprise offering.
Does Gitlab do better with this?
Re: Lore – Open source version control system designed for scalability
#327Earlier quoted context omitted.
As others have said, it's Apple and they do not take kindly to other people leaking their technology/announcements ahead of time. See also: the time that ATI's CEO told his employees that their chips would be powering Apple's to-be-announced hardware a few days before the announcement. Steve Jobs responded by pulling all of ATI's hardware from its demo units at the announcement, not mentioning ATI at all, cancelling…
> and never partnering with ATI again. Except of course shipping ATI hardware for years afterwards, then also using nvidia, then dropping nvidia and only using ATI/AMD until transitioning to Apple Silicon.
Also Steve Jobs Apple is probably much different than today's Apple.
Re: Lore – Open source version control system designed for scalability
#328Earlier 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…
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 fig…
Not sure what it is on the Apple Pay side but with FPLS it is/was basically your keys would be revoked and you would be ineligible to ever get new ones… so no content that requires DRM on iOS for the life of the company.
Re: Lore – Open source version control system designed for scalability
#329Has anybody used Lore (or the older Epic internal version they were using on Fortnite) for also managing code?
As someone who came from VFX I always found the way Git works to feel very limiting. I feel like it was one of those things that was just so much better than the previous option (SVN, etc) that it blewup without actually being ideal.
Re: Lore – Open source version control system designed for scalability
#330Turns out it is not really new but only open sourced it now. From the FQA. >Lore, formerly called Unreal Revision Control, is the built-in version control system for UEFN (Unreal Editor for Fortnite), where creators have been using it to version their islands. It is also seeing progressive adoption by internal Epic teams, and is being implemented as the backing store for UEFN’s cook pipeline, where it replaces tradit…
It's a separate tool from Unreal Engine, so you don't need to constrain yourself to its conventions. You're also not going to use UObjects, its reflection layer, serialization, and all that other stuff for a tool that's strictly for version control. Plus you're going to tie yourself to all the issues and slowness of the engine. Epic made this mistake with the Epic Games Launcher, which is essentially an instance of the engine running, and a huge source of various issues.
As for Verse vs Rust, Verse is used in UEFN experiences, but it is _far_ from any kind of production state. It's also intrinsically tied to UEFN. It's not like you can download a standalone compiler or REPL for Verse.