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

271–280 of 717 posts

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

#271

Post by russdill »

spelunker wrote: post #82
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…

The lights are blinking, so everything must be working!

Basically, sometimes there commands take a long time. It's nice to have feedback that something is happening even if it's just effectively a blinking light.

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

#272

Post by MaulingMonkey »

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

C++'s stdlib collection algorithms were basically all mutate-in-place instead of return-a-new-value until C++20 introduced ranges, and I still don't know anyone who actually uses those. By contrast, people actually use the `container.iter().map(...)` etc. in Rust.

C++ also lacks much of the fancy pattern matching features which are frequently associated with functional programming. Such features may not be fundamental to functional programming, but they would fall under "some functional programming features", in the sense that they're common in the languages of that ecosystem.

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

#273

Post by throw_await »

foresto wrote: post #242
e40 wrote: post #43

Earlier quoted context omitted.

I think we can all agree that information should be behind a -v CLA. It's probably just something no one has thought of doing. I've learned over the decades to just ignore it.

> It's probably just something no one has thought of doing. One might reasonably think that about a number of git's rough edges, and one might be surprised at the reality. Some years ago, the annoyance of git's inconsistent terminology drove me to look into consolidating "cache", "index", and "staging area" in git's help text and documentation. What I found was that others had (of course) thought of it before, but wh…

That makes me sad. This termainology is really one of the major flaws of git, along with the checkout/reset thing

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

#274

Post by bryanlarsen »

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…

> p4 predates most of the VCSes we consider "modern"

p4 also significantly predates VCSes we consider obsolete. p4 is almost a decade older than SVN.

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

#275

Post by throw_await »

LtdJorge wrote: post #161
yoyohello13 wrote: post #99

Earlier quoted context omitted.

Luckily it’s an open source project so you could go in and clean up the ux.

Probably unacceptable as many would have built tooling around the specific default behaviors.

If tooling is relying on the output format of porcelain commands, it's wrong. The output of various subcommands have already changed more than once.

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

#276

Post by [deleted] »

manoDev wrote: post #224
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…

Git LFS is a major PITA, and if you use GitHub is even worse since there are quotas and rate limits that are charged separately.

[deleted]

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

#277

Post by genocidicbunny »

js2 wrote: post #136
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…

Objects are your files. Underlying git is a content-addressable filesystem. The objects are referenced by trees. A tree is just a directory. The trees are then referenced by commits and/or tags into a DAG with named pointers into various parts of it (which are your branch and tag references): https://git-scm.com/book/en/v2/Git-Internals-Git-Objects Because it would be terribly in-efficient to have a bunch of loose ob…

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. That is the problem git has in the gamedev space. You're trying to manage teams of programmers, designers, sound engineers, gameplay specialists, producers...even c-levels. The parent comment to yours is right, to many many people who work on things that Lore could be useful for would find git to be gobblygook.

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

#278

Post by Karliss »

Wowfunhappy wrote: post #101
Tuna-Fish wrote: post #44

Earlier quoted context omitted.

Lore itself is not an example of a program that meaningfully benefits from any of the key features of Lore. Lore is meant for situations where your repository is going to contain gigabytes of binary files, such as art assets for games. Git is technically great at everything but that, and even the external solutions for that situation still kind of suck.

Is Lore worse at managing text files, though? If not, it might make sense to adopt it fully in an organization so you can just use one tool.

Git is currently industry standard tool for software development, which means that almost every IDE and code editor has good and mature GIT integration. It will take a while for Lore to achieve similar level of support. Considering the intended usecase seems likely that they focus the effort on integrating into game engines and game development specific needs instead of making plugin for every last code editor. Not only code editor but every other software related tool interacts with version control - code review tools, CI, package managers and code forges. That's a lot more work than just creating a version control system. Why waste effort on areas that already have good alternatives.

Code forges lead to the next reason -> they are making it open source (see the faq for why). If they want community collaboration it makes sense to prefer industry standard tooling. Organization internal consistency doesn't matter to external collaborators. Various Google projects with all their custom tooling are good example of what happens if this gets ignored. Every time I have to deal with depot_tools or repo it's a pain.

Third reason not to self host is that it's not quite production ready (see "Is lore production-ready?" in the FAQ). Can't be self hosting from day 0 and once you have a working setup you need better argument for switching just because you can. If lore was attempting to make a statement that it's a superior method of version control for regular source code it would be a different story.

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

#280

Post by jhatemyjob »

reactordev wrote: post #251
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…

Has nothing to do with Perforce being the Oracle of VCS because it’s baked into the big 3? Riiiight.

It's not even baked into Google anymore.
Post reply on HN