Lore – Open source version control system designed for scalability • Hacker News Board

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

#591

Post by BatmanAoD » Thu, Jun 18, 2026, 4:33 AM UTC

y1n0 wrote: post #584

lkjdsklf wrote: post #571

Earlier quoted context omitted.

Jj is weird. In general it’s a better ui and model than git, but there’s a few common operations that are just dumb. It also recreates a lot of the stupidity of mercurial (which makes sense) The fact that everyone needs the same stupid “tug” alias because jj wants to use “bookmarks” instead of just named branches is just classic silly shit. We’ve had named branches for 40 years. Everyone who has vcs experience knows…

That's built in now, for what it's worth.

You mean `jj advance bookmarks`? It still seems like a pain to not just have it happen automatically on `commit`. (I use the "experimental" auto-advance-bookmarks feature, but it's got a lot of papercuts.)

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

#592

Post by gmueckl » Thu, Jun 18, 2026, 4:37 AM UTC

PaulDavisThe1st wrote: post #489

FanaHOVA wrote: post #449

Earlier quoted context omitted.

Solving merge conflicts on text-based files is infinitely easier than binary-based. It's not a useful comparison.

What does that have to with your VCS being integrated with your IDE? Isn't resolving merge conflicts in binary files going to entirely a function of the IDE and not the VCS ? What am I missing?

Merge conflicts on binary files are typically unresolvable in practice because the editing tools don't normally have the ability to compare files. This leads to one of the two divergent sets of changes getting lost. That's why great VCSes allow file locking: locks are a communication tool between team members to avoid losing work.

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

#593

Post by fhdbeid » Thu, Jun 18, 2026, 4:45 AM UTC

Wowfunhappy wrote: post #550

DetroitThrow wrote: post #547

Earlier quoted context omitted.

Spam from a bot! I think there are automatic filters to prevent this so I'm surprised it wasn't banned before we all had to see it, maybe @dang can comment on how quickly these are supposed to be resolved

Thanks, I actually thought this had to do with Epic Games somehow!

[dead]

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

#594

Post by adastra22 » Thu, Jun 18, 2026, 4:48 AM UTC

ibejoeb wrote: post #356

jbverschoor wrote: post #263

Too bad it does not support fully local/detached (without server). It would be nice to be able to run it similar to a local repo without remote

The unique feature is universal locks (like cvs checkout) for opaque binaries like art, which requires universal state, so this seems to be orthogonal to the goal.

Why?

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

#595

Post by gmueckl » Thu, Jun 18, 2026, 4:57 AM UTC

LugosFergus wrote: post #48

chadgpt3 wrote: post #41

Earlier quoted context omitted.

Jonathan Blow found it convenient to represent all assets in a large number of text files, to enable merging. For instance he'd have one text file per entity on a map. The game and editor could read either this or the compiled binary version.

You really can't merge binary data, such as textures, meshes, audio, etc. It doesn't matter if you base64 encode the data and stuff it in a text file: it's a jumble of data (assuming this is the implication of what Blow did).

Tools that support non-destructive editing workflows could in theory provide limited diff and merge capabilities on their internal graphs pf non-destructive operations. E.g. Photoshop could in theory merge two files where unrelated layers have changed. But nobody is actually implementing this because it would be lots and lots of work.

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

#596

Post by calebm » Thu, Jun 18, 2026, 4:59 AM UTC

I am a math artist (https://gods.art), and I’ve had trouble with hit because I want to be able to check in images and similar artifacts, but got is clearly not designed for it. Very excited to try this!

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

#597

Post by gmueckl » Thu, Jun 18, 2026, 5:11 AM UTC

bentt wrote: post #261

There was and still is a very nice competitor in this space called PlasticSCM. They were bought by Unity a few years ago. Unity has not been a good steward. They should have done what Epic is doing and open sourced it. But instead they chose to give it P&L responsibility. Curious what it's contributing to their financials.

Seeing PlasticSCM wither like this is sad. I had rather high hopes for this system to successfully compete with Perforce, but history worked out differently.

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

#598

Post by dijit » Thu, Jun 18, 2026, 5:22 AM UTC

s1ncere wrote: post #561

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…

This a lot of very old and out of date information and opinions, respectfully disagree

How out of date?

I migrated from Git (AzureDevops) to Perforce in February this year, this was true then.

Horde is approx 8 months in the public eye.

Respectfully, what?

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

#599

Post by dijit » Thu, Jun 18, 2026, 5:22 AM UTC

maccard wrote: post #478

dijit wrote: post #435

Earlier quoted context omitted.

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.

As I said in my last reply - none of that surprises me. Our provider worked out of the box, fwiw.

interesting, is it rude to ask what provider you use? (if it's not EntraID?)

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

#600

Post by dijit » Thu, Jun 18, 2026, 5:27 AM UTC

jayd16 wrote: post #587

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…

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 you're wealthy: incredibuild are much more popular), but adaptive unity builds check for a read-only flag; which is how Perforce treats checked-out/changed files but not git.