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

431–440 of 717 posts

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

#431

Post by minraws »

niek_pas wrote: post #22

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…

If you can't understand atleast 70% of those lines of Git, you really should be using a git web app or something.

Or maybe try jj. Either is better than you using Git's raw cli as someone who doesn't really know or care how it works.

Git cli is very much made with rough edges and is generally expected to be in hands of an advanced user, these days lots of commands have been made simpler and stuff, but git cli is just still very raw.

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

#432

Post by maccard »

pdpi wrote: post #20
gbraad wrote: post #5

What makes lore better or worth considering... when svn and git never failed me...

When you have a game that weighs in at 100GB, only a tiny fraction of that is built from code. The rest of it is binary assets that most VCSs struggle with. What makes this worth considering is the fact that they designed it to handle binary assets.

And if your resulting game is 100GB, the source repo was 4TB.

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

#433

Post by munificent »

akurilin wrote: post #428
munificent wrote: post #414

Earlier quoted context omitted.

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.

I went in the other direction. 8 years at EA and now at Google working on open source.

Everything is so easy when your entire source repo is a paltry few hundred megs and you can build everything from source in a few minutes. It feels like flying.

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

#434

Post by reactordev »

jhatemyjob wrote: post #424
Arainach wrote: post #399

Earlier quoted context omitted.

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…

Is Google a big 3 media/entertainment studio?

While I agree with you, not at Google anymore, I do not consider them the top 3 engine providers that I am referring to in my post. No no, Unreal/Unity/Red/EA/SC it’s all perforce.

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

#435

Post by dijit »

maccard wrote: post #423
dijit wrote: post #384

Earlier quoted context omitted.

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 weir…

I'm actually using helix-authentication-service.

Swarm "works with it" in theory, but in practice I had to patch the loginWithSSO function to shell out to the p4 process to handle auth, because P4PHP doesn't expose ClientSSO at all and it's required for a clean login with keycloak.

EntraID is a different flow that they've probably nailed, from what I hear from other studios.

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

#436

Post by akurilin »

munificent wrote: post #433
akurilin wrote: post #428

Earlier quoted context omitted.

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.

I went in the other direction. 8 years at EA and now at Google working on open source. Everything is so easy when your entire source repo is a paltry few hundred megs and you can build everything from source in a few minutes. It feels like flying.

Very relatable. I still recall when our team at Microsoft, about 20 years ago, had a dedicated "build engineer" who would be given the task to create a new branch for the product. He would disappear for a few days and re-emerge with the announcement that a new branch had been officially created and was ready to be used. Hard to imagine that in git world.

When I went back to Perforce I was reminded of why that was a thing. You're making a full copy of everything. They recently introduced a virtual copy stream, but I remember people advising against using it, for reasons I can no longer remember. It seemed like a potentially sensible approach.

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

#438

Post by akurilin »

munificent wrote: post #433
akurilin wrote: post #428

Earlier quoted context omitted.

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.

I went in the other direction. 8 years at EA and now at Google working on open source. Everything is so easy when your entire source repo is a paltry few hundred megs and you can build everything from source in a few minutes. It feels like flying.

Oh, and thanks for writing Game Programming Patterns. That was a great resource.

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

#439

Post by PunchyHamster »

jmaw wrote: post #245
PunchyHamster wrote: post #199

Earlier quoted context omitted.

> That's not something that you can do in git: it's all or nothing. That is partially incorrect; you can restrict writes via hooks but not reads; you'd need a workaround like submodules

Does `--no-verify` override the restriction via hooks, or are there some kind of server-side hooks that can be used?

no-verify cancels local hooks, remote hooks are unaffected.

Gitolite supports per-diectory/file write access natively, for gitlab you'd probably need to write your own.

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

#440

Post by PaulDavisThe1st »

stackghost wrote: post #188
stevefan1999 wrote: post #85

Earlier 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…

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.

And a few of them think that it is corporate structure and development models that are actually the problem.

I'm just asking questions!

Post reply on HN