[Aeolun]

I’m just waiting for the next VCS that brings significant changes.

We’d absolutely switch over if there was some feature we wouldn’t get elsewhere. But it’d need a couple of months/years of sustained advocacy.

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

[yjftsjthsd-h]

If they ever fix the performance issues and get a little polish, the patch-based DVCSs (pijul et al.) will be a great improvement in usability. If I were guessing, I bet on that as the next step (given the understanding that predicting the future like that is a fool's game).

[normie3000]

Patch-based like svn?

[yjftsjthsd-h]

Sorry, I didn't use SVN enough to answer that. Basically, they're distributed VCSs like git, but where git stores commits, that is, snapshots of what the files look like at a specific commit, patched-based VCSs in the darcs "lineage" store diffs. Obviously the end result looks similar - git gives you diffs by comparing commits, darcs replays diffs to instantiate what the files actually look like at any given time - but it (allegedly) makes it much easier to handle arbitrary merges and do things like maintain a branch that's just like another branch but with a single commit on top.