Live data from Hacker News

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

news.ycombinator.com

241–250 of 440 posts

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

#241
post #5
post #2

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.

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 :)

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

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

#242
post #128

Earlier quoted context omitted.

> And why cloud native? And what even is cloud native? When "cloud native" isn't just marketing, it seems to have all sorts of different meanings.

We're using S3 storage, lambda and ECS compute, and serverless DBs. It allows us to build a scalable product much faster, and leverages cloud features like multizone backups and distribution without having to develop these ourself. It also allows fast transfer of data between Diversion and other cloud systems.

So basically not self-hostable.

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

#243
post #180

As a game dev I find the pitch unexciting. > git is bad we're better Honestly, a modern git lfs workflow is really smooth. I think it handles binaries fine. Show me cumbersome git feature and why this works better. You can't just tell me tools I use every day are unusable. I think the main pain of git is if you want to put everything in a single repo. Big isn't a problem, getting just what a I need (checking out a si…

Git LFS is a giant hack ontop of Git. Most game devs I know moved away from it over time (back to Perforce or SVN). It might seem okay at first - but deep into a project you'll want to rearrange/rename folders and keep history logs, and discover that Git LFS doesn't actually work like normal Git and your file history wasn't kept. Only once you start dealing with issues will you find all the weird hacks Git LFS does ontop.

I'd say Git not working well for game dev isn't a pitch that Diversion needs to make, because it's already clear to most game devs.

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

#244
post #177

Earlier quoted context omitted.

Git is bad for games and they should definitely compare them in their pitch if they want to capture that market.

No, it's not. LFS has improved over the years. Git is supported as a first class citizen in Unreal Engine 5 - alongside P4.

Just because it has integrations, doesn't make it great. LFS is still not great. Doesn't have a lot of backends for instance. And a real locking system is table-stakes for a gamedev VCS

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

#245
post #69
post #51

Being deceptive about Git's shortcomings is going to raise eyebrows with anyone seriously evaluating your solution, which is already going to raise eyebrows because it's not free software. 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's good attempts at FOSS p4 replacements now, you need to do better if you want to stand out. There are? Like what?

Yes Please. I would switch my studio today if this existed.

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

#246
Little feedback on the "how is it different from Perforce" section of the web page.

There have to be more advantages than "it's in the cloud" ...right? Also, for many this is potentially a huge hurdle / disadvantage. Who are you, and why should we trust you with our precious IP / code? (many game studios are on-prem very intentionally)

Personally, I'm currently (being forced to) use Perforce and I've learned to tolerate it, but wish we could use git. There have to be more things that make your offering better than Perforce and you should really highlight them.

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

#247
Ok, I'll bite.

Looks interesting. My first thought, as a gamedev who has been in charge of selecting VCS at multiple studios.

1TB is not a lot, and I would really appreciate clear public pricing terms on data before committing to a VCS. Esp at the smaller indie scale.

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

#248
post #116

>> most notably in games development, semiconductors and financial services are still using legacy tools like SVN and Perforce I think this should be your elevator pitch. Don't focus too much on "git complexity" as most people already know git so it just creates an argument. Scalability, in terms of numbers of users is somewhat hard to argue as well (Linux kernel has 1000s of contributors). However, it is completely…

> Don't focus too much on "git complexity" as most people already know git so it just creates an argument. I'd say this phrase is both right and wrong. It's right in the sense that it creates an argument. It's wrong in that it creates an argument with the peanut gallery of git experts. But guess what, most people using git are not experts. They're software developers who don't want to learn the intricacies of git (pr…

> peanut gallery of git experts

There are people who use git for its original purpose (kernel devs and very few others) and then there is the remaining 99% of people who essentially use “github flavored git”, using only three or four git subcommands and for the most part never needing to understand its intricacies.

Unfortunately, although they are using git-the-chainsaw-shotgun with all the safeties on, it’s nonetheless a chainsaw shotgun and sometimes they’ll run into issues where they or somebody in their company needs to be an expert and figure out how to un-scramble an egg, so to speak.

If a new VCS can solve the 99% case and never need users to fall back to understanding nitty gritty details, it could very well have strong takeup especially among people who don’t give a crap about what VCS they’re using as long as it gets out of the way and doesn’t make them think (game devs, data folks, etc).

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

#249
post #16

I have not analyzed the full potentials and benefits of Diversion but I would not agree with the statements you made about the Git. I think you should not focus on Git in your pitch. >> 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. Mu…

The Windows Git repository is only 300GB, that's basically childs' play when people are talking about "large repo scalability". Average game developer projects will be multiple terabytes per branch, with a very high number of extremely large files, and very large histories on top of it. Git actually still does handle large files very poorly, not only extremely large repos in aggregate. The problem with large Git repositories is nowhere near solved, I assure you.

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

#250

Earlier quoted context omitted.

I don't think you understand the scale of large creative projects like games. The current (only medium sized) Unreal Engine project I'm working on has about 300k files in the head alone, and a fresh sync for the stuff only required to build/cook the game is about 350GB. If you add the raw content from things like Maya, substance Painter, brush, etc, it is well in excess of 1TB. Vanilla git just does not scale to this…

How niche is your use case? Despite all the questions I have about storing un-versioned large media files in Git instead of EC2 and your lack of good management about modularizing the code base and lack of build tooling....thats the use case I specifically stated in my post. The monstrosity that is Diversion could have great benefits for niche use cases like yours. i.e. large media file Version Control for teams who…

EC2 and a build script? Are you implying that the parents 1TB of assets are "un-versioned large media"? If so, I'm sorry you are being very dismissive about something you don't fully understand.
Post reply on HN