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

571–580 of 717 posts

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

#571

Post by lkjdsklf »

y1n0 wrote: post #303
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…

I’ve started using JJ vcs, mainly because some people were saying it was great and I didn’t really get it. I’m starting to come around though. From a UI perspective it’s a major improvement on git. The branching workflow is something that has taken a bit to get used to though.

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 what it is. We don’t need bookmarks. Just stop. Everyone who used mercurial used plugins to turn them into basically branches and same thing with jj.

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

#572

Post by anitil »

LugosFergus wrote: post #62
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…

Something else that git isn't good at: permissions. In gamedev, you might have proprietary work that you want to restrict to certain users. In P4, you can add restrictions to certain directories for only those who have signed the required NDAs. That's not something that you can do in git: it's all or nothing. Maybe you can set something up with submodules, but that's going to upend your repository if you hadn't plann…

Your comment and the parent comment are fantastic. I'd never have thought of them because I've never worked in the field

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

#573

Post by ozkatz »

dimatura wrote: post #421
penciltwirler wrote: post #88

The premise is that Git-LFS sucks, so we need to build a new data versioning system (in Rust, from scratch). While I mostly agree with this premise, but there are already lots of existing (mature) data versioning systems with the same tricks under the hood: - Pachyderm (Go): https://github.com/pachyderm/pachyderm - XetHub (acquired by HuggingFace): https://huggingface.co/blog/xethub-joins-hf - LakeFS (Go): https://gi…

There's also git-annex and iterative DVC. I used xethub a fair bit (was the earliest user, in fact) and I thought it was better than git annex, git-lfs and DVC, but still did start to struggle past a certain size. I think part of the problem was just git itself, and the compromises required to have a hybrid repo. So I'm happy to see this vcs doesn't use it. xethub did start shipping a version of their product that di…

Curious if you’ve had a chance to try lakeFS?

It was designed with large-scale environments in mind. I’m aware of several deployments managing hundreds of petabytes of data and billions of objects, which is why lakeFS does not use Git’s Merkle tree / directory tree approach.

Disclaimer: I’m one of the project’s co-creators.

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

#574

Post by jianfenglin »

m463 wrote: post #543
LPisGood wrote: post #517

Earlier quoted context omitted.

That decision had a lot of detractors at the time, but it ultimately seems to have been correct.

I don't know if I agree. People who moved to bluetooth got arguably worse sound quality. For wired headphones, there were very few lightning headphones and they mostly sucked. Now with usb-c you can get a broader range of headphones (because other phones have gone with usb-c). either kind needs a dac inside the dongle, or the shell of the headphone, or have a bulky external dac. 3.5mm is still king for decent wired h…

Most people don't like wire and don't care about genuinely good sound through wire vs. artificially sweetened (DSP-ed) sound through Bluetooth. That's what Apple is targeting at, the mass consumer.

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

#575

Post by edoceo »

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?

There is a bunch of mundane stuff in the banking/finance world masked off by paperwork.

It's not sensitive in the leaking state secrets sense it's sensitive in the risk adverse lawyers on both sides think it's sensitive.

The Bureaucracy exists to perpetuate the Bureaucracy.

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

#576

Post by kazinator »

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 non-strawman version of "security through obscurity" is the belief that a system is secured by means of keeping its mechanisms secret.

Suppose an organization doesn't believe such a thing; it's still more secure to keep code secret than not.

Obscurity is a valid layer of security, just not a valid corner stone or linchpin of security.

In particular, when code operates as a service (end users don't have the executable code on their machines) then protecting the source code is a real security measure. Without it, attackers can only probe the service as a black box, guessing about what it is doing.

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

#577

Post by kazinator »

ifh-hn wrote: post #252
danudey wrote: post #195

Earlier quoted context omitted.

As others have said, it's Apple and they do not take kindly to other people leaking their technology/announcements ahead of time. See also: the time that ATI's CEO told his employees that their chips would be powering Apple's to-be-announced hardware a few days before the announcement. Steve Jobs responded by pulling all of ATI's hardware from its demo units at the announcement, not mentioning ATI at all, cancelling…

Sounds like a bit of a dick...

I believe that the action does reflect Jobs' ego in the following way.

Namely, his belief that CEO == company.

Jobs would never take the view that the action of the CEO of ATI is actually one bad actor acting alone which doesn't represent what ATI wants as an organization, and is unfair and damaging to that organization and all of its employees.

The reason he would not take that view is because then he would not be able to believe that he is the single most important thing at Apple, overshadowing everything else.

If the leak had been the responsibility of some rank and file employee at ATI, with appropriate action taken against that employee by the ATI CEO, it is likely that Jobs would likely have reacted differently, because it then would not longer be seen as a personal matter between him and the CEO, where the corporations are just pawns in a game of teach-you-a-lesson.

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

#578

Post by Scramblejams »

Tiktaalik wrote: post #118
rootlocus wrote: post #33

Earlier quoted context omitted.

Git LFS has file locking, and no VCS can provide you with the tools for diffing binary assets. I don't see any meaningful difference between Perforce, Diversion or Lore and git + LFS + file locking. Unless there's a meaningful performance impact for large projects (I only work on small / medium projects), the capabilities are the same. However, I get excellent git support for code in any editor, as opposed to Diversi…

There's also the tooling. Game teams have artists and designers where baroque command line incantations are headwinds to their workflow pace. For the longest time Git tools were really poor. In recent years there's a few ok ones, like Git Fork, though I wouldn't know if those tools scale to the level of a AAA team size repo and not fall over.

Maybe more than a headwind. From my time in AAA here are two things I learned that were true in that environment:

1. Artists hate Perforce.

2. You will never get them to try anything else.

I'm exaggerating, but not by that much. I lost count of the number of artists who are deeply uncomfortable with technology and just manage to learn the bare minimum to do their job, and then will take no more.

So besides everything else Lore needs to nail to be acceptable, they need to make it easy for artists to switch. Maybe when UnrealGameSync grows enough knobs and switches to make it unnecessary for an artist to ever touch P4V, Epic can roll Lore into UGS as an unobtrusive option. And if by then there's good support in Unity, in JetBrains, in Maya, etc., then maybe they'll have something.

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

#579

Post by kazinator »

Meneth wrote: post #457
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…

Banks absolutely love security by obscurity. No clue why.

Banks run a lot of code as a service. Most people never get to see the executable code. If the source code for those services were easily visible to employees that don't need to have access to it or external consultants and such, that would be monumentally stupid.

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

#580

Post by PaulDavisThe1st »

maccard wrote: post #527
PaulDavisThe1st wrote: post #523

Earlier quoted context omitted.

> Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets. OK, I think this is well-established by up-thread comments, and I don't disagree with it at all (though note that its not just binary assets, it's anything that isn't line oriented, which includes for example XML). I didn't realize that LinearIO's comment was really that specific; it appeared to…

> The 10k tutorials on git might indicate issues with its design, or it might indicate its massive popularity. Hard to say. It's "hard to say" if you want to ignore the fact that it requires 10k tutorials. Meanwhile, there are 500+ person companies with non technical users using P4 with literally 0 onboarding other than "by the way, undo is broken don't use it". > I just remember that learning to use P4 required lear…

the fact that 10k tutorials exist says way more about the human urge to write, document, and share information than git itself. the 10k number is also a made up statistic. It might be 2k, it might be 20k. i use git daily and often fairly intensively, and i've read perhaps 5-10 tutorials, so the idea that "git requires 10k tutorials" just doesn't make any sense.

if anything, the fact that something with good search-fu might find a tutorial more specifically catering to their background and needs seems like a huge plus for git.

> Using P4 is: Download P4V, install plugin for $EDITOR, and double click on a changelist to submit.

"a changelist" ... "what the hell is that? I've been editing my files, I don't have "a changelist"."

and anyway, joining a company that's already using P4 is never, ever going to be that simple (even if it was actually that simple as the first user, which I question)

Post reply on HN