Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lore – Open source version control system designed for scalability

lore.org

Post reply on HN
Print view View original

421–430 of 717 posts

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

#421

Post by dimatura »

penciltwirler wrote: post #88

The premise is that Git-LFS sucks, so we need to build a new data versioning system (in Rust, from scratch). While I mostly agree with this premise, but there are already lots of existing (mature) data versioning systems with the same tricks under the hood: - Pachyderm (Go): https://github.com/pachyderm/pachyderm - XetHub (acquired by HuggingFace): https://huggingface.co/blog/xethub-joins-hf - LakeFS (Go): https://gi…

There's also git-annex and iterative DVC. I used xethub a fair bit (was the earliest user, in fact) and I thought it was better than git annex, git-lfs and DVC, but still did start to struggle past a certain size. I think part of the problem was just git itself, and the compromises required to have a hybrid repo. So I'm happy to see this vcs doesn't use it. xethub did start shipping a version of their product that did not use git but I didn't get the chance to try it. I've also tried oxen and it wasn't bad at first, but soon ran into some weird issues with the repo state which I didn't really try to debug. It is clear to me at this point, given my experience with all these systems -- none of which I've been 100% happy with -- that "git for data" is a nontrivial problem.

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

#423

Post by maccard »

dijit wrote: post #384
akurilin wrote: post #254

We had to use Perforce (Helix Core Cloud) at my last game studio, and it is the de facto industry standard that most of your creative staff is already familiar with. The programmers don't love it, but they don't rule the roost in games. It's also the safe, verified default for working with Unreal Engine 5. It does show its years though. We were one of the first users of the Perforce cloud offering, as we were small a…

ditto; and UE5 on anything that isn't perforce is a lesson in pain. I just took over a team that was using Git, and yes, I know it's everyones favourite VCS but for Games it's just about the worst thing available. I could measure art reviews with git in hours, now with perforce its seconds. I wish I was joking. All the interesting tools that UE5 uses (Horde/UBA for a clean example) will require perforce. but, Perforc…

I completely agree with every single point you've said here. Running a P4 server is an exercise in self torture, but it's the only option with UE5.

> I wish I could use a better code review tool than Swarm.

With one caveat. I think swarm is a great tool. It could do with being easier to configure, but as a code review tool it's simple, straightforward and gets the job done.

> I wish I could integrate SSO without weird LUA hooks which cause segfaults on my machine (enough of them causing a perforce deadlock).

this is about the only thing that Perforce has actually managed to do in the last... 5 years? [0] It's also woefully awkward to set up and operate, as is everything P4. But it does work.

[0] https://help.perforce.com/helix-core/integrations-plugins/he...

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

#424

Post by jhatemyjob »

Arainach wrote: post #399
jhatemyjob wrote: post #280

Earlier quoted context omitted.

It's not even baked into Google anymore.

Technically correct, but Piper is API-compatible with Perforce, so while there's presumably no license fee it's still strongly there in spirit. https://graphite.com/blog/google-perforce-to-piper-migration

It's hardly the same thing at this point. For instance you could say Nginx is API-compatible with Apache, and yes that is correct (Maybe? Let's not split hairs here). But to go as far as saying Apache is state of the art and link to Apache's homepage (like throw2ih020 did) is just like.... no.

I think you think I'm trying to correct/one-up reactordev. I'm not. I agree with him. He's pointing out throw2ih020 is being ridiculous, and I'm pointing out that it's even more ridiculous because it's less than 3.

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

#425

Post by maccard »

ibejoeb wrote: post #382
IshKebab wrote: post #373

Earlier quoted context omitted.

> Git knows that the file was renamed even without using git to do the rename. No it doesn't. Git knows that file A was deleted and file B was created, and if they have the same content then it will guess that it was a rename. But it's a heuristic that doesn't always work. E.g. I think it doesn't try to guess for large diffs, and it doesn't work if you modify the file in the same commit.

Right, if you rename a file and then change its content without committing it, it doesn't know. Clearly that's bad practice in a multi-user setting because you're going to break all subsequent merges. However, if you just move or rename a file, git does recognize that, and it doesn't require any manually annotation. Lore needs you to tell it that you're moving or renaming. It's not the end of the world, but it's a re…

> Lore needs you to tell it that you're moving or renaming. It's not the end of the world, but it's a real pain if other tools are operating on the file. You will need to go back and manually annotate those operations if you want it to preserve the relationships.

Lore is clearly influence by 30 years of epic using perforce, and this is how P4 works.

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

#426

Post by minraws »

throw0101c wrote: post #342
throw2ih020 wrote: post #24

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 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. How well does Mercurial work in this situation (or even Subversion, given that Perforce is non-distributed like SVN)?

Mercurial is a bit better, but not by much it had slightly better large file support historically but I wouldn't recommend it.

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

#427

Post by hparadiz »

ibejoeb wrote: post #397
hparadiz wrote: post #393

Earlier quoted context omitted.

I don't have a Windows install anymore and won't set it up just for one game. Furthermore Epic Games has a history of acquiring studios and them crippling Linux support on games that were already purchased. I have a long list of games that I happily play on Linux with no issues.

Didn't know that about Epic. Fair point.

The way games on Linux work today is most are compiled for Windows. There are a few exceptions like Civ will in many cases provide a fully Linux native build. But even in that case on Linux you can choose whether to run the native or the Windows version.

When you download a Windows game on Steam you will go into the Settings and select "Compatibility Layer" and there you will find several versions of Proton. Proton https://github.com/ValveSoftware/Proton is a pre-configured wine bundled with windows DLLs and Linux .so library files. This makes Proton Immutable for any given major version. Meaning you can run Proton 2.x for your game if that's what fits your situation. It's always there if you need it for your specific games. Steam launches this in a container. It is not emulated. It is a fully native implementation of the API that in many cases achieves superior performance.

This is why you will sometimes see the joke that the most compatible API for Linux is actually the w32 API.

This API is now at the point where pretty much everything works unless you cripple it on purpose. And that's what Epic Games is doing here. There's no technical reason for this. It's a business decision that doesn't even make sense because frankly I could vibe code them a linux native game client that launches their games properly on linux in a few days.

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

#428

Post by akurilin »

munificent wrote: post #414
akurilin wrote: post #254

We had to use Perforce (Helix Core Cloud) at my last game studio, and it is the de facto industry standard that most of your creative staff is already familiar with. The programmers don't love it, but they don't rule the roost in games. It's also the safe, verified default for working with Unreal Engine 5. It does show its years though. We were one of the first users of the Perforce cloud offering, as we were small a…

I really like your article. It does a good job of explaining not just the technical differences but the way those affect the surrounding development culture.

Thank you! It was a bit of culture shock for me when I first experienced it, coming from the world of business software, and I figured others would find it equally fascinating to learn more about.

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

#429

Post by akurilin »

dijit wrote: post #384
akurilin wrote: post #254

We had to use Perforce (Helix Core Cloud) at my last game studio, and it is the de facto industry standard that most of your creative staff is already familiar with. The programmers don't love it, but they don't rule the roost in games. It's also the safe, verified default for working with Unreal Engine 5. It does show its years though. We were one of the first users of the Perforce cloud offering, as we were small a…

ditto; and UE5 on anything that isn't perforce is a lesson in pain. I just took over a team that was using Git, and yes, I know it's everyones favourite VCS but for Games it's just about the worst thing available. I could measure art reviews with git in hours, now with perforce its seconds. I wish I was joking. All the interesting tools that UE5 uses (Horde/UBA for a clean example) will require perforce. but, Perforc…

Couldn't agree more. I wonder why the company stalled as much as it did. To be fair they've been around for three decades, maybe it's just hard to keep momentum for that long, especially if you're in a dominant position with no competition coming after you.

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

#430

Post by isodev »

danudey wrote: post #195
SoftTalker wrote: post #160

Earlier quoted context omitted.

Strikes me as bizarre that payment code would be sensitive, unless it's a security by obscurity thing (which would also be concerning). Keys, secrets, etc. yes. But code? What am I missing here?

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…

It’s funny how exciting Apple Pay was when introduced, only Apple pulled the lock-everyone-in card and now we’re all using QRcodes.
Post reply on HN