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

621–630 of 717 posts

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

#621

Post by lentil_soup »

toobulkeh wrote: post #583
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…

Why do you need to lock anything? To prevent someone else from working on it? To prevent duplicative work? That sounds like a management/coordination issue. Not a VCS issue. So you have version A and version B. Why are 2 artists working on the same asset without coordination? Do they not use task tracking or project management? Even if that’s ignored, then one person’s work gets wasted. That happens all the time in t…

Because it's not so cleanly cut. Editing a level might touch several files without you realising, you might move a mesh file which causes 100s of references to update across 100s of files.

For example, you want several people collaborating on a level. Say a level designer, an artist, a lighting person, audio. Usually you split this into several files to allow for the collab but you're bound to hit moments where you need to edit across the board. The level designer moves an area which causes the light, audio, meshes to move. If you don't have a way of knowing someone else is working on those files you're going to step on a lot of toes.

Whether this should live separately from source control is a fair question, but it's just a simple place for it as it's tied directly to the files.

Also, the outcome of a mistake is quite high, it could mean a whole day or two (a week?) of wasted work because you didn't realise someone was also editing the same file.

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

#622

Post by necovek »

MoonWalk wrote: post #486
isodev wrote: post #430

Earlier quoted context omitted.

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.

No idea what this is referring to...

Many countries in the world have local systems for quick, direct bank transfers encoded with QR codes to be used by local payment systems or local banking apps.

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

#623

Post by necovek »

zer00eyz wrote: post #225
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?

> security by obscurity thing... What am I missing here? You are looking at the problem from the wrong direction. If you build a honeypot, to trap hackers, does it behove you to explain what the bait is, and how the trap works? Know your customer, fraud detection heuristics, finger prints, behavioral triggers are all areas where banks, and financial institutions need to keep the sauce secret. Telling the other party…

Alternatively, you can also just try not to have security issues, and resolve them with urgency when they do pop up.

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

#624

Post by Juliate »

I understand the website doesn't address users first, but it really feels like a missed opportunity to show a typical, simple use case in the front page (as in, "as a user, what's in it for me?").

A quickstart link is buried in there, and that's good, but the value of the product is multi-faceted and doesn't address data architecture only.

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

#625

Post by maccard »

dijit wrote: post #599
maccard wrote: post #478

Earlier quoted context omitted.

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?)

Sorry - I didn’t intend to be vague! Entra, yep.

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

#626

Post by maccard »

bc1000003 wrote: post #473
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…

Confirmed. Perforce is (was?) the industry standard for most larger game teams. If you've been in the business for any length of time you're probably pretty familiar with it and all of its many warts. But Perforce does get the job done and it's reliable and stable. However combining some of the flexibility and workflows of git with the ability to deal more efficiently and effectively with large asset files is somethi…

> Perforce does get the job done and it's reliable and stable.

Well… perforce does get the job done, but it does need a lot of hand holding from an admin (and you need someone who knows p4 server if you’re using it). It’s also stable in the sense of “it has exactly the same feature set as it did 15 years ago, and branches (streams) are considered modern”.

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

#627

Post by maccard »

tikotus wrote: post #611
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…

I like putting it like this: VCS can be centralized or decentralized, and it can version per file or per commit. For games you want centralized per file versioning, like Perforce. Git is decentralized per commit versioning.

I mostly agree. I think for games you want per commit versioning 95% of the time. You don’t _really want developers building with cherry picked old revisions etc, but you don’t want an artist to have to pull down the 8TB of new art content that was submitted in the last 48 hours to update a texture.. the only way to do that is per file versioning!

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

#628

Post by mariusor »

dijit wrote: post #415
mariusor wrote: post #388

Earlier quoted context omitted.

Your straw man artist should use any of the nice frontends that work on top of git and hide its verbosity.

Yes, then it breaks because you gave your artist an SSH link to clone and LFS requires a HTTPS auth token and exits with terse errors. Or, you need to lock your files and git doesn't really support that. To be fair, your hypothetical is true: UE5 supports Git as a backend, you don't need to run git commands (most of the time), but in practice even in the best circumstances: Git for game dev is brittle, slow, and extr…

> Git for game dev is brittle,

You're basically reinforcing my point which was that the artist argument is a straw man, and companies that need artists to interact with version control will most likely use something else than git.

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

#629

Post by schaefer »

sasham wrote: post #441

The issues they want to address are already solved in Diversion ( https://diversion.dev ). Granted it's not open source yet, but that isn't usually a priority for game/entertainment studios - having a complete platform is. After tearing it apart for 2 hours - it seems like a solid beginning, but definitely not a fully-functioning product (especially on Mac, I hope it works better on Linux/Windows). Disclaimer - I'm o…

Pricing for on-premise deployment is “talk to us”.

No thank you.

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

#630

Post by maccard »

retroflexzy wrote: post #190
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…

A significant part of my job, unfortunately, is helping people fix their workspaces when Perforce (p4) goes bad, or creating guardrails and wrappers to stop Perforce doing bad things. In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace. For example: - p4 trac…

A quick reply;

> p4 tracks file metadata of client workspaces on the server

Honestly, using P4 necessitates a plugin for $EDITOR of choice. The jetbrains IDEs do full on integration, but I managed a decade with an addon that just ran "p4 add/edit" on any save.

> Scripting p4 is a nightmare

Agreed, but so is git, or plastic. My experience has been using the CLI with -Ztag is the way.

> By default, p4 "helps" you with text files by "correcting" line endings on sync or even converting between encodings

This is a nightmare, and definitely one of P4's worst traits. Everywhere I've worked we have a presubmit trigger, to catch this.

> By default, p4 keeps flies read-only, only unlocking them when explicitly marked as being edited.

See point 1, but honestly you go very very far with just p4 edit a whole folder.

> Branching a modest game project, with, say, Unreal source code, can take hours. And this is the quick version where you ask the server to simply create new metadata, with no file transfer to a client.

A new stream including submission at my current job is about 20 minutes. Even at $BIG_CORP with 800 people working on a project, a branch didn't take hours. (Assumning by branch you mean streams. If it's a branch I have no idea, we don't use them)

> p4 is licensed by the user-account

P4's licensing is predatory. It's very much "talk to us", but you'll find out that "talk to us" pricing is exactly the same for absolutely everyone. If you're really lucky, and get someone who is feeling generous, they might give you 1-2 extra automation seats. Given P4's security model is so old, I don't hate shared credentials for this. A bit like IAM roles, nobody should really have access to the credentials even if they were scoped appropriately.

Post reply on HN