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

641–650 of 717 posts

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

#641

Post by qwery »

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 think your criticism of git's output is fine -- fair enough.

What I will say to that directly is that everyone's different and expecting a UI to match every user perfectly is unreasonable. I don't think it's fair to call output that's more verbose than you'd like "user-unfriendly" without qualifying who the user/s is/are.

The thing missing from most of the responses to this is: you can only get this information once. It's effectively impossible to have any of this information repeated -- you can't run it a second time with `--verbose`.

I don't mind things telling me what's going on, and git's push output is perhaps verbose, but not by a margin that causes me trouble. Maybe that comes with always running less than ideal hardware and having second rate internet connections. I want to know why a command took longer to run than I expected.

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

#642

Post by qwery »

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

git is not a particularly suitable VCS for gamedev for reasons so much deeper than what messages it prints for a given command. git is a tool built to solve versioning text files in a collaborative, open software development context. That is the problem git has in the gamedev space.

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

#643

Post by hosteur »

I do a bit of amateur photography and I have my photo collection in subversion today. Would Lore be a better fit for a photo collection with hundreds of thousands of binary files and almost a TB in size?

I have considered git many times but i have effectively one user and what I have now works. And I did not see any benefits in git for this use case.

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

#644

Post by tikotus »

maccard wrote: post #627
tikotus wrote: post #611

Earlier quoted context omitted.

I like putting it like this: VCS can be centralized or decentralized, and it can version per file or per commit. For games you want centralized per file versioning, like Perforce. Git is decentralized per commit versioning.

I mostly agree. I think for games you want per commit versioning 95% of the time. You don’t _really want developers building with cherry picked old revisions etc, but you don’t want an artist to have to pull down the 8TB of new art content that was submitted in the last 48 hours to update a texture.. the only way to do that is per file versioning!

Indeed. But luckily those who mostly want per commit versioning are coders, and they are technical enough to find a solution for this. Like perforce git interface.

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

#645

Post by badsectoracula »

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?

Theoretically yes, but in practice you don't need the full repository, but even in mid-2010 (when i first encounter Perforce in a gamedev company - previously the companies i worked on used Subversion which was also able to handle some huge repositories -- one had all their games from the 90s to early 2010s in a single Svn repository, including code and data) a workspace with just the game's code and data in the engine's format (i.e. excluding everything a programmer wouldn't need, like the "source data" for assets such as max/maya/etc files) was around 250GB or so. IIRC the entire repository (all versions, not just latest) had crossed a petabyte in size :-P though that company put absolutely everything in Perforce.

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

#646

Post by zipy124 »

Lucasoato wrote: post #212
zipy124 wrote: post #72

Earlier quoted context omitted.

If you've used git+LFS for any extended period of times, you'd know how often it breaks, especially when used with forges like GitHub. Both GitHub and Git treat LFS as an after-thought and second class citizen.

Can you tell me where did it break? Or what feature you wished it had? I’m just curious, still trying to form an opinion on this.

I searched through my browser history to see what issues I googled the last time I used it, here is a non-exhaustive list:

- Auth errors with github because of different supports for various methods which results in the unhelpful "does not support the locking API error"

- Encountered files that should have been pointers but weren't errors

- Github handling the spec wrong such that file pointers that are invalid can make it through to Github such as multiple file pointers to the same file, but that have different line endings (issue 5410 on the git-lfs github if you want to see the details)

- Semi-frequent object does not exist on the server errors

- LFS support cannot be used on forks in github (you must instead manually clone the project and upload as un-related)

- Cloning with non-default ssh key is somewhat convoluted (issues 2842 2215 2727 4145 and 2433 on git-lfs)

Some of these are actual git-lfs issues which make using the usual git API break such as the auth/ssh-key stuff, whilst others are simply that it is much easier to get yourself into a bad state with git-lfs than vanilla git. Of course you can always get yourself out of a bad state by fresh-clone, or forcing etc.... but with large files this becomes a non-instant operation.

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

#647

Post by Hendrikto »

jayd16 wrote: post #222
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…

P4 is more "industry standard" than "state of the art"... But it does handle large files and partial checkouts without feeling bolted on.

Git has had native partial checkout for ages.

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

#648

Post by qznc »

gavinhoward wrote: post #153

As someone who has thought a lot about VCS design [1] [2], the chunking approach is the wrong one and will still waste space. [1]: https://gavinhoward.com/uploads/designs/yore.md [2]: My WIP VCS has been named Yore for at least two years; I did not copy Lore's name.

I wrote down some thoughts about a "next generation VCS" in 2019: https://beza1e1.tuxen.de/monorepo_vcs.html

Back then I concluded that it will probably never be built because OSS projects don't need it. Maybe this is changing now as AI allows for larger OSS projects.

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

#649

Post by zackwu »

js2 wrote: post #493
sundarurfriend wrote: post #445

Earlier quoted context omitted.

> Because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it! This is the type of attitude that kept most Unix tools quite user-unfriendly for several decades. What information to show the user, and when, are important design decisions to make. Just dumping it all on the user and making them wade through it is not doing the user a favour. Thankfully newer tool…

> This is the type of attitude This is the type of attitude that makes me regret ever commenting on HN. FFS, git is a tool for programmers.

I'm a programmer and I understand Git internals decently well, but unless something went wrong, I pay zero attention to the verbose output of `git push`. BTW, isn't "avoid unnecessary output" one of the Unix philosophies?
Post reply on HN