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

411–420 of 717 posts

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

#411

Post by HWR_14 »

SoftTalker wrote: post #160
MrDresden wrote: post #133

Earlier quoted context omitted.

I once worked in a git repository that required those kinds of restrictions. This was within a bank and the code in question was related to enabling Apple Pay from within the banking application. The consequences of that information and code leaking or being seen by anyone who had not signed the NDA were very serious (don't remember the details but it made the lawyers were extremely stressed about it). Needing to fig…

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?

The code revealed the existence of Apple Pay, which had not been publicly confirmed.

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

#412

Post by abustamam »

dansmith1919 wrote: post #376
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…

This has bothered me ever since I was using git for the first time: what do you mean I have to 'add' and 'commit' and then 'push'? I just want to save my stuff, this is SO many steps.

When I was getting started with programming I often forgot to do one of those steps and often ended up losing my work because I was working from a library computer or something.

When I got more experience I finally understood why it is like that, and it makes sense now, but its still a lot of steps for someone learning to remember.

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

#413

Post by abustamam »

yjftsjthsd-h wrote: post #405
dansmith1919 wrote: post #376

Earlier quoted context omitted.

This has bothered me ever since I was using git for the first time: what do you mean I have to 'add' and 'commit' and then 'push'? I just want to save my stuff, this is SO many steps.

You don't have to do add as a separate step unless you're adding it to the repo for the first time. You can (and I do) just `git commit file1 dir2` or whatever. I don't conceptually think commit+push should be combined; committing a version is separate from pushing it to a remote.

TIL! Thanks

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

#414

Post by munificent »

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.

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

#415

Post by dijit »

mariusor wrote: post #388
genocidicbunny wrote: post #277

Earlier quoted context omitted.

Now explain this to an artist with very little programming experience beyond what they picked up from their coworkers. I don't mean to be too glib, but some programmers have this decrepit idea that anyone working with computers should understand programming to be able to fully utilize them. I worked in gamedev, and many of my colleagues were brilliant, but your comment would read as complete nonsense to many of them.…

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 extremely space inefficient.

Worse still: people try pushing their "short lived branches" workflow when using Git, which is *not* how gamedev works, especially for artists. Longer lived changesets are more common. (in Perforce these are called Shelves).

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

#416

Post by k_bx »

frollogaston wrote: post #234
wrwills wrote: post #227

Earlier quoted context omitted.

I suspect the use of Rust rather than C++ might have something to do with the fact that Simon Peyton Jones and Lennart Augustsson (both of Haskell fame) both work at Epic and there would have been a strong internal push to do this in a language with some functional programming features. Rust rather than Verse because that would probably not be the right tool for the job (even if Simon works on it). Rust rather than H…

I don't see how Rust is more functional programming oriented than C++

Pure by default, type classes (traits), no inheritance, type level lifetime computation. It's not only more functional it's much more type-safe and closer to Haskell in spirit

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

#417

Post by dimatura »

armcat wrote: post #386

Can this be used for ML/AI projects as well? I'm thinking for version controlling LoRa finetunes, finetuning data (which can consist of text, images and audio), safetensors, etc?

Of course it can. Is it good at it? I guess we'll find out, for sure people will try (I might if I get some spare time). At a glance some of the tech used resembles that of xethub (of which I was a user, until they got acquired by huggingface), which was marketed towards AI/ML/data science (to version control data/models/etc).

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

#418

Post by seniorThrowaway »

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…

I've had the misfortune of scripting an UE build with perfoce as the VCS, it truly is abysmal.

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

#419

Post by dijit »

nogbit wrote: post #333

Any multiregion deployment requires DynamoDB. Shame this solution is specific to AWS.

yeah, that's actually crazy.

I don't know a single AAA (or even AA) studio that hosts Perforce in Cloud at all.

Perforce usually starts out life in a gamedev studio as running on "a spare desktop" which then eventually gets promoted to a real server in a closet.

The most important thing for Perforce is disk, memory and above all: bandwidth (of those things and the network too!); it's also quite latency sensitive since all operations touch the server. So running it far away is never a good idea.

There was some complicated perforce architecture inside Ubisoft to account for this: AAA tends to involve a lot of co-dev studios, so the lead studio would get the commit server and others might get replicas (and you could feel to pain)- but all the perforce instances were actually on the same machines and would replicate to one-another anyway: each project was given a port for the perforce fleet. Really bizarre.

but, that's besides the point. Even the tiny studios run their own locally hosted VCS machines.

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

#420

Post by superxpro12 »

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…

Git LFS and git's (relatively) new sparse clone features i suspect are their answer to this sort of thing, although my understanding is that was more focused on monorepo operations in general. I'm not entirely sure permissions were sorted, or this sort of mixed-mode dvcs/cvcs operation model with file-scope checkouts interacting with traditional branch-mode operation.
Post reply on HN