Live data from Hacker News

Version Control for Everything

tyoverby.com

31–40 of 55 posts

Re: Version Control for Everything

#31

I suspect that game developers and other creatives (like 3D artists and movie effects people) have ways they track their versions. They have quite unusual assets and workflows. I agree that LLMs introduce a lot of new issues. We’re going to be developing a whole new paradigm, for working with them, and we’re just at the very start.

There are a lot of indie game devs and small studios that don't use any kind of formal system for this. Maybe they'll copy and paste the root folder once in a while. \Game - Copy (2) is technically version control, in a sense.

Re: Version Control for Everything

#33
post #21

Ah, we've got back to the "we should event source everything, and allow ourselves to change history and re-snapshot current state", idea gaining followers again. Well, yeah. But it's hard. Also, git is not the solution to this, it's just the screwdriver you have in your hand right now.

Funnily enough, git doesn't actually allow you to 'change' any history. It allows you to make new history, and the old history might get garbage collected eventually.

It does (let you change history), but in a tamper evident way.

Re: Version Control for Everything

#35
post #21

Earlier quoted context omitted.

Funnily enough, git doesn't actually allow you to 'change' any history. It allows you to make new history, and the old history might get garbage collected eventually.

Event sourcing normally doesn't either. The only way is forward.

Until you get an event (or 104561 events) that corrupts the whole system and makes it really tricky to get back a working version.

Re: Version Control for Everything

#36
post #2

I really really want to do version control for everything, but most of my data is binary so it really doesn't agree with git; I tried using LFS as well but it didn't work for my specific workflow. Hopefully something less text oriented comes along in the future. Lore looked interesting for this purpose. https://github.com/EpicGames/lore

Hash the files and commit the hashes. Store the large files somewhere convenient, keyed by the hash. Voila, you’ve invented an LFS.

That's just how plain git works anyway. Commits are just a tree of hashes which refer to the blobs in the objects store. Diffing is done on demand. If you can implement diff for binary files, then you've got git.

Re: Version Control for Everything

#37
I still don't understand why NILFS2 isn't more popular for these reasons. I've recently been experimenting with "workspace" VMs that use it. Instead of Git, I had Codex put together a simple system to "tag" useful snapshots, right now pre-post bits of work. I like it because sometimes something you'd normally gitignore gets changed when you didn't want it to. Plus you can cover system state outside of the project.

Re: Version Control for Everything

#38
Does anybody have experience storing issues/reviews in git? I know gerrit does this and keeps track of `change-id` to support rebase etc, but I think that requires a gerrit server to run.

Would also be nice if GitHub issues/reviews were in sync so reviews are accessible during a GitHub outage.

Re: Version Control for Everything

#39

I suspect that game developers and other creatives (like 3D artists and movie effects people) have ways they track their versions. They have quite unusual assets and workflows. I agree that LLMs introduce a lot of new issues. We’re going to be developing a whole new paradigm, for working with them, and we’re just at the very start.

There are a lot of indie game devs and small studios that don't use any kind of formal system for this. Maybe they'll copy and paste the root folder once in a while. \Game - Copy (2) is technically version control, in a sense.

I would hope they have ways to track those assets. They may be worth tens of millions of dollars.

Re: Version Control for Everything

#40
post #6
post #5

Earlier quoted context omitted.

But versionning everything is not really great idea. Probably 90% of your files are static. Archives, Media, LIBs. Not worth versioning. But for that 10%, having any (D)VFS is handy. Thats why I wrote DOT for myself, to handle that niche need to version every document I work with. Its private for now, but here is printout of help: http://borg.uu3.net/~borg/?dot

why not version control those things? if they're static, there's no changes so version controlling them has little cost. maybe existing tools aren't adequate for this conception of the world, but I don't think that's a good reason not to work towards "version control everything"

Cost of keeping all data (up to +100%). If they dont change, no point of really versioning them. Backup of those is simple either, whatever syncing software (incremental).

Docs that often change, its completly different story. I love VCS like features where I can slam 'dot status' to see whats going on, commit when I feel I need snapshot, sync to whatever device I want. And because I run DVFS I dont even bother with backups because I have multiple copies of repo with entire history.

Post reply on HN