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

361–370 of 440 posts

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

#361

Post by sasham »

anthomtb wrote: post #327

> cloud-native version control Just how "cloud-native" are we talking here? One chief selling point of git is that you are not reliant on a centralized server. You have remotes , yes, but if one of them goes down, you still get the entire project history. I am of the opinion that the software world needs to find something better than git. One of my major pain points as a lead are the inevitable, yet unpredictable, gi…

> Just how "cloud-native" are we talking here?

So we're entirely serverless, using distributed cloud storage and DBs. Basically Diversion is up as long as you don't have a major AWS outage (happens, but rarely).

> Not needing external servers for VCS is one of the things git gets right.

I agree in general. But the way most devs are using git today isn't really decentralized, everything is going into and out of GitHub/Lab. And the more often the better, because CI and merge conflicts. So I wonder if having a VCS that is decentralized in theory really important - taking into account the upsides of building in the cloud (scalability, distribution speed, collaboration etc).

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

#362

Post by osigurdson »

layer8 wrote: post #342
osigurdson wrote: post #319

Earlier quoted context omitted.

Why aren't these teams choosing something else then? If everyone on the team dislikes git, switch to mercurial or something else.

Because often it’s not the team that chooses, but tooling is instead standardized across the enterprise. And enterprises like to make the “safe” choice of choosing what’s most popular. And then there’s the whole aspect that you have to know some basic Git anyway to debug your way through the open source code you use (maybe not for JavaScript/NPM, I don’t know). Git also happens to currently be the most interoperable…

How did it get so popular if disliked by the majority of dev?

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

#363

Post by sasham »

0xbadcafebee wrote: post #291

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…

Totally agree, and the launch post could only be that long :) We're trying to build a better dev experience, and the tech is only a means to that end.

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

The CLI is the most complete interface. Web UI still can't do everything (getting there though).

Thanks for the feedback!

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

#364

Post by jitl »

hintymad wrote: post #306
sasham wrote: post #297

Earlier quoted context omitted.

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…

Having an effective monorepo at scale will also require an entire infrastructure to solve all the problems that a poly-repo must solve and more. In particular, - Partial download, as a monorepo will quickly grow too large for a single person to download. This is trivial for poly-repo but requires dedicated system for monorepo. - Dependency management. With a decently sized monorepo, one can't compile everything and t…

Polyrepo is such a pain in the ass though. At a smaller scale it's much, much nicer, and then when we get big enough to hit all those scaling problems, we'll be able to afford it by hiring a team of 3 to go implement Bazel/Buck2/..., and perhaps switching from Git to Diversion.

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

#365

Post by jitl »

carlthome wrote: post #314
kristjansson wrote: post #307

Earlier quoted context omitted.

Submodules are great, but they're hardly an alternative to monorepos.

Why not? Just want to understand.

Submodule workflows have a lot of overhead at review time. During development it's fine, you work with the fully materialized tree just like it's a monorepo. But once you need to submit your changes for review, how does that workflow look?

1. Commit in submodule A, then get it reviewed and merged as SHA 123

2. Update submodule A to 123, get it reviewed

3. Reviewer has feedback on usage of new API in submodule A

4. Make another PR on A, at commit 457. This time don't merge it since reviewer on main repo might have more feedback.

Monorepo:

1. Make PR to monorepo

2. Get review feedback

3. Push changes to PR branch

4. Merge

5. Update submodule to 456, push to existing PR

...??

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

#366

Post by stackskipton »

osigurdson wrote: post #362
layer8 wrote: post #342

Earlier quoted context omitted.

Because often it’s not the team that chooses, but tooling is instead standardized across the enterprise. And enterprises like to make the “safe” choice of choosing what’s most popular. And then there’s the whole aspect that you have to know some basic Git anyway to debug your way through the open source code you use (maybe not for JavaScript/NPM, I don’t know). Git also happens to currently be the most interoperable…

How did it get so popular if disliked by the majority of dev?

Because generally people picking the tools are not majority of dev. They are architects or Senior Developers who do enjoy learning new things.

Also, git generally does just work and most IDE/Source Control Systems take care of basic operation of pull/branch/commit/push/open PR.

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

#367

Post by osigurdson »

stackskipton wrote: post #366
osigurdson wrote: post #362

Earlier quoted context omitted.

How did it get so popular if disliked by the majority of dev?

Because generally people picking the tools are not majority of dev. They are architects or Senior Developers who do enjoy learning new things. Also, git generally does just work and most IDE/Source Control Systems take care of basic operation of pull/branch/commit/push/open PR.

I suppose. It might seem a bit perverse after all if the non-engaged, uninterested in coding, clock puncher devs got to make all the decisions.

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

#368

Post by pmontra »

sasham wrote: post #349
pmontra wrote: post #110

As this is a startup the competitors are GitHub, Bitbucket, GitLab etc. and not the underlying technology. That is a mean to a goal, making money or most probably a lucrative exit. > [git] was built for [...] much smaller projects, It was built for the Linux kernel. There are larger projects than that but how many? Of course if you manage to make them switch to Diversion and get paid for that you could be well off ev…

Thanks for the feedback! We're offering a private cloud option for large customers, from many conversations this is OK for most of them. And adding a daily backup to any location is actually very easy. > At least with git there are dozens, hundreds, thousands of copies of any repository around the company. This is actually a huge issue for large companies (data breach), that doesn't have a good solution with Git.

Well, that's risk mitigation.

However if a file touches a developer's machine it can be breached from there unless they do like banks with sensitive information: no internet, no USB, no anything. Kind of impossible to develop like that.

So... IDEs in remote desktops and local browsers to lookup for documentation on the internet? But then you still have to protect against screenshots of code and OCR. Or photos. You can't defend against everything because developers must at least read the code. It's like DRM for music and movies. There is always a loophole.

So, mitigation. If your customers pay for that, good for you. About me, I prefer a local/remote repository for my projects. My customers decide what they prefer, currently git but they don't have many alternatives.

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

#369

Post by layer8 »

osigurdson wrote: post #362
layer8 wrote: post #342

Earlier quoted context omitted.

Because often it’s not the team that chooses, but tooling is instead standardized across the enterprise. And enterprises like to make the “safe” choice of choosing what’s most popular. And then there’s the whole aspect that you have to know some basic Git anyway to debug your way through the open source code you use (maybe not for JavaScript/NPM, I don’t know). Git also happens to currently be the most interoperable…

How did it get so popular if disliked by the majority of dev?

Popular as in “everyone is using it”, not necessarily “everyone is fond of it”. How did Jira become so popular? The dynamics that lead to such outcomes are interesting, but hardly unusual.
Post reply on HN