5 ms·

Version Control for Everything

52 points by evakhoury 1mo ago

cfjgvjh 27d ago
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 https://github.com/EpicGames/lore
- Borg3 27d ago
  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 http://borg.uu3.net/~borg/?dot
  - denkmoon 27d ago
    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"
    - Borg3 27d ago
      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.
  - XorNot 27d ago
    The bigger issue is that most of the files you're likely to capture in "version everything" are just noise. Disk space is far from cheap when the value of what's being stored is basically zero. You can version everything today with something like ZFS snapshoting - and very quickly realize hundreds of gigabytes of noise aren't worth keeping.
- xyzsparetimexyz 27d ago
  Why not just fork git and make it better at binary files?
  - DanielHB 27d ago
    Problem with dealing with binary files with git (or source control in general) is that you want to be able to see diffs, which is very dependent on the type of binary file you have. I think you can create git plugins to show diffs in different formats for certain file-types (or even open a 3rd party tool to let you visualize it), but it is a lot of work. Most productivity tools don't have anything of the sort. If you just care about storing the file git LFS + manual text-changelog per binary file works well, but it is annoying to get everyone on your team to work in this workflow (heck, getting everyone and all automation scripts to install LFS is already a pain).
    - gmueckl 27d ago
      The problem is really starting g with a coders mindset that reducing a change to an explicit visual representation of a minimal delta is such a useful thing for everybody. It isn't. For example, for images, an A/B comparison is enough in a lot of cases. There are also no meaningful ways to "merge" changes for a lot of data outside source code, so the insistence that version control can't exist without merging is shortsighted. Meaningful deltas and meaningful merges are actually a problem set that is totally and utterly disjointed from keeping the underlying change history. Deltas and merges can always be computed independently of the underlying storage format for versioned data. Git could have indicriminately used binary deltas for file storage and would still work the same on every higher layer.
      - eru 27d ago
        In Git the deltas (or diffs) are derived data. They aren't central to what Git is. Natively and conceptually, Git works with repository snapshots.
  - eru 27d ago
    You don't even need to fork it: git has something like a plugin system for exactly this use-cases. (I'm not exactly sure what their terminology is. But they thought about this use-case before.)
- 2001zhaozhao 27d ago
  It's interesting you brought up Lore. I also wonder whether importing VCS tech from the games industry for versioning general agentic work would be a good idea.
- catlifeonmars 27d ago
  Hash the files and commit the hashes. Store the large files somewhere convenient, keyed by the hash. Voila, you’ve invented an LFS.
  - globular-toast 27d ago
    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.
    - catlifeonmars 24d ago
      True. The main difference, like you pointed out, are the concept of a file tree and a commit tree which adds some structure along the time and space dimensions on top of the content-addressable blob storage.
  - WhyNotHugo 27d ago
    That's exactly what git-annex does: https://git-annex.branchable.com/ https://git-annex.branchable.com/ LFS is kinda close, but you don't store the files "somewhere convenient": you need support on every git remote to handle the files.
- TYPE_FASTER 26d ago
  I guess it kinda depends on your use case. If you're versioning software artifact binaries and want to have support for rules for retention (keep n number of builds around), version numbering (you can only write a release artifact with a version number once), etc., using Git for text and Artifactory for artifact binaries has worked pretty well for me.
ssivark 27d ago
> We use issue trackers and pull requests to manage work, people write documentation and communicate over email, instant messaging, and in meetings. Keeping all of the information in these channels synchronized and up to date is a full time job. The crux of what OP wants seems to be transparent interfaces to the data store backing each of these services. Version control would be about tracking changes when this data mutates, which seems somewhat orthogonal to this stated need. I wonder whether a nice solution to this would be to have a distributed architecture where each node can publish / subscribe to updates and maintain a local copy it operates on, with conflict resolution for eventual consistency. PS: Checkout Perkeep for a take on aggregating all your data in one place.
Klaster_1 27d ago
> Design docs from Google Docs to checked-in markdown? This worked pretty well for the team I'm in. Design docs in Google Docs were really hard to keep in sync with decisions and not properly agent accessible. Initially, we were concerned lack of comments would be an issue, but this didn't really came true - a Slack channel does a good enough job. With this flow, the design author makes a decision and review results, agent propagates it to individual areas, and from those to tasks (those are in MD too), and then copies descriptions to Jira. No more "we changed a thing but missed one place that depends on it", or at least not as bad as before.
- davethedevguy 27d ago
  Would you mind elaborating on from those to tasks (those are in MD too) please? We're doing the design docs in MD thing, but are you saying you've gone a step further and have the backlog represented in git too?
  - Klaster_1 27d ago
    Not the whole backlog, just the tasks for the feature being designed, like an epic. Atlassian has a CLI that - acli. We use Jira as usual, it's just a way to not having to manually propagate design adjustments to Jira.
germandiago 27d ago
LLMs are irremediably broken (agents also) for delivering software. The most you can do is to accelerste subworkflows and review as hell. Noone wants middle term maintenance nightmares or unreliable code. Can look good the first month, that's it. I think they have been overselling it so much but you need to know exactly what you are doing and I think for generating code they are pretty bad. And they will improve as they sniff some more data but that's it. Something new, something LLMs do pretty bad.
conartist6 27d ago
I've been working for a long time to be ready for this need! Blab is an (un-announced) version control system designed to support "everything". It's built on top of a content-hashable XML-ish data modeling language called CSTML: https://docs.bablr.org/guides/cstml https://docs.bablr.org/guides/cstml Binary document support isn't done yet, but it is planned.
hoistway 27d ago
The revert safety net is what makes agentic coding tolerable. Without version control, every AI mistake becomes permanent, and that alone kills the workflow.
- aitchnyu 27d ago
  Also the linters and unit tests that keep the agent on track.
ammar_az 27d ago
The approach of having everything next to the code seems good in theory but it's just a nightmare in practice for big projects. Imagine your git history filled with commits from project managers where every little change in requirements and docs has its own commit. We've tried that and ended up having to rebase our branches multiple times a day while we lost the overview of code changes completely. The main issue that code can live in multiple branches while development but you can't apply that to docs and requirements where you need to have one centralized source of truth for everyone. I think we will start to see more adaptation from collaboration tools to provide/accept the info in text format making it suitable for agents as a working solution. Meanwhile, I've seen that having two repos (One for Code and one for docs) is the best solution for the current tools available
- vjvjvjvjghv 27d ago
  “ every little change in requirements and docs has its own commit” I think this would be a great thing to have and know who changed what and when. It seems it’s more of a problem of the tools being able to help the user see only what he needs to see in a certain context.
  - ammar_az 27d ago
    It's a great thing if those changes live in their own repo and not mixed with changes to the code itself. Actually Jira has been doing that for a while now by offering the history view with a timeline for each change, also GitHub shows edit version for files as well. The main role for projects management is handle the chaotic way of humans communication across different organization without developer being involved in that messy cycle. But having everything in the same repo will remove this decoupling and will let developers get involved in that chaos as it's part of the repo history.
- badsectoracula 27d ago
  The issue you describe seems to be related to the tools you're using and how you use them, not to the core idea itself. I've worked in several gamedev companies where everything was in a Perforce repository. In fact in one company EVERYTHING was in it, not just code and game data, but also documents, concept art, plans, everything. If it wasn't in P4, it didn't exist. Yet nobody thought it was a pain (after learning to use P4V at least :-P but that's a different topic) because P4 a) can handle big files just fine and b) you don't really care about the history of the entire repository, but only about the part you're working on. For example personally i had my history tab display just the engine's code directory (and even then i rarely checked it since i don't really care what Joe working on the animation code did, my main interest was on the stuff i worked - and P4V showed me both if someone else is working on the same files i am and if my files have been modified, with easy GUI tools to see both diffs and the file's development history visually - the timeline feature is honestly great for that). Perforce has some fundamental issues in how it works that creates problems, probably because of some deeply ingrained assumptions stemming from the 90s when it was first made that were never addressed, but it also has a lot of features (especially on the P4V GUI client) that makes working on a huge monolithic repository where everything goes in pretty much seamless.
PaulRobinson 27d ago
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.
- eru 27d ago
  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.
  - globular-toast 27d ago
    Event sourcing normally doesn't either. The only way is forward.
    - andy_ppp 27d ago
      Until you get an event (or 104561 events) that corrupts the whole system and makes it really tricky to get back a working version.
  - emmelaich 27d ago
    It does (let you change history), but in a tamper evident way.
    - eru 26d ago
      It's two different ways to see the same thing. Basically, almost everything is immutable in git, apart from tags and branches: these are mutable pointers to immutable commits.
- catlifeonmars 27d ago
  As the saying goes, “when you have a screwdriver, everything looks like nail” <proceeds to hammer down the screws with the back of the screwdriver>
samuell 27d ago
> Why not put issues alongside the codebase? That's the idea of Epiq: https://ljtn.github.io/epiq/ https://ljtn.github.io/epiq/ > In my view, the main obstacle here is that without serious dedication, the user experience for humans would be a major downgrade. This isn’t insurmountable, but it would be a lot of work. I think Epiq does a decent job of addressing this. Take a look at the second animation on the page above. It even lets you "scrub" your way through the timeline to very quickly glance at what an agent (or junior developer) did to your code recently.
purplepatrick 27d ago
Methinks AI hasn’t been as successful in non-verifiable domains, because they are non-verifiable, not because there’s no version control…
ChrisMarshallNY 27d ago
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.
- applfanboysbgon 27d ago
  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.
  - ChrisMarshallNY 27d ago
    I would hope they have ways to track those assets. They may be worth tens of millions of dollars.
    - applfanboysbgon 26d ago
      You would hope. I know of one case of an indie dev of an extremely successful, multimillion dollar franchise who did in fact lose everything related to the original game that made them successful, something which probably has cost them millions of dollars because they were unable to port it despite demand, and they've spent over a year recreating it from scratch.
theknarf 27d ago
https://www.inkandswitch.com/universal-version-control/ https://www.inkandswitch.com/universal-version-control/
emmelaich 27d ago
You could run rsync with -b --backup-dir=something-$(date +%Y%m%d.%H%M%S) every few seconds. Or fired off with inotify.
eturkes1 27d ago
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.
stabbles 27d ago
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.
- gritzko 27d ago
  Beagle indexes all the tickets within reach and shows them in one Excel-like view with buttons to manage their worktrees https://replicated.live/blog/click https://replicated.live/blog/click There is a port for plain git repos named Bee. That one is earlier-stage, but works https://github.com/gritzko/bee https://github.com/gritzko/bee
OroPla 27d ago
I am disappointed that the article doesn't talk about backups, which kind of are version control for everything.
dowonseo 27d ago
A pull request for a minor value change to an xlsx file doesn't sound so good
t4t5 27d ago
This is why I’m convinced we’ll see a lot more “plaintext-first” apps going forward. As agents take over more of our workload, it becomes increasingly important to store the data in a dumb and simple format that’s easy to diff and verify. I talked about some of this at LocalFirstConf: https://youtu.be/2ZEBH5Clrnc https://youtu.be/2ZEBH5Clrnc
timsehn 26d ago
I'm the CEO of a company that's focused on version control for structured data ie. SQL tables and JSON documents. We share the "version control for everything" vision and think an agentic world needs it. https://www.dolthub.com/ https://www.dolthub.com/

52 points by evakhoury 1mo ago

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 https://github.com/EpicGames/lore

Borg3 27d ago
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 http://borg.uu3.net/~borg/?dot
- denkmoon 27d ago
  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"
  - Borg3 27d ago
    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.
- XorNot 27d ago
  The bigger issue is that most of the files you're likely to capture in "version everything" are just noise. Disk space is far from cheap when the value of what's being stored is basically zero. You can version everything today with something like ZFS snapshoting - and very quickly realize hundreds of gigabytes of noise aren't worth keeping.
xyzsparetimexyz 27d ago
Why not just fork git and make it better at binary files?
- DanielHB 27d ago
  Problem with dealing with binary files with git (or source control in general) is that you want to be able to see diffs, which is very dependent on the type of binary file you have. I think you can create git plugins to show diffs in different formats for certain file-types (or even open a 3rd party tool to let you visualize it), but it is a lot of work. Most productivity tools don't have anything of the sort. If you just care about storing the file git LFS + manual text-changelog per binary file works well, but it is annoying to get everyone on your team to work in this workflow (heck, getting everyone and all automation scripts to install LFS is already a pain).
  - gmueckl 27d ago
    The problem is really starting g with a coders mindset that reducing a change to an explicit visual representation of a minimal delta is such a useful thing for everybody. It isn't. For example, for images, an A/B comparison is enough in a lot of cases. There are also no meaningful ways to "merge" changes for a lot of data outside source code, so the insistence that version control can't exist without merging is shortsighted. Meaningful deltas and meaningful merges are actually a problem set that is totally and utterly disjointed from keeping the underlying change history. Deltas and merges can always be computed independently of the underlying storage format for versioned data. Git could have indicriminately used binary deltas for file storage and would still work the same on every higher layer.
    - eru 27d ago
      In Git the deltas (or diffs) are derived data. They aren't central to what Git is. Natively and conceptually, Git works with repository snapshots.
- eru 27d ago
  You don't even need to fork it: git has something like a plugin system for exactly this use-cases. (I'm not exactly sure what their terminology is. But they thought about this use-case before.)
2001zhaozhao 27d ago
It's interesting you brought up Lore. I also wonder whether importing VCS tech from the games industry for versioning general agentic work would be a good idea.
catlifeonmars 27d ago
Hash the files and commit the hashes. Store the large files somewhere convenient, keyed by the hash. Voila, you’ve invented an LFS.
- globular-toast 27d ago
  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.
  - catlifeonmars 24d ago
    True. The main difference, like you pointed out, are the concept of a file tree and a commit tree which adds some structure along the time and space dimensions on top of the content-addressable blob storage.
- WhyNotHugo 27d ago
  That's exactly what git-annex does: https://git-annex.branchable.com/ https://git-annex.branchable.com/ LFS is kinda close, but you don't store the files "somewhere convenient": you need support on every git remote to handle the files.
TYPE_FASTER 26d ago
I guess it kinda depends on your use case. If you're versioning software artifact binaries and want to have support for rules for retention (keep n number of builds around), version numbering (you can only write a release artifact with a version number once), etc., using Git for text and Artifactory for artifact binaries has worked pretty well for me.

ssivark 27d ago

> We use issue trackers and pull requests to manage work, people write documentation and communicate over email, instant messaging, and in meetings. Keeping all of the information in these channels synchronized and up to date is a full time job. The crux of what OP wants seems to be transparent interfaces to the data store backing each of these services. Version control would be about tracking changes when this data mutates, which seems somewhat orthogonal to this stated need. I wonder whether a nice solution to this would be to have a distributed architecture where each node can publish / subscribe to updates and maintain a local copy it operates on, with conflict resolution for eventual consistency. PS: Checkout Perkeep for a take on aggregating all your data in one place.

Klaster_1 27d ago

> Design docs from Google Docs to checked-in markdown? This worked pretty well for the team I'm in. Design docs in Google Docs were really hard to keep in sync with decisions and not properly agent accessible. Initially, we were concerned lack of comments would be an issue, but this didn't really came true - a Slack channel does a good enough job. With this flow, the design author makes a decision and review results, agent propagates it to individual areas, and from those to tasks (those are in MD too), and then copies descriptions to Jira. No more "we changed a thing but missed one place that depends on it", or at least not as bad as before.

davethedevguy 27d ago
Would you mind elaborating on from those to tasks (those are in MD too) please? We're doing the design docs in MD thing, but are you saying you've gone a step further and have the backlog represented in git too?
- Klaster_1 27d ago
  Not the whole backlog, just the tasks for the feature being designed, like an epic. Atlassian has a CLI that - acli. We use Jira as usual, it's just a way to not having to manually propagate design adjustments to Jira.

germandiago 27d ago

LLMs are irremediably broken (agents also) for delivering software. The most you can do is to accelerste subworkflows and review as hell. Noone wants middle term maintenance nightmares or unreliable code. Can look good the first month, that's it. I think they have been overselling it so much but you need to know exactly what you are doing and I think for generating code they are pretty bad. And they will improve as they sniff some more data but that's it. Something new, something LLMs do pretty bad.

conartist6 27d ago

I've been working for a long time to be ready for this need! Blab is an (un-announced) version control system designed to support "everything". It's built on top of a content-hashable XML-ish data modeling language called CSTML: https://docs.bablr.org/guides/cstml https://docs.bablr.org/guides/cstml Binary document support isn't done yet, but it is planned.

hoistway 27d ago

The revert safety net is what makes agentic coding tolerable. Without version control, every AI mistake becomes permanent, and that alone kills the workflow.

aitchnyu 27d ago
Also the linters and unit tests that keep the agent on track.

ammar_az 27d ago

The approach of having everything next to the code seems good in theory but it's just a nightmare in practice for big projects. Imagine your git history filled with commits from project managers where every little change in requirements and docs has its own commit. We've tried that and ended up having to rebase our branches multiple times a day while we lost the overview of code changes completely. The main issue that code can live in multiple branches while development but you can't apply that to docs and requirements where you need to have one centralized source of truth for everyone. I think we will start to see more adaptation from collaboration tools to provide/accept the info in text format making it suitable for agents as a working solution. Meanwhile, I've seen that having two repos (One for Code and one for docs) is the best solution for the current tools available

vjvjvjvjghv 27d ago
“ every little change in requirements and docs has its own commit” I think this would be a great thing to have and know who changed what and when. It seems it’s more of a problem of the tools being able to help the user see only what he needs to see in a certain context.
- ammar_az 27d ago
  It's a great thing if those changes live in their own repo and not mixed with changes to the code itself. Actually Jira has been doing that for a while now by offering the history view with a timeline for each change, also GitHub shows edit version for files as well. The main role for projects management is handle the chaotic way of humans communication across different organization without developer being involved in that messy cycle. But having everything in the same repo will remove this decoupling and will let developers get involved in that chaos as it's part of the repo history.
badsectoracula 27d ago
The issue you describe seems to be related to the tools you're using and how you use them, not to the core idea itself. I've worked in several gamedev companies where everything was in a Perforce repository. In fact in one company EVERYTHING was in it, not just code and game data, but also documents, concept art, plans, everything. If it wasn't in P4, it didn't exist. Yet nobody thought it was a pain (after learning to use P4V at least :-P but that's a different topic) because P4 a) can handle big files just fine and b) you don't really care about the history of the entire repository, but only about the part you're working on. For example personally i had my history tab display just the engine's code directory (and even then i rarely checked it since i don't really care what Joe working on the animation code did, my main interest was on the stuff i worked - and P4V showed me both if someone else is working on the same files i am and if my files have been modified, with easy GUI tools to see both diffs and the file's development history visually - the timeline feature is honestly great for that). Perforce has some fundamental issues in how it works that creates problems, probably because of some deeply ingrained assumptions stemming from the 90s when it was first made that were never addressed, but it also has a lot of features (especially on the P4V GUI client) that makes working on a huge monolithic repository where everything goes in pretty much seamless.

PaulRobinson 27d ago

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.

eru 27d ago
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.
- globular-toast 27d ago
  Event sourcing normally doesn't either. The only way is forward.
  - andy_ppp 27d ago
    Until you get an event (or 104561 events) that corrupts the whole system and makes it really tricky to get back a working version.
- emmelaich 27d ago
  It does (let you change history), but in a tamper evident way.
  - eru 26d ago
    It's two different ways to see the same thing. Basically, almost everything is immutable in git, apart from tags and branches: these are mutable pointers to immutable commits.
catlifeonmars 27d ago
As the saying goes, “when you have a screwdriver, everything looks like nail” <proceeds to hammer down the screws with the back of the screwdriver>

samuell 27d ago

> Why not put issues alongside the codebase? That's the idea of Epiq: https://ljtn.github.io/epiq/ https://ljtn.github.io/epiq/ > In my view, the main obstacle here is that without serious dedication, the user experience for humans would be a major downgrade. This isn’t insurmountable, but it would be a lot of work. I think Epiq does a decent job of addressing this. Take a look at the second animation on the page above. It even lets you "scrub" your way through the timeline to very quickly glance at what an agent (or junior developer) did to your code recently.

purplepatrick 27d ago

Methinks AI hasn’t been as successful in non-verifiable domains, because they are non-verifiable, not because there’s no version control…

ChrisMarshallNY 27d ago

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.

applfanboysbgon 27d ago
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.
- ChrisMarshallNY 27d ago
  I would hope they have ways to track those assets. They may be worth tens of millions of dollars.
  - applfanboysbgon 26d ago
    You would hope. I know of one case of an indie dev of an extremely successful, multimillion dollar franchise who did in fact lose everything related to the original game that made them successful, something which probably has cost them millions of dollars because they were unable to port it despite demand, and they've spent over a year recreating it from scratch.

theknarf 27d ago

https://www.inkandswitch.com/universal-version-control/ https://www.inkandswitch.com/universal-version-control/

emmelaich 27d ago

You could run rsync with -b --backup-dir=something-$(date +%Y%m%d.%H%M%S) every few seconds. Or fired off with inotify.

eturkes1 27d ago

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.

stabbles 27d ago

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.

gritzko 27d ago
Beagle indexes all the tickets within reach and shows them in one Excel-like view with buttons to manage their worktrees https://replicated.live/blog/click https://replicated.live/blog/click There is a port for plain git repos named Bee. That one is earlier-stage, but works https://github.com/gritzko/bee https://github.com/gritzko/bee

OroPla 27d ago

I am disappointed that the article doesn't talk about backups, which kind of are version control for everything.

dowonseo 27d ago

A pull request for a minor value change to an xlsx file doesn't sound so good

t4t5 27d ago

This is why I’m convinced we’ll see a lot more “plaintext-first” apps going forward. As agents take over more of our workload, it becomes increasingly important to store the data in a dumb and simple format that’s easy to diff and verify. I talked about some of this at LocalFirstConf: https://youtu.be/2ZEBH5Clrnc https://youtu.be/2ZEBH5Clrnc

timsehn 26d ago

I'm the CEO of a company that's focused on version control for structured data ie. SQL tables and JSON documents. We share the "version control for everything" vision and think an agentic world needs it. https://www.dolthub.com/ https://www.dolthub.com/