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

481–490 of 717 posts

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

#481

Post by maccard »

danudey wrote: post #206
kvirani wrote: post #163

Earlier quoted context omitted.

There's also a new player called diversion (diversion.dev) which I think may be a YC startup? Anyway it takes a different approach of being more like Google drive but bringing in VCS behavior making it more indie and designer friendly.

At my previous game-dev-company job we ended up splitting things up into: 1. Code - Git 2. WIP art, shared assets (logos, marketing materials, etc) - Google Drive (because things are often changing, getting passed around, etc) 3. Finished assets (PSD files you're done with, or you think you're done with) - SVN (because we wanted a log of who contributed to what, wanted artists to be able to pick up where someone else…

Yeah that seems like an awful solution. This is exactly why we use perforce and just shove _everything_ in it.

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

#482

Post by 827a »

qmr wrote: post #228
827a wrote: post #135

Earlier quoted context omitted.

This presumption has destroyed far, far more companies and projects than the opposite assumption (that something built for small will scale to big, then doesn't).

Can you name five?

Kubernetes and the one I'm working at right now.

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

#483

Post by fsfod »

bc1000003 wrote: post #473
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…

Confirmed. Perforce is (was?) the industry standard for most larger game teams. If you've been in the business for any length of time you're probably pretty familiar with it and all of its many warts. But Perforce does get the job done and it's reliable and stable. However combining some of the flexibility and workflows of git with the ability to deal more efficiently and effectively with large asset files is somethi…

There is work being done on Git to add pluggable object backends[1] by some GitLab devs that could changes things up a bit and make large object handling not suck Maybe Lore could act like a promisor remote to pull large objects from as well for interop.

1: https://gitlab.com/groups/gitlab-org/-/work_items/15061

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

#484

Post by mietek »

PaulDavisThe1st wrote: post #446
reactordev wrote: post #385

Earlier quoted context omitted.

check-in isn’t a concept in git because there is no server in git. It’s just a log. The beauty of the merkle tree. It’s just GitHub became popular because people didn’t understand that you can rebase from any remote source. Delta patches become effortless

git is so agnostic about all this stuff that you can even merge completely disparate, unrelated repositories (for example, my own primary "job" repository, and the linux kernel) into the same on-disk structure. Of course, doing so is useless because none of the commits from one repo has any relevance to the other. But because the commits are identified by true GUIDs, there are no collisions, and both sets of commits…

I found the ability to merge unrelated repositories very useful when collecting various bits of work I did separately and combining it into a single library.

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

#485

Post by MoonWalk »

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

He was, but this incident wasn't an example. That's a righteous punishment for an infraction like that.

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

#486

Post by MoonWalk »

isodev wrote: post #430
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…

It’s funny how exciting Apple Pay was when introduced, only Apple pulled the lock-everyone-in card and now we’re all using QRcodes.

No idea what this is referring to...

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

#488

Post by mixdup »

isodev wrote: post #430
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…

It’s funny how exciting Apple Pay was when introduced, only Apple pulled the lock-everyone-in card and now we’re all using QRcodes.

In the US you can use Apple Pay anywhere NFC payments are accepted. It's generally completely open on the acceptance side at this point

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

#489

Post by PaulDavisThe1st »

FanaHOVA wrote: post #449
PaulDavisThe1st wrote: post #443

Earlier quoted context omitted.

One of the many points of git's design is that most of the steps you need to do in P4 are not necessary at all. You do not "lock assets", you do not "release them", there is no "merging into streams" equivalent. The entire workflow with git avoids huge amounts of the cognitive load of using P4, which in turn means that integration with IDEs becomes much less important. I worked with P4 around the time I first started…

Solving merge conflicts on text-based files is infinitely easier than binary-based. It's not a useful comparison.

What does that have to with your VCS being integrated with your IDE? Isn't resolving merge conflicts in binary files going to entirely a function of the IDE and not the VCS ? What am I missing?

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

#490

Post by jbverschoor »

ibejoeb wrote: post #356
jbverschoor wrote: post #263

Too bad it does not support fully local/detached (without server). It would be nice to be able to run it similar to a local repo without remote

The unique feature is universal locks (like cvs checkout) for opaque binaries like art, which requires universal state, so this seems to be orthogonal to the goal.

Myeah I understand, buy i generally enjoy just creating a local repo. Of course, not what Epic does ;)
Post reply on HN