Ask HN: What does the next evolution of version control look like?

[tawb]

What is next for version control? What works well about the current systems and what is starting to break with current software development practices?

I've been spending some time studying the history of different parts of my software stack I've used for years but did not know the background of. From my vantage point, it doesn't seem like many things have fundamentally changed about version control since the late-2000s, early 2010s, while many other parts of the dev stack have changed dramatically.

[paulrpotts]

I have used a number of tools for this: RCS, CVS, commercial tools like ClearCase, Visual SourceSafe, and Voodoo, as well as Subversion and Git.

Some of them had huge weaknesses evident from the start - for example CVS had little support for maintaining directory structures. The upside of CVS is that when things got screwed up, which they did often, I could go in and fix up the hidden files, since they were more or less human-readable.

Git seems to have the edge because it is reliable - I've never seen it crash - and because it can do just about anything I've ever wanted to diagram out. It's also very good about being able to roll back mistakes.

My beef with Git is the user interface. It's often still very hard to figure out exactly which command I need and the structure of commands, and their options, are often very non-orthogonal. Using checkout to branch is pretty much the simplest example I can think of. The fact that so many git commands have output that tells you what to do to fix the inevitable problem you're going to run into next is kind of a tell that the functionality is badly structured into commands. I have two "front ends" to Git - TortoiseGit if I'm on Windows, and Stack Overflow if I'm not.

If you've never heard of Voodoo, it was a commercial product for Mac and worked really well, with its concept of "orthogonal version management." I think this concept is still interesting: https://link.springer.com/chapter/10.1007/3-540-60578-9_4 It also had a feature I miss frequently, which is meaningful support for non-text files. Back when I was doing Mac programming I used this a lot.

The other one that I think has things worth studying is darcs. The Haskell source is quite amazing, although it has not really become popular in part because, at least when I last tested it, it was pretty slow. http://darcs.net/

I think Git's ties to GitHub are problematic. I know it's not required to use it with GitHub, there's the GitLab alternative, but it's the infrastructure that's been presented to me at my last few gigs. It has a lot of nice features but it encourages so much ceremony about the most minimal code change that it adds a lot of friction and it's easy to mistake activity for progress.

[tawb]

Thanks for the detailed reply! A bunch of interesting points, and many things for me to go dig into more.

I definitely agree with your points about UI and the ceremonies of our current version control system.

One thing I've been thinking about this morning is that maybe it isn't the underlying protocol that needs to evolve, but the user experience that sits on top of the protocol. As I've asked this question to many engineers in my network, most are satisfied with the technical performance of git and the problem it solves, and their pains are almost all on the UX and organizational layer.

[andsoitis]

> What works well about the current systems and what is starting to break with current software development practices?

What do you think?

[tawb]

My experience with git has been pretty limited to Github. I've been working on software for five years, and mostly full stack in small startup teams so I'm lacking some breadth of experience that I was hoping to find some more of on HN.

But a few things that have always stood out to me about the user experience of version control:

- Git allows us to work in parallel effectively on different branches, but when our whole team is focused on one set of interrelated new features, we spend a lot of overhead coordination time figuring out how to not create conflicts for eachother. So we can work in parallel, but not in real-time with eachother's changes. The multiplayer aspect of design in Figma comes to mind here.

- I and many folks at my level use github in much simpler way than many older coworkers do. I rarely touch anything that isn't basic branching, commits and merging

- As a very visual thinker, it took me a very long time to grok git and what I was doing. As I've worked with more devs who come from non-engineering backgrounds, I've found this pretty common

[andsoitis]

> when our whole team is focused on one set of interrelated new features, we spend a lot of overhead coordination time figuring out how to not create conflicts for eachother. So we can work in parallel, but not in real-time with eachother's changes

If multiple people work on the same code (interrelated new features) at the same time, it seems to me they would have to sequence their work (i.e. coordinate) so as to not step on each others' toes. Put differently, this sounds like the problem is inherent and won't be solved by technology.

[i2cmaster]

People were beginning to use more automation even before LLMs. The amount of spam eg renovate generates can be overwhelming. I think something will be done to separate human PRs from robot PRs.

[tawb]

Can you expand on that for me?

I know there are issues with open source projects getting a lot of spam PRs from folks trying to fluff their contributions on their profiles. I can definitely see that getting worse with AI systems, but I haven't been in these communities enough to be familiar with that pain myself.

[i2cmaster]

The people aren't so much the issue.

To deal with dependency churn, CVEs etc people have started setting up automatons to generate PRs. Those can generate a ton of them with minimal information about their real impact(unlike human PRs) and so going through them is not only a lot of work but the volume can be much greater. I'm certain people will begin adding LLM based automatons soon too.

Because of that I think the next big deal will be creating a separate class of changesets for machine suggested changes.

[tawb]

That's helpful context, thanks!

That's a super interesting take. The obvious thing is that the surface area of automation has improved and you can build a lot of tools to help with that, but you also need tooling to help deal with that overload of new automation - especially if your bandwidth is limited.