22 ms·

Launch HN: Diversion (YC S22) – Cloud-Native Git Alternative

280 points by sasham 3y ago

Hi Everyone! We’re Sasha and Egal, co-founders of Diversion (https://diversion.dev https://diversion.dev). We’re building a modern, cloud-native version control. Our first users are game developers, who like its simplicity and scalability. See a quick demo here: https://youtu.be/DD0XkL8kDYc https://youtu.be/DD0XkL8kDYc 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 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 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!

parasti 3y ago
Focusing on Git seems like completely the wrong pitch. Git is a distributed VCS - in all your examples you were clearly trying to use Git in a centralized manner with no backups. I suggest focusing more on your own product than on Git.
- sasham 3y ago
  You're totally right, we were using BitBucket and pushing and pulling from there. It's really more of a centralized manner, but this is the usual workflow for most teams and companies and what they actually need (a single source of truth). Totally agree about backups, lesson learned :)
  - funcDropShadow 3y ago
    Until the day, the company is target by a ransomware group and everything is switched off in panic. Or the day the network connection of a building goes down. Requiring a REST api in the cloud for every VCS is command bytes hard then. We had this before with SVN and it wasn't nice.
  - solidasparagus 3y ago
    I want to add counter-feedback. I think focusing on git's weaknesses is really appealing. My background is more ML research and data and I viscerally connect with your pitch around both git's limited scalability and the complex/dangerous nature of git operations (ML researchers + git is not great).
    - TexasMick 3y ago
      Tbh they should really just learn it. It's super simple and powerful
  - IlliOnato 3y ago
    So it sounds to me as you are trying to create a replacement for BitBucket\GitHub and their ilk, not Git. This may be a worthwhile task. Maybe it makes sense to concentrate on this in your pitch. For 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.)

280 points by sasham 3y ago

parasti 3y ago

Focusing on Git seems like completely the wrong pitch. Git is a distributed VCS - in all your examples you were clearly trying to use Git in a centralized manner with no backups. I suggest focusing more on your own product than on Git.

sasham 3y ago
You're totally right, we were using BitBucket and pushing and pulling from there. It's really more of a centralized manner, but this is the usual workflow for most teams and companies and what they actually need (a single source of truth). Totally agree about backups, lesson learned :)
- funcDropShadow 3y ago
  Until the day, the company is target by a ransomware group and everything is switched off in panic. Or the day the network connection of a building goes down. Requiring a REST api in the cloud for every VCS is command bytes hard then. We had this before with SVN and it wasn't nice.
- solidasparagus 3y ago
  I want to add counter-feedback. I think focusing on git's weaknesses is really appealing. My background is more ML research and data and I viscerally connect with your pitch around both git's limited scalability and the complex/dangerous nature of git operations (ML researchers + git is not great).
  - TexasMick 3y ago
    Tbh they should really just learn it. It's super simple and powerful
- IlliOnato 3y ago
  So it sounds to me as you are trying to create a replacement for BitBucket\GitHub and their ilk, not Git. This may be a worthwhile task. Maybe it makes sense to concentrate on this in your pitch. For 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.)