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

691–700 of 717 posts

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

#691

Post by d3Xt3r »

jianfenglin wrote: post #574
m463 wrote: post #543

Earlier quoted context omitted.

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.

Wired headphones are making a comeback though. They're even considered trendy/fashionable now.

https://www.cnn.com/world/wired-headphones-comeback-spc

https://mashable.com/article/wired-headphones-instagram-acco...

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

#692

Post by throw2ih020 »

cylemons wrote: post #638
arka2147483647 wrote: post #229

Earlier quoted context omitted.

Its important to understand that in Game Dev a ’git clone’, aka ’p4 sync’, can be a terabyte of stuff. Git is bad at such volumes of binary assets, textures, models, sounds, etc.

Yikes, does that mean each dev has terabytes of stuff on their machine?

If they're doing a full build then yes, but in practice most devs or artists will work on smaller partial checkouts and another engineer or team works to keep everything integrated into regular builds. You don't need the full game locally to rig a model or paint a texture, and even some gameplay stuff can be tested in a graybox demo environment without the full game assets before being integrated.

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

#693

Post by throw2ih020 »

left-struck wrote: post #582
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…

Can this be used for Solidworks models? PDM is so awful

Yeah, engineering is another use case for Perforce, will be interesting to see if Epic pursues that market too. I know UE has some use in industries like architecture and professional simulators.

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

#694

Post by throw2ih020 »

throwaway81523 wrote: post #217
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 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 Git-annex ?

You gave me a flashback to that time I tried to use Git Annex on a moderately sized dataset and it resulted in a sysadmin at rsync.net personally contacting me to see if I needed help with whatever poorly written script was hammering their service.

In other words: No, absolutely not.

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

#696

Post by reactordev »

computerdork wrote: post #690
reactordev wrote: post #685

Earlier quoted context omitted.

Funny because `git pull` is an abstraction like you talk about. It's a `git fetch` followed by a `git rebase`. Staging or `stashing`, it's all just leaves on the merkle tree. The concept of time/branches/doesn't exist. Only previous hash, current hash. It's simple and people have ADDED complexity to make sense of it (coming from other VCS').

True, the pull command is simple. But it's really the pushing and merging that cause the problems. And, yeah, don't know if i'd call it simple in the way you're using the word. It's simple in that the tool is very "RISC" in nature instead of CISC, doing smaller simple operations instead of larger more complex ones (except for a few exceptions like pull). But for procedures like pushing your code, it's complex. You ha…

My counter argument is “what is the right order?” And you’ll say “the way work gets done” (paraphrasing) but then I’ll say “that’s exactly how git came to be”.

You are right that it gives you more options and more ways to footgun yourself but that mostly came after the fact. It does need a simplicity wrapper or some better defaults.

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

#697

Post by PaulDavisThe1st »

maccard wrote: post #662
59nadir wrote: post #633

Earlier quoted context omitted.

Honestly, when our backend team merged into one that was using Perforce for the backend learning how to use Perforce wasn't realistically even a blip on the radar of what to get used to. I was against it at the time for what we were doing but with the benefit of hindsight I can say that I prefer something like Perforce if someone can manage it for me, or it's a set-and-forget type situation; I don't personally have a…

> Honestly, when our backend team merged into one that was using Perforce for the backend learning how to use Perforce wasn't realistically even a blip on the radar of what to get used to. I think a lot of what people are assuming here is that because git has such a steep learning curve, P4 does too. You can literally ignore all of the concepts that P4 has and still muddle your way into getting things updated.

All I can say is that wasn't my experience with P4 in 2015.

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

#698

Post by computerdork »

reactordev wrote: post #696
computerdork wrote: post #690

Earlier quoted context omitted.

True, the pull command is simple. But it's really the pushing and merging that cause the problems. And, yeah, don't know if i'd call it simple in the way you're using the word. It's simple in that the tool is very "RISC" in nature instead of CISC, doing smaller simple operations instead of larger more complex ones (except for a few exceptions like pull). But for procedures like pushing your code, it's complex. You ha…

My counter argument is “what is the right order?” And you’ll say “the way work gets done” (paraphrasing) but then I’ll say “that’s exactly how git came to be”. You are right that it gives you more options and more ways to footgun yourself but that mostly came after the fact. It does need a simplicity wrapper or some better defaults.

Yeah, hopefully, someday someone will write a really good one that becomes universal used.

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

#699

Post by frollogaston »

gavinhoward wrote: post #480
VikingCoder wrote: post #298

Earlier quoted context omitted.

I tried to give that section of the doc a fair read. Looks like operational transforms to me. The doc claims it's the first with this technique. A 30 second search reminded me of Darcs, and taught me about Pijul, and Weave. And yes, Google Docs storage works the same way - there are probably papers documenting how efficient Google Docs storage is, but it's not wrapped up in a full VCS that folks can use. The example…

> Looks like operational transforms to me. Sort of. I add provenance, which helps properly identify collisions, and require a well-defined order by stacking [1] changelists. > The doc claims it's the first with this technique. More like the first with the particular angle on the technique. I specifically mention patch theory as another side of the same coin. > A 30 second search reminded me of Darcs, and taught me ab…

I'm not saying this goes over my head, but respectfully it goes over how much time I'm willing to spend understanding it... From what I can tell, it's a type of diffing approach. You're storing the diffs but tying them to hashes of the original data too.
Post reply on HN