Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative
Why a new VCS? There is no doubt that Git vastly improved our lives, and played a significant role in the advancement of software development over the past 18 years. But - it was built for a very different world in 2005 (slow networks, much smaller projects, no cloud), and is not the perfect tool for everyone today.
The biggest drawback of Git is its limited scalability - both in repository and file sizes, and the number of concurrent users. This is the reason Google and Meta built their own version control systems. It’s also the reason why other large companies, most notably in games development, semiconductors and financial services are still using legacy tools like SVN and Perforce.
Another issue we’re trying to fix is Git’s famous complexity. In our previous startup, a data scientist accidentally destroyed a month’s work of his team by using the wrong Git command (EDIT: we were eventually able to restore from a non-updated repo clone, after a few hours). As a developer who used CVS and SVN before Git was created, I often wondered why Git is so difficult to learn, compared to other tools.
On the other hand, Git’s branching and merging abilities are exceptional - this has enabled the modern software development methodologies that we all take for granted today (e.g. feature branches, CI/CD), greatly improving developers’ velocity.
We were wondering - is it possible to create an easy-to-use, fast, scalable version control system, with Git’s branching capabilities? And what else can be improved, while we’re at it?
One thing available in modern cloud tools is real-time collaboration (e.g. Google Docs, Figma). While developers don’t necessarily want their work in progress to be visible to everyone, it may be very useful to easily share it when you want to get feedback before a commit, to detect and prevent merge conflicts, and to have visibility into which parts of the codebase are being changed by others.
Diversion is built on top of distributed storage and databases, accessible via REST API, and runs on serverless cloud infrastructure. Every repository operation is an API call (commit, branch, merge etc.). The desktop client synchronizes all work in progress to the cloud in real time (even before a commit). Users can work with Diversion using an interactive CLI, Web UI, or IDE plugins (currently JetBrains, more coming soon). The Web UI allows to perform most basic operations, without needing to install a desktop client.
Diversion is compatible with Git, and can synchronize with existing Git repositories (each new commit in Diversion goes into Git, and vice versa). We’re planning to release it as open source once the code base matures, and when we implement an open source repositories directory on our website (naturally, Diversion’s code is managed on Diversion!)
We’re in open beta, you can try it here (https://diversion.dev) (click Get Started). It’s completely self-service and there’s no need to talk to anyone, and it’s free for small teams (https://diversion.dev/pricing).
Building a version control is hard (as we have learned), and Diversion still has a long way to go. We are currently working on improving speed, CI integrations, plugins to IDEs and game engines, and other usability improvements. We would love to hear your thoughts and feedback on what we’ve got so far!
439 comments
[ 3.6 ms ] story [ 335 ms ] threadFor BitBucket\GitHub\GitLab and for workflows enabled by them Git is just an underlying technology. Some of the functionality of these services is implemented using Git commands very clumsily. Some Git commands don't make sense or are dangerous in such environment\workflow. Yet Git interface is fully exposed to the users of these systems.
(Despite your statements and example, Git commands are not dangerous in the sense that they can destroy information already pushed to the repo. However, as your example demonstrated, they are dangerous in the sense that to recover from them requires expert knowledge and capabilities.)
Git was designed to for truly distributed development, and it is great for that. A lot of projects use it though for a centralized development. Git the software is fully capable to support such development with proper configuration, but has arguably bad defaults for it, and the existing solutions seem to be half-assed (to tell the truth, I hate GitHub, but won't go into this right now).
For me in my work and personal use the fully distributed character of Git is not important, but being able to work offline is, crucially. I know it is important issue for many developers. With working from home being more and more widespread I'd think this issue becomes more important, not less. Not being tethered to your good internet connection, or being able to work during an outage is really cool :-)
(Before Git I would have 2 VCS applications installed on my work laptop, one working against central database that required internet connection, one fully local, with separate local database. Synchronizing them was a constant chore, a significant part of it I was not able to automate and had to do manually. Sill, it was worthwhile price for being able to work offline.)
While git is indeed a usability clusterbomb and there is massive space to improve, the problem above sounds like a devops failure. Git gives you all the tools to prevent such a disaster, all you have to do not give the root password of your CI server to any data scientist.
On the topic of your startup, I would very much like a lighter learning slope, where I can introduce regular non-coders to the benefits of source control, and still have the advanced brancing/merging/rebasing etc. for the wizards.
Non-coder users are actually an important use case for Diversion (like in game development where many/most users are artists).
To put it bluntly, this story does not sound credible. It's also one of the first things you say in the pitch, which taints everything you write later. I would suggest focusing on what you do well, not in making up stories about data loss with what you perceive as the competition.
(It's especially odd when Git isn't the obvious competition; Perforce is.)
Obviously this person had all the privileges required to force push the previous commit in order to save the day. The old adage of never fact-checking a good story holds true however. Not sure it's a good selling point though, by nerd sniping everyone to explain in detail what the actual problem was no one will read to the end.
You _really_ have to try to fuck up hard enough that everything is gone, it just might require even more arcane commands than what got you into a mess.
> You _really_ have to try to fuck up hard enough that everything is gone
...is still true when using git-lfs, which seems common when using large data sets.
We might add end-to-end encryption in the future (disabling some capabilities), if there's demand for it.
The incumbents need to cater to existing customers with a need to host their own servers for licensing reasons; but this forbids them from using cloud native features in the core of their products.
There may well be space for a newcomer to make a cloud only product targeted at the subset of studios that have the legal ability to use the cloud. Instinctively, there may be some useful features around large files which are possible in the cloud but impractical in an on prem environment.
You definitely have a point reg vendor lock, we've planned for this and Diversion will be able to run in any cloud and on-prem in the future (we are running it in containers now).
That said, for large game projects, it really is the only viable option.
I mean the nice UI and collab features are indeed improvements but I'm thinking more core git specific improvements.
[1] https://git-lfs.com/
>>it was built for a very different world in 2005 (slow networks, much smaller projects, no cloud)
Slow network: why is this a negative thing? If something is designed for a slow network then it should perform well in a fast network.
Mush small project: I do not agree. I can say that it was not designed for very very large projects initially. But many improvements were made later. When Micorosoft adopted Git for Windows, they faced this problem and solved it. Please look at this https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...
No cloud: Again I would not agree. Git is distributed so should work perfectly for the cloud. I am not able to understand what is the issue of Git in the cloud environment.
>>In our previous startup, a data scientist accidentally destroyed a month’s work of his team by using the wrong Git command
This is mostly a configuration issue. I guess this was done by a force push command. IFAIK, you can disable force push by configuration.
Edit: updated in the top text now!
This is ultimately a very weak pitching strategy. The first thing you convey to your potential users is insecurity--an insecurity that people won't choose your product over Git. And it's hard to want to buy something from someone that isn't secure enough about their product to pitch the product first, and answer questions/make comparisons after, as a form of clarification.
Alternatively, instead of doing a comparison to Git, you could start with a list of "have you experienced these Git issues? <list of problems>. Here's how Diversion improves on Git in this regard." In this case you're actually solving people's problems, rather than looking like you're grasping at straws to complain about Git and justify an alternative.
FWIW, I personally have 0 interest in a cloud-first version control. I like the cloud as a form of backup and syncing with team members, but I ultimately want a version control that works as well offline as it does online, and prioritizes the local experience.
The fact that they don't seem to fully understand working of Git (not on the level of Git developers, just the level of Git administrators/users) does not inspire trust in their competence to create a Git alternative.
Doesn't say a lot for git's usability.
Git is great in that it is flexible and powerful. But that power leaves some tools open to people who don’t know what they are doing… that’s the trade off.
(Now something that better handles non-code assets and large data files, I’d be much more willing to listen to that pitch.)
One is that the possibility of overwriting history / etc is a really powerful and useful feature, but one that should only be used with some consideration, hence being gated behind the scary '--force'. The fact that git provides one the ability to discard and overwrite commits for a ref shouldn't be an endorsement of doing so freely. I'm glad git has this capability though and any "git alternative" would be all the worse if it didn't provide it, IMO.
Two is that if the concern is git's usability - i.e. the "problem" here is that it's too "easy" for users to do destructive actions accidentally - well, there are ways to solve that other than to reinvent all of git. There are plenty of alternative git UIs already, and an alternative UI is a great way to be "wire compatible" for existing users but still help protect those novice users from footguns.
Though I'll say that "--force" isn't necessarily a "scary-sounding" option name unless you're used to Unix CLI naming conventions.
Further, the warnings git gives you about this are virtually inscrutable if you don't already understand what's happening.
A good interface to "blowing away history" would give you a brief summary of what will actually be gone, e.g.:
"If you go ahead with this overwrite, the following changes will be completely removed from the repo:
a3bf45: Fix bug in arg parsing 22ec04: Add data from 2024-01-17 scraper run ...
Are you SURE you want to completely destroy those commits? (Y/n)"
and if user says "Y", output should log all removed commits and also say:
"These commits can still be recovered until <date>. If you realize you want these back before then, run the following:
<command to restore commits>"
Generally, I think it's a mistake to put UI improvements in a secondary tool.
If there are issues that need fixing, get those changes in the canonical project, because layered patches on top will always be short of maintainers and behind the main project.
While there is a lot of user interfaces that could be improved, I believe the above have empirically been shown to be inferior to the alternative "re-run this command but add scary option to proceed".
Users habitually answer "Y" to questions like the above all the time. And certainly after a few times it becomes routine for anyone. But having to re-enter the command and type some a whole word like "overwrite", "force" or "i-know-what-im-doing" is a whole other roadblock. The example is especially ill-chosen to have Y as the default option.
Any operation in git that destroys so many commits will include a list of commits that is destroyed, similar to what is suggested here, and trying to push the resulting repository will say exactly how many commits will be removed, and require rerun with force option (together with the necessary privileges). So reality is already not far from what you suggest, but with more fail safes.
The clear warning about what commits will be lost is not at all how I remember force-push working.
That said, I usually use magit in emacs for git and understand the force options well, so I haven't actually looked at the standard push failure warning in years. Maybe I'm remembering wrong, or perhaps it's been improved in recent versions.
Multiple individuals with similar problems would tend to imply systematic inadequate training. Or the enterprise concerned adopting an inappropriately complex system for its intended userbase.
At least with git, every developer has a copy of the full history so full data loss is impossible really. What happens if this company folds? You're left with some proprietary repo that you suddenly have to workout how to self host.
It just doesn't make sense when compared to just learning git which is definitely the most fruitful thing a developer could learn at the start of their career.
I wonder how Diversion handles operations that possibly delete data. Whats their solution?
Actually those commits that you considered lost, were still stored on everyone's personal computer in your team. You just didn't know how to use `git reflog` to find them.
I'm trying to imagine how to generalize this to other products. I think if I state the competing product has negative feature X, but also intentionally get some details confidently incorrect or deliberately feign incompetence, you get a group of people confirming X.
Github rejected my commit as I had the wrong email address. I then had to try and work out how I delete a commit but keep all my changes so I could commit it all again but with the correct email address.
I'm not sure exactly what I did but in my ham-fisted experimentation I deleted the commit and restored my local copy back to the way it was before my commit, losing all my work that day.
What you describe would be 1 Minute of work and maybe 10 clicks with a very low probability of shooting yourself in the foot in Tower.
Git doesn't give you access to the server side reflog either. So it's of not much use if you don't control the server.
As for losing data with Git, the easiest way to accomplish that is with data that hasn't been committed yet, a simple `git checkout` or `git reset --hard` can wipe out all your changes and even reflog won't keep record of that.
Also Git has pretty awful behavior losing changes when one doesn't press "Save" in their IDE. Bad, bad Git.
It's what I end up doing manually anyway but why make a system where the default behavior is destructive and I have to remember every.
Not only is it quite careful about not losing data, someone actually took the time to make it spit out messages that not only describes what just happened, but also gives suggestions of what to do next depending on how the user wants to proceed. That adds a level of discoverability that is usually associated with dialog based guis. The quality of these messages can sometimes be surprisingly good, far from the Clippy-level helpfulness you sometimes see.
There are a few exceptions to the principle of not losing local changes, where you explicitly restore an old version of a file for example. But saying the default behaviour is destructive really gives a false impression.
But yes, you are absolutely right that a system to recover unsaved work is a good thing, but I would argue that it belongs at the editor level, not in a version control system. A user could have a number of files open that have local changes. The editor has a much better idea in which order changes were made, and which changes hasn't even been committed to disk yet.
Using their desktop apps, Pages, Keynote, Numbers, TextEdit, Preview, I never hit "Save". I just close the apps. When I come back, the windows reopen right where I left off.
I wish emacs did this. I honestly don't know what it would be like for a code editor to be "constantly saving". I guess I would adapt, but there are times when I do all sorts of changes and go "Ah, this isn't right" and just kill the buffer. The ultimate undo.
But there's a great feeling, to me, when I go to close the app (or shutdown the computer) and it just closes. No prompts, no warnings, just saves its state, shuts down, and comes back later. And with the ever popular "naming things" issue of computers, I have a bunch of just "Untitled" windows. They're there when I open the app, and that's all I need to know.
The nag factor and cognitive load reduction of that is just unmatched. "Just deal with it, I'll come back later, maybe, and clean it up". One less thing.
Neither is it the fault of your version control system, or any other system really, if you cannot access your server and are without backups.
If a feature can lead to actual unintended data loss, it should come disabled by default. Are there any other "unsafe by default" features in Git? What would be a sane general default that prevents unwanted data loss, and why is it the case?
Do people use it in an unsafe manner because they don't understand git and there lies a problem that could be tackled? yes.
With that, I don't think git has any feature that is unsafe by default.
Well, you just mentioned `--force`. It is unsafe by default. Git has a couple of flags to make it safer (`--force-with-lease`, `--force-if-includes`) but those aren't the default.
Obviously they've done it for backwards compatibility, but the fact that they haven't even added an option to make it the default is pretty lame.
I’d I never cared about historical state and mistakes, I wouldn’t need version control at all :)
If stackoverflow told them to break off the chainsaw safety tab there is no chance it would have been read first.
The commits that were overwritten by "force" are still there on the server. Any admin could recover them pretty easily. They're probably still present in the local repo of the person who ran "git push --force" too, as well as anyone else's machine who has cloned the repo.
The only way you'd actually lose data is if every single person who had a clone of the repo ran gc.
Or apparently if nobody knew about "git reflog" and nobody bothered to do a Google search for "oops I accidentally force pushed in git" to learn how to fix it.
Designing for resource-constrained systems usually means you're making tradeoffs. If the resource constraint is removed, you're no longer getting the benefit of that tradeoff but are paying the costs.
For example, TCP was designed for slow and unreliable networks. When networks got faster, the design decisions that made sense for slow networks (e.g. 32 bit sequence numbers, 16 bit window sizes) became untenable, and they had to spend effort on retrofitting the protocol to work around these restrictions (TCP timestamps, window scaling).
> This is mostly a configuration issue
git apologism :)
(FWIW I do agree with the rest of your comment, and I hope you forgive the slight joke. Product users, for any product are fallible humans. That might be fallible in accidentally deleting, or it might be fallible in forgetting to turn on the safety settings.)
Very seriously, something like this should not be possible in a source control system. Data integrity needs to be built in by design.
We enforce a strict pull-request squish commit with four eyes approval only. You can’t force push, you can’t rebase, you can’t not squish or whatever else you’d want to do. But we don’t pretend that is the “correct” way to use Git, we think it is, but who are we to tell you how to do you?
We take a similar approach to how we use Typescript. We have our own library of coding “grammar?” that you have to follow if you want to commit TS into our pipelines. Again, we have a certain way to do things and you have to follow them, but these ways might not work for anyone else, and we do sometimes alter them a little if there is a good reason to do so.
I don’t personally mind strict and opinionated software. I too think Git has far too many ways to fuck up, and that is far too easy to create a terrible work environment with JavaScript. It also takes a lot of initial effort to set rules up to make sure everyone works the same way. But again, what if the greater community decided that rebase was better than squash commit? Then we wouldn’t like Git, and I’m sure the rebase crowd feels the same way. The result would likely leave us with two Gits.
Though I guess with initiatives like the launch here, is two Gits. So… well.
Meh, this is overrated. We'd end up with 2 Gits, and over time just one fork would probably take over, based on marketing, PR, dev team activity, etc. The second one would probably still be around but used by only a minor part of the community.
Just because a thing has on paper many forks, does not mean those forks are equal. In fact, a situation with many major forks rarely survives the long term. See Jenkins vs Hudson, Firefox vs Iceweasel, etc. Most people will congregate towards one of the forks and that's it.
It is built into Git by design. Git keeps commits around for 90 days even after they’re “deleted.” This is why people who understand Git were so skeptical of OP’s claim. The point that Git is confusing still stands, however.
As an example, what if someone pushes:
- A private key or password - Copyrighted content - Illegal content
In cases like this, it needs to be possible to remove the bad commit from the repository entirely.
Git had much more edge when it was competing vs SVN and other centralized VCSs. With 10Mb networks (if you were in office) you could feel physical pain when committing stuff ><
Reg how Git is not perfect in the cloud world - check out GitHub's blog post here about their cloud dev environment, Codespaces https://github.blog/2021-08-11-githubs-engineering-team-move...
"The GitHub.com repository is almost 13 GB on disk; simply cloning the repository takes 20 minutes."
Moving 13GB inside your own cloud should take seconds at most. The problem is the way Git works, it clones your entire repository into the container with your cloud environment, using a slow network protocol. With Diversion it takes a few seconds.
Using git with bash is the best way to use git (:
It is not about bashing git; it is about anchoring your argument of why Diversion is a better alternative around git. You're basically taking your game/arguments to their playing field, and thus will have an uphill battle for mindshre.
Instead, consider reframing the playing field and mention git less (if at all). Something like "the future of version control is blah". Surprise us, talk to us about your vision for source control, or better yet, code and multi-discipline collaboration (e.g. between eng and design), etc.
> The problem is the way Git works, it clones your entire repository into the container with your cloud environment, using a slow network protocol.
What about git's network protocol is 'slow'?
I think I can also come up with a pretty simple experiment to prove or disprove this: 1. Fill a file with 13Gb of data and commit it. 2. Upload that to GitHub or wherever you want 3. Time how long it takes to clone and compare that to the real GitHub.com
You will find the one we made takes 'seconds' (or minutes, depending on your network connection), while the the GitHub.com will take some time.
So, same data, two different results? The difference in this experiment rules out the 'slow' network protocol as the difference maker. The real reason is that the GitHub.com repo will have hundreds or thousands of commits.
Basically, the difference is the commit history, because that's how git needs to work. Git stores the diffs for the entire commit history, not just the literal files at the HEAD. I don't know what the network protocol has to do with that.
They just forgot about shallow clones..
git clone --depth 1 https://github.com/github/docs.git 3.37s user 1.83s system 35% cpu 14.521 total
Not a scientific test at all, but the second one was literally 15x faster, wall clock time.
On Windows. On Linux Git still doesn't scale well to very large repos. Before you say "but Linux uses git!", we're talking repos that are much bugger than Linux.
Also the de facto large file "solution" is LFS, which is another half baked idea that doesn't really do the job.
You sound like you're offended that Git isn't perfect because you like it so much. But OP is 100% right here; these are things that Git doesn't do well. It's ok to really like something that isn't perfect. You don't have to defend flaws that it clearly has.
Linux also has the huge advantage of an ecosystem, tools and integrations. It is overkill for small projects and there are friendlier alternatives for those - but git wins because it is what everyone knows. Something aimed at the small number of large projects will suffer the same problem.
In terms of number of commits, Linux is probably bigger than most. In terms of storage size, almost any video game project will be significantly bigger.
It's no secret that git is very bad at handling large binary files.
Also if you vendor a few dependencies that quickly increases the size.
> On Windows. On Linux Git still doesn't scale well to very large repos.
All of Microsoft's solutions for git scaling have been cross-platform. Even VFS had a FUSE driver if you wanted it, but VFS is no longer Microsoft's recommended solution either, having moved on to things like sparse "cone" checkouts and commit-graphs, almost all of which is in mainline git today.
I also find it funny the complaint that git scales worse on Linux than Windows given how many Windows developers I know with file operation speed complaints on Windows that Linux doesn't have (and is a big reason to move to Windows Dev Drive given the chance, because somewhat Linux-like file performance).
https://git-scm.com/docs/git-config#Documentation/git-config...
Certainly true. But it's not clear at all how does the product solve these specific problems (they say "Painless Scalability" which sounds nice but did they try developing any 100+ GB projects with massive numbers of commits/branches on it?)
Cloud-native and running things on “EC2” are very different things.
https://github.blog/2021-08-11-githubs-engineering-team-move...
But honestly, you can ignore that, because Git doesn't even handle small amounts of binary files very well. Ignore multi-gigabyte textures and meshes; just the data model doesn't really handle binary files well because e.g. packfile deltas are often useless for binaries, meaning you are practically storing an individual copy of every version of a binary file you ever commit. That 10MB PDF is 10MB you can never get rid of. You can throw a directory of PDFs and PSDs at Git and it will begin slowing down as clones get longer, working set repos get bigger, et cetera.
The 300GB size of the Windows repository is mostly a red herring, is my point. Compared to most code-only FOSS repos that are small, it's crazy large. That kind of thing is vastly over-represented here, though. Binary files deserve good version control too, at the end of the day.
May I ask, how you use Git for your music? Since binary diffs are not really a thing, the main benefit I could imagine is simply having revisions of your files with you having to create folders or having files named "track01_test_final2.flac"
Yes! This is something many people wonder -- other than those who love git :) I used to love Mercurial and I still mourn its mostly-loss. So I welcome a new DVCS system that is friendlier than git.
> Diversion’s code is managed on Diversion!
This is a good sign.
> can synchronize with existing Git repositories (each new commit in Diversion goes into Git, and vice versa)
Can you expand on what this means please? Does it simply mirror, or is it feature-for-feature compatible? Is it a backup capability?
> still using legacy tools like SVN and Perforce
I won't argue re SVN, but Perforce? It's used in the game industry primarily for its excellent handling of binaries / large binaries. How well does Diversion handle that kind of thing -- multigigabyte data sets, frequently changing?
The site says large files are fine, but that's too vague for games, IMO. Large, frequently changing, binary-not-text hard-to-diff files?
Edit: one final question: why cloud only? Why not software that can be locally hosted, or hosted by (other) service providers? What if I love Diversion and want to run a Diversion setup on my own Linux box in a cupboard?
This allows a member of a team that works with Git to try Diversion, to keep backups, and to use GitHub Actions or other CI tools that work with git.
Answers like this also make me feel more confident / interested in the tech.
Also agreed git is terrible right now for version-controlling workflows in AI (I have a fairly large .gitignore file with S3-hosted things ever for my NextJS + FastAPI apps - pain in the butt
AI workflows are definitely a use case we are looking at in the near future. What types of files are you hosting on S3?
"Being able to get just the tip" is `git clone --depth 1`, isn't it?
I'd like to hear about how this happened. No one in the team heard of reflog?
Most studios will try to avoid locking themselves into another expensive, annoying VCS that they have no control over. There's good attempts at FOSS p4 replacements now, you need to do better if you want to stand out.
There are? Like what?
As a developer, doing things like "I only want this subtree of the stream" is hard. Virtual streams exist, but they have a (non-negligible) overhead on the server. It has some quirks due to it being 30 years old which make it... interesting, to work with sometimes.
They are wildly, wildly expensive though.
I am not a defender of P4, but for some reason I'm defending them in this thread. It's free for < 5 people [0] if you want a side-project indie game.
[0] https://www.perforce.com/products/helix-core/free-version-co...
If anyone is interested in my resuming them, let me know at contact at weedonandscott dot com
[0] https://www.reddit.com/r/vfx/comments/11s08ne/your_opinion_o...
[1] https://www.reddit.com/r/gamedev/comments/11s5haf/what_do_yo...
> Git does have problems, we’ve had processes fall over on projects, many times actually, but it’s always solvable.
Every team that I've worked on would replace that tool with someonthing more stable if it existed. It does for version control, and it's perfoce, which comes with a hefty license fee, and a _different_ set of problems.
The selling point of Pipetrack is the commutativity, but to echo the comments in those threads, I've never found myself wanting commutavity. In games I want a mainline branch, support for large assets, granular access controls, performant, shared global system, and a method to cleanly differentiate between wip changes and ready changes in a way that works with non-technical users, and won't be the highest individual line item per-user subscription we pay for. Unless the selling point of your tool fixes one or many of those problems, it's not going to help in games.
Honestly, I think we'd be better off on SVN than git most of the time, but the _tooling_ around git is far superior.
Are they being deceptive? I'm not sure I see it.
Can someone explain how is this possible? More importantly was there any git branching strategy and permissions?
I would start by talking about what is great about Diversion -- what it lets you do that you couldn't before.
Since you mention gaming and perforce I looked in vain to see if it supports binaries (a major limitation of git -- just simply not in its design space). "Binaries" can actually mean for some people compiled code -- not for me but I understand why people do it -- as well as images, data files, Word files etc.
Sounds like the second is scaling but you don't say what you mean by that. Git scales pretty well until either the repo & its history gets enormous or when there are a lot of people making simultaneous changes.
The realtime collab integrated with a version control mentality could be interesting -- a major problem with google docs is the lack of useful version control (even Word is better).
And why cloud native?
Once you've done that you need only briefly mention "why not just use git instead?"
The thought behind cloud native is that workloads and devtools and data are moving there, and we want Diversion to be the best choice for when everything is in the cloud. Besides that cloud storage and DBs allow us to build and iterate much faster, and worry less about scalability, data distribution & storage etc.
But we can also run Diversion locally / in a container, it just won't be as scalable.
You skipped Subversion/SourceForge. People forget but for about 5 if not 10 years, SVN was the biggest SCM in town, next to P4, P4 having more of a hold in the game dev world.
I did leave out the proprietary things like Perforce and Aide de Camp, Solidworks PDM and the various in house things. Life's too short!
And what even is cloud native? When "cloud native" isn't just marketing, it seems to have all sorts of different meanings.
You did talk a little (in a comment or your post I don't remember) that you can use various cloud APIs to integrate into other systems.
But at the moment, from what you're telling me "cloud native" is as interesting to me as how you format your source code.
VCS is sort of a solved problem like SQL.
it's like saying it's about time someone revisited those Javascript frameworks.
I agree that there's no reason to change just because something is older than some threshold. Bit I think the roughly 15 year cadence has reflected the time it has taken for a new VCS idea to develop and then become mainstream enough for its drawbacks to become annoying enough that it loops again.
Youre talking an extreme use case. Like saying we need to replace the shovel because it cant do what a bulldozer does.
Its miniscule fraction of GitHub repos have those issues like an incredibly small number mainly devoted to games or media.
UX is fine if you know it. SQL UX isnt ideal either.
(Personally, I would never use a proprietary cloud-only offering for version control.)
yeah, I have no idea who would want to replace a free, open, well-debugged, featureful, ubiquitous vcs with a closed, immature SaaS offering...if your sourcecode is valuable, you don't let a YC startup gate-keep it (sorry)
git has terrible ergonomics for newcomers, but UI is exactly what the various git forges solve
for experienced devs, git issues get internalized like the issues with every other tool
a more realistic approach is the jujutsu stuff google is working on...works WITH git to create a better workflow
If you really want to do cloud. Use git.