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

611–620 of 717 posts

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

#611

Post by tikotus »

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.

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

#612

Post by IshKebab »

ibejoeb wrote: post #375
IshKebab wrote: post #371

Earlier quoted context omitted.

No they're saying that it will explicitly record the move, unlike Git which has to guess (it often fails).

Git does record the move, and you don't have to use the git ui to do it. Lore says it requires `lore stage move` to record it. More details in the reply to your other comment.

See my other comment. Git does not record moves.

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

#614

Post by dessimus »

vorticalbox wrote: post #469
Meneth wrote: post #457

Earlier quoted context omitted.

Banks absolutely love security by obscurity. No clue why.

security by only obscurity is bad. Having both is better. For example say I have a hollowed out wall that is hidden behind a painting. Just putting my money in the hole is bad once it’s found it’s gone but if I put my money in a safe in the hole. Well now you need to find it and break the safe and a hidden safe is objectively better than just having a safe on the floor because you need to find it first.

Sure, if there's many paintings scattered around the house of various sizes, but if there's only one painting, in your office, behind the desk, mounted to cover a safe at standing height, then you might as well hang a neon sign saying "Look Here!" next to it.

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

#615

Post by kreco »

kurhan wrote: post #613

Why development of lore happens on git/github ?. Subversion is hosted on subversion server. Same applies to mercurial or fossil. I'd expect that VCS project is self-hosted.

Maybe because they want contributions.

They have probably enough _bigger_ projects that dogfoods it.

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

#616

Post by KingMob »

FabHK wrote: post #602
forrestthewoods wrote: post #508

Earlier quoted context omitted.

> You do not "lock assets", Uhhhhhh. Locking binary assets is ABSOLUTELY NECESSARY in Git. Except Git can't actually do that. So what locking binary assets Git looks like in practice is an unenforced message in Slack saying "hey I'm changing this file please no one else touch it". Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets. > there is no "m…

> But I can also teach a game designer or artist who has never heard of source control how to correctly and safely use P4 in about 15 minutes. Meanwhile you can tell Git is badly designed because there are 10,000+ tutorials explaining how easy it is! Spoiler: things that are actually easy do not need 10,000 tutorials telling you that it is easy. 100% and LOL. Sometimes I wonder where we'd be if Mercurial (hg) had won…

Hoverjets, probably.

If you're not sick of hearing about it, jj is git-compatible, and borrows heavily from hg's UI and terminology. It's CLI is concistent, logical, and easier to pick up than git.

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

#617

Post by fc417fc802 »

Marsymars wrote: post #299
raincole wrote: post #283

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. If there is an asset that is updated very frequently in the early stage of development, you'll be charged for all the storage for the rest of the repo's life. That happens a lot in gamedev: most assets…

> 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.

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

#618

Post by lentil_soup »

danudey wrote: post #240
lentil_soup wrote: post #50

Earlier quoted context omitted.

don't think it supports branches it's also tough when you have 1TB of data, over 1mm files and you might want to lock hundreds files in one go

I mean, Git LFS 'supports branches' in that the LFS content identifiers are checked into git as files and Git operated normally; LFS is just a way to replace those content identifiers with the actual content, and then vice-versa when you commit. I think branching is the one thing that didn't get more complicated with LFS.

No, I meant the locking. Being able to branch a lock so you can edit an asset in a feature branch and then discard it (or force a merge)

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

#619

Post by KingMob »

gmueckl wrote: post #595
LugosFergus wrote: post #48

Earlier quoted context omitted.

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.

Yeah, it's a cool idea, but for proprietary formats, it's much harder for outsiders to do, and the original companies just don't see it as something they should take care of. My gut says there's too many changes that couldn't be cleanly merged anyway, so they think it's not worth the bother. (And they might be right.)

At least for code, I know people have attempted format-aware, structural diffing for a while. The Lisp communities tried a few times, because s-exps are trivial to turn into trees. None became the standard diff tool, though. However, modern tools like difftastic used tree-sitter to bring a lot of language-aware diffing to the masses.

- https://docs.racket-lang.org/sexp-diff/index.html

- https://github.com/michaelw/mw-diff-sexp

- https://github.com/lambdaisland/deep-diff2

- https://fazzone.github.io/autochrome.html

- https://github.com/Wilfred/difftastic

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

#620

Post by bananaboy »

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 been using p4 daily for about 21 years at various game studios (with a small break of around 5 years in the middle, where I used it only sporadically) and I think I can count the number of times I've used "reconcile offline work" on one hand. I think the only time my workspace has gotten into some kind of corrupted state was because of a crash that left it half-synced. If that ever happens I usually just blow it away and force sync the entire repo again rather than use reconcile (because it's so slow).
Post reply on HN