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

291–300 of 717 posts

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

#291

Post by andrewflnr »

yoyohello13 wrote: post #99
maccard wrote: post #91

Earlier quoted context omitted.

> It's probably just something no one has thought of doing There are 1000 things that's true of about git. At a certain point that becomes a problem in and of itself.

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

Great, then your choices are (a) try and probably fail to get your changes upstreamed and/or (b) maintain your own fork of git forever.

This is very much a "if you don't like X about your country, just move to a different one" kind of "solution". The costs are extreme to the point that pretending it's viable is insulting. Really it's just a way to silence legitimate complaints.

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

#292

Post by ibejoeb »

frollogaston wrote: post #107

"Full-surface API" is a feature nobody here has mentioned. Is that a dig at how git intentionally has no linkable library? I saw this earlier https://news.ycombinator.com/item?id=48470604

I don't know if it's a jab at git. Git does have `porcelain` to accommodate programmatic interaction. It's not linkable, but it's still an API.

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

#293

Post by orthoxerox »

bigbuppo wrote: post #259
iveqy wrote: post #211

Earlier quoted context omitted.

The way I usually solve this is by using git submodules.

Oh man, I've been laughing at this for 37 minutes straight now.

Git submodules are the regular expressions of version control.

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

#294

Post by gouggoug »

danudey wrote: post #195
SoftTalker wrote: post #160

Earlier quoted context omitted.

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?

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…

From the linked article, it was a press release, not just to his employees.

> The incident began Monday when ATI, which supplies graphics cards for all Apple's current models, issued a four-paragraph news release that stated its Radeon processor would be featured in three new Mac models -- none of which were announced by Apple (Nasdaq: AAPL) until CEO Steve Jobs' Wednesday morning keynote address.

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

#295

Post by xboxnolifes »

ibejoeb wrote: post #286

> lore stage covers adds, edits, and deletes — you use the same command for all three. Stage a deleted file and Lore records the deletion for the next commit. Moves and renames are tracked too, through a dedicated subcommand: lore stage move records the rename so the file keeps its identity and history across the move instead of registering as a delete plus an add. Oof. So this isn't compatible with any tools that mo…

Isn't this just the same thing as `git mv`?

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

#296

Post by xiaoyu2006 »

cmrdporcupine wrote: post #132
cedws wrote: post #34

Earlier quoted context omitted.

Git as a data structure is clever, but Git as a CLI is atrocious.

Obligatory: https://git-man-page-generator.lokaltog.net/

this is such a good laugh. peak comedy

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

#298

Post by VikingCoder »

frollogaston wrote: post #185
gavinhoward wrote: post #179

Earlier quoted context omitted.

When it comes to large assets, wasting large chunks of space is a problem. If your chunks are 64 kib average (from the Lore document), but changes only average 1 kib (which could be a high estimate), then you will still run out of space 64 times faster and need to read 64 times more data off of the disk for certain operations. It also makes diffing hard, as well as diff viewing.

What do you do instead of chunking your snapshots? Storing diffs is usually the other approach.

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 in the doc uses text, and unfortunately I think it's for a reason. I think with large, binary game assets, the most common operation is going to be strings of "replace A with B", and depending on your chunk size relative to the distribution of changes you make on your assets, I see it as pretty close to a wash, for efficiency. Especially considering that content-addressable blocks also solves de-duplication, which for a multi-game studio is probably going to be significant. Especially if they're managing multiple releases, patches, development branches, etc.

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

#299

Post by Marsymars »

raincole wrote: post #283
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…

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 can rewrite the history of the LFS repo on an as-needed basis.

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

#300

Post by js2 »

genocidicbunny wrote: post #277
js2 wrote: post #136

Earlier quoted context omitted.

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

I'm not here to engage in rhetorical combat.

I was simply answering niek_pas's rhetorical questions, that's all, because maybe they piqued someone's curiosity and I can contribute a little of my esoteric knowledge about the inner workings of git. This is a site for the curious, yes?

Git is a tool by programmers for programmers. If folks outside the programming community are able to use it, great, but that's not its target audience. You don't need to convince me why git isn't suitable for artists.

Cheers.

Post reply on HN