[imiric]

The next big thing will be semantic code versioning. I.e. a tool that understands language syntax and can track when a symbol is changed.

There are already experiments in this area[1], but I don't think any are ready for mass adoption yet.

The fact that it's 2022 and we're still working with red/green line-based diffs is absurd. Our tools should be smarter and we shouldn't have to handhold them as much as we do with Git. It wouldn't surprise me if the next big VCS used ML to track code changes and resolve conflicts. I personally can't wait.

[1]: https://github.com/GumTreeDiff/gumtree

[pid-1]

You can use .gitattributes to set which program will be used to generate "diffs".

A new VCS isn't really needed.

[vineyardmike]

> The next big thing will be semantic code versioning. I.e. a tool that understands language syntax and can track when a symbol is changed.

Hmm maybe. I think this will come, but it may be more broken up through build tools that include this functionality, not a singular VCS. I think aggressive linting is starting to help with whitespace and formatting adding noise to diffs. We're seeing progressively more integrated build tools (Cargo, NPM, vs anything C/Java).

Personally, my bets are on the next VCS being more "workspace" centric as a next-step evolution. Any big change is going to come as we already change how we work. We're starting to see a lot of various tools that are basically VM/Container workspaces that you work out of. Cheap to spin up for each feature, instead of branching/pushing/pulling on one local repo. I think "thin client" reproducible workspaces are the next evolution.

What will VCS look like when everything is always-connected and (maybe?) cloud hosted? Maybe it'll allow "sharing" of workspaces, so you can build big features as a team (instead of feature branches being pushed/pulled). You'd certainly not store the "fat" history of changes locally, and big assets/binaries/etc would be better supported. Maybe it'll be built into one of these virtual workspaces as an overlay-fs, so its transparently auto-saved to a central store instead of manipulating the existing file system like git.

[ghoward]

In my opinion, it wil be both semantic code versioning and better support for versioning binary files.

It turns out, both kind of need the same things, and if you do it right, you get better merging with text than Git currently does.

Source: I'm working on the next big VCS. It's not Pijul, though.

[pdimitar]

Do you have any preliminary material to read through about this VCS?

[ghoward]

Just poorly written design documents. https://git.yzena.com/Yzena/Yc/src/branch/master/docs/yar/de... . I'm still hashing out the details of the diff and merge algorithms.

Not much else is done, unfortunately, because this VCS depends on some other software that I'm struggling to write.