Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Version Control for Everything

tyoverby.com

Post reply on HN
Print view View original

11–20 of 55 posts

Re: Version Control for Everything

#11

Post by davethedevguy »

Klaster_1 wrote: post #4

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

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?

Re: Version Control for Everything

#12

Post by 2001zhaozhao »

cfjgvjh wrote: 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

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.

Re: Version Control for Everything

#14

Post by Klaster_1 »

davethedevguy wrote: post #11
Klaster_1 wrote: post #4

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

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?

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.

Re: Version Control for Everything

#15

Post by ammar_az »

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

Re: Version Control for Everything

#16

Post by XorNot »

Borg3 wrote: post #5
cfjgvjh wrote: 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

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

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.

Re: Version Control for Everything

#17

Post by PaulRobinson »

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.

Re: Version Control for Everything

#18

Post by samuell »

> Why not put issues alongside the codebase?

That's the idea of 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.

Re: Version Control for Everything

#20

Post by gmueckl »

DanielHB wrote: post #10
xyzsparetimexyz wrote: post #9

Earlier quoted context omitted.

Why not just fork git and make it better at binary files?

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…

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.

Post reply on HN