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

661–670 of 717 posts

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

#661

Post by jayd16 »

dijit wrote: post #600
jayd16 wrote: post #587

Earlier quoted context omitted.

UBA mostly doesn't need Perforce and Horde isn't as good as the GitHub, gitlab etc. UGS (the tool that pulls down the latest engine version for artist) is pretty perforce centric.

Wasn't aware that Gitlab could do distributed compilation. Horde configurations can only live locally or in Perforce: https://dev.epicgames.com/documentation/unreal-engine/horde-... Horde only supports Perforce today: https://dev.epicgames.com/documentation/unreal-engine/horde-... UBA and Horde go together pretty well- in fact I've never seen a distributed-UBA deployment without a horde one (SN-DBS, Fastbuild or if y…

I meant that, as a web accessible build and review tool, Horde is not as good as the rest of the big players. You would still use gitlab et al to run your UAT script and that would do whatever distributed build you want.

I agree that it might not be feasible advice to try to force of of these other SAASed into the mix. It's just that Horde lacks a lot of niceties that the greater tech community has.

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

#662

Post by maccard »

59nadir wrote: post #633
PaulDavisThe1st wrote: post #580

Earlier quoted context omitted.

the fact that 10k tutorials exist says way more about the human urge to write, document, and share information than git itself. the 10k number is also a made up statistic. It might be 2k, it might be 20k. i use git daily and often fairly intensively, and i've read perhaps 5-10 tutorials, so the idea that "git requires 10k tutorials" just doesn't make any sense. if anything, the fact that something with good search-fu…

Honestly, when our backend team merged into one that was using Perforce for the backend learning how to use Perforce wasn't realistically even a blip on the radar of what to get used to. I was against it at the time for what we were doing but with the benefit of hindsight I can say that I prefer something like Perforce if someone can manage it for me, or it's a set-and-forget type situation; I don't personally have a…

> Honestly, when our backend team merged into one that was using Perforce for the backend learning how to use Perforce wasn't realistically even a blip on the radar of what to get used to.

I think a lot of what people are assuming here is that because git has such a steep learning curve, P4 does too. You can literally ignore all of the concepts that P4 has and still muddle your way into getting things updated.

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

#664

Post by chadgpt3 »

wredcoll wrote: post #316
Aurornis wrote: post #307

Earlier quoted context omitted.

There are real problems, but Jonathan Blow doesn't limit his criticism to those problems. He just indiscriminately criticizes everything. He's turned into the type of critic that is a broken clock that happens to right twice a day. His criticism isn't limited to AAA game studies. He's a vaccine skeptic and is pretty heavy into far-right influencer garbage. All very surprising if you only know him from his games. This…

Anyone still following him after that needs to fundamentally reevaluate some life decisions.

Maybe he's right on gamedev and wrong on some other things

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

#665

Post by VikingCoder »

gavinhoward wrote: post #480
VikingCoder wrote: post #298

Earlier quoted context omitted.

I tried to give that section of the doc a fair read. Looks like operational transforms to me. The doc claims it's the first with this technique. A 30 second search reminded me of Darcs, and taught me about Pijul, and Weave. And yes, Google Docs storage works the same way - there are probably papers documenting how efficient Google Docs storage is, but it's not wrapped up in a full VCS that folks can use. The example…

> Looks like operational transforms to me. Sort of. I add provenance, which helps properly identify collisions, and require a well-defined order by stacking [1] changelists. > The doc claims it's the first with this technique. More like the first with the particular angle on the technique. I specifically mention patch theory as another side of the same coin. > A 30 second search reminded me of Darcs, and taught me ab…

Your argument was essentially that you kick chunking's ass.

I look forward to the benchmarks, but am highly skeptical.

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

#667

Post by Marsymars »

fc417fc802 wrote: post #617
Marsymars wrote: post #299

Earlier quoted context omitted.

> One thing I don't like about Git LFS is that there is no way to delete very old history. It's the 'git spirit' to not allow deleting history, but in the context of LFS it sounds horrible. Especially if you use Github. At my dayjob we used Git LFS for a bit, but foud it unworkably clunky - we eventually found it easier to just make a separate "LFS" repository and add it as a submodule to the main monorepo. Now we ca…

> Now we can rewrite the history of the LFS repo on an as-needed basis. With the giant caveat that doing this effectively breaks the history of the parent project. TBF that's not really any different than rewriting history and later discovering that an old version of a lockfile no longer works but I still think it's worth mentioning.

Yeah, I can't edit my first post, but should note that if you don't want to rewrite history of the submodule, it also at least lets you consistently do shallow clones of the submodule - various git-related CI/CD operations on the main repo won't work with shallow clones, so it's a pain if you have to pull in a million old versions of binary dependencies just to run gitversion.

As far as rewriting the history of the submodule goes... that's really something we're okay with - for us, the alternative to the git submobdule was just an SMB share - indefinitely keeping old binary dependencies isn't something we want to do.

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

#669

Post by justinhj »

thsbrown wrote: post #581
justinhj wrote: post #358

One of the reasons I left the game industry, or at least one the benefits of leaving was to not have to use Perforce any longer. Albeit a necessary evil, hopefully lore is better. I always wondered if a combination of a database to index assets and asset versions with the data being in S3 style storage would be better for game assets; code can be in Git. Then your workflows are easy to build on top of that.

Isn't this what git lfs is effectively?

The main difference in my proposal is separating git completely from asset management and replacing it with a flexible, scalable system built for that purpose

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

#670

Post by oblio »

Hendrikto wrote: post #647
jayd16 wrote: post #222

Earlier quoted context omitted.

P4 is more "industry standard" than "state of the art"... But it does handle large files and partial checkouts without feeling bolted on.

Git has had native partial checkout for ages.

> partial checkouts without feeling bolted on.

OP said this, maybe Perforce's partial checkouts are just better than Git's.

Post reply on HN