Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

291–300 of 440 posts

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

#291

Post by 0xbadcafebee »

I get that enterprises will buy anything with "Cloud" or "AI" in the name, but VCS doesn't have anything to do with the cloud. Lots of VCS's have had server-oriented architectures, well before Git.

I see a lot about the architecture and design here. This is a product smell: focusing more on technology than solving problems. Some nerdy people may be interested in it, but it all means nothing if the experience of those users isn't good. You want me to buy your product? Sell me on why the experience is better. How it's going to speed up dev time, reduce errors, make collaboration better. None of that will be improved by a REST API or distributed storage in your backend app.

I'm also not looking to change my development practice. If most of your features are only available in a browser, I'm not going to want to use it, even if it were better than what I do now. Meet the users where they are.

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

#292

Post by e12e »

myfonj wrote: post #234

Out of curiosity, are there any VCSs that operate on AST instead of plaintext lines? (Or is something like this being developed or proven impossible?) I guess it should be possible to cooperate on shared codebase without need for every contributor to check in and out text files following exactly the same formatting. Or even naming convention. Or even same language, provided all collaborators can transpile to and from…

I believe the smalltalk vcs Monticello work on a semantic level?

https://eng.libretexts.org/Bookshelves/Computer_Science/Prog...

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

#295

Post by stevelacy »

jayd16 wrote: 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…

Game dev here, totally agree.

File-locking across branches excited me, support for visual diffing of uassets would be insane. The platform screenshots as a git/github alternative didn't excite much interest as Plastic and Perforce are major players.

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

#296

Post by yjftsjthsd-h »

asimpletune wrote: post #172
sasham wrote: post #37

Earlier quoted context omitted.

Thanks! We're definitely not trying to bash Git, it's done a lot of good for software development and for sure is going to continue evolving. 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 de…

I'm not sure I understand this at all. > 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…

It is perhaps worth pointing out that if you don't need the history you can just `git clone --depth 1` and save the network transfer and disk space.

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

#297

Post by sasham »

hintymad wrote: post #282

> Cloud-Native Git Alternative Not sure if this is a good summary of the product. For one, cloud-native is an implementation detail, unless the company plans to sell the new VCS as packaged software instead of service. For two, I'm not sure how being cloud-native addresses any issue with my daily interaction with Git. > The biggest drawback of Git is its limited scalability I wonder how many people really has this pr…

Monorepos are indeed causing problems with git, and this is one of the main arguments against them (see [1]). Some companies are building their own solutions (Google, Meta), and some are splitting their monorepos because of these problems. IMO if a company wants to run a monorepo for their reasons, they shouldn't be limited by their VCS.

The technical details are for the readers who want to know, I agree it's not really important for the users (most of them, at least).

[1] https://medium.com/@mattklein123/monorepos-please-dont-e9a27...

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

#298

Post by Arelius »

hasty_pudding wrote: post #283
Arelius wrote: post #250

Earlier quoted context omitted.

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.

well then modularize your code better! git can handle large repositories there's no reason you should have a one terabyte repository unless youre Google or something with the money to write your own VCS. but if you want to pay for a nine developer team with a massive cloud infrastructure for something like version control.... go for it!!! I'm going to check back a year from now and see if products still exists

sigh So, in GameDev, art assets are as important to the final game as code. And is, just as important to be version controlled as code.

And sure, you can split it up between many different repositories, and call it modular But you're just adding complexity, and not really solving the core problem which is that a single version of an art assets can possibly be > 1G, and be a poor format to be stored delta-encoded, so each revision can possibly be nearly a full duplicate. (Yes, we can talk about the file formats being a poor fit for VCS, which is true, but GameDevs are just trying to make their product) And again, it's really important for game assets to be version controlled. And maybe Git isn't the best place for the assets to exist in version control, but we are in a thread about Diversion and not Git.

Now, don't get me wrong, I'm uncertain that Diversion will exist in a year when you check-back, But I can guarantee you that Perforce will, and if Unity doesn't continue it's trajectory of destroying everything it touches, Plastic should continue to exist also.

I don't even completely disagree, Diversion, P4, and Plastic appear to be a bad fit for code in comparison to git, and even in our studio we've taken a modular approach (gasp) and store our code in git, while using a better suited VCS for assets. But it doesn't change the fact that you are being very dismissive for something that you very clearly know nothing about, and clearly have far too much ego to even be interested in a legitimate dialog about.

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

#299

Post by badjuju »

Can I offer a suggestion - focus on non-code developer use-cases. It is still wildly difficult to integrate a VCS system into a document-based application, yet this could improve many, many engineering and science applications that rely on text files (simulation configurations, pre- and post-processing setups, semi-manual entry data-backed "dashboards", etc). This is a problem that really needs solving and I don't see anything out there that makes it approachable.

Having built this myself (hacked on top of git) for an engineering analysis platform in the Energy Space, I'd say a good UI (even simpler than GitKraken) and an "just works" integration would be a massive win.

Just my 2 bits.

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

#300

Post by foofie »

sasham wrote: post #297
hintymad wrote: post #282

> Cloud-Native Git Alternative Not sure if this is a good summary of the product. For one, cloud-native is an implementation detail, unless the company plans to sell the new VCS as packaged software instead of service. For two, I'm not sure how being cloud-native addresses any issue with my daily interaction with Git. > The biggest drawback of Git is its limited scalability I wonder how many people really has this pr…

Monorepos are indeed causing problems with git, and this is one of the main arguments against them (see [1]). Some companies are building their own solutions (Google, Meta), and some are splitting their monorepos because of these problems. IMO if a company wants to run a monorepo for their reasons, they shouldn't be limited by their VCS. The technical details are for the readers who want to know, I agree it's not rea…

> Monorepos are indeed causing problems with git, and this is one of the main arguments against them (see [1]).

The article is a disappointing read. It spends a lot of time talking about monorepos and how they spell all sorts of trouble. Yet, the article makes zero mentions of submodules as a way to get the best of both worlds.

Post reply on HN