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

431–440 of 440 posts

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

#431

Post by sasham »

devaiops9001 wrote: post #428

Git works fine with petabyte-scale projects and handles 100+ gigabyte files totally fine with some modest scripting. For one of the projects I oversee a typical file size is about 8gb each and a handful are about 140gb. What we version with Git are a list of the files in ion (superset of JSON) so the 8gb files aren't "in" Git but just referred to via hashes by what is committed in Git. These files are accessed via Ce…

Interesting! So you basically implemented something similar to git LFS, correct?

Can I ask what's your usecase and why not use LFS instead?

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

#432

Post by sasham »

jrk wrote: post #426

I was curious to follow your development, but the lack of RSS feed for your blog means I basically can't.

Ooops! We built a new site and now it's broken. Thanks for flagging! Fixing, it will be available here: http://www.diversion.dev/blog/rss.xml

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

#434

Post by maccard »

oDot wrote: post #427
maccard wrote: post #425

Earlier quoted context omitted.

I don't read the replies here as a lack of interest, more as a lack of interest in the solution you've come up with.

I don't disagree, but usually when a solution doesn't fix a painful problem, people are almost disappointed after getting their hopes high. In those posts, the commenters give me the impression that they are mildly annoyed at best (or worst).

I can't speak for the VFX post, but I think the gamedev post shows the weaknesses of git in one line:

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

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

#435

Post by ColonelPhantom »

pas wrote: post #64
gumby wrote: post #60

It's about time someone revisited & reimagined version control. the previous generations each lasted about 15 years: SCCS/RCS -> CVS -> Bitbucket/git/mercurial -> ??? so I am glad to see this. 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 -- j…

??? might be https://pijul.org/ with its commutative awesomeness

It's worth mentioning that Pijul is largely based on the same theoretical model of Darcs, which actually predates Git. But Pijul definitely makes it a lot more workable, e.g. by solving the exponential (iirc) complexity merge that Darcs has.

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

#436

Post by kristjansson »

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.

Anything that cuts across submodule boundaries needs as many MRs as boundaries it crosses, conflicting submodule pointer updates in the main require additional MRs (in the submodules) to resolve and coordination between those MRs.

They're basically fine for slowly-moving dependencies, vendoring, etc. but they emphatically do not solve the large-org many-team coordination problems that monorepos are meant to solve.

FWIW, git is a great monorepo platform for 1-10m lines of code (Linux, $MY_JOB, ...). It's only the very largest scales (Windows, Google3, ...) or asset heavy cases (ML, game dev) that need special treatment.

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

#437

Post by vlovich123 »

weebull wrote: post #429
vlovich123 wrote: post #419

Earlier quoted context omitted.

Sorry no. CI and monorepos are at best tangentially related. Dependency tracking across repos is a PITA which inhibits code reuse - git sub modules suck as do whatever that alternative git submodule concept is called (subtree?). Code repos like Cargo and NPM can help but even still it’s an annoying dance to update dependencies in multiple downstream projects. And if there’s a code change you need to make, it’s a 3-wa…

That's exactly my point. Cross dependencies is exactly the problem I want CI to solve.

Like the CI system automatically push code commits updating downstream dependencies that reference the upstream repo? Or something else?

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

#438

Post by devaiops9001 »

sasham wrote: post #431
devaiops9001 wrote: post #428

Git works fine with petabyte-scale projects and handles 100+ gigabyte files totally fine with some modest scripting. For one of the projects I oversee a typical file size is about 8gb each and a handful are about 140gb. What we version with Git are a list of the files in ion (superset of JSON) so the 8gb files aren't "in" Git but just referred to via hashes by what is committed in Git. These files are accessed via Ce…

Interesting! So you basically implemented something similar to git LFS, correct? Can I ask what's your usecase and why not use LFS instead?

I just looked at git-lfs and yeah the approach is pretty similar. There may be a good reason either way, as far as I know it hasn't been explored.

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

#439

Post by vintagedave »

sasham wrote: post #346
vintagedave wrote: post #40

> I often wondered why Git is so difficult to learn, compared to other tools. 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…

Right now we're trying to get it to users who prefer something that just works, and don't want to think about hosting. But you can actually run Diversion in a container (that looses distributed storage and DBs, which means it won't be as scalable). Other providers would definitely be great, if we succeed in standardizing it like git.

Thankyou for this (and the other!) replies, much appreciate your involvement in the thread!

Answers like this also make me feel more confident / interested in the tech.

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

#440

Post by pmeunier »

ColonelPhantom wrote: post #435
pas wrote: post #64

Earlier quoted context omitted.

??? might be https://pijul.org/ with its commutative awesomeness

It's worth mentioning that Pijul is largely based on the same theoretical model of Darcs, which actually predates Git. But Pijul definitely makes it a lot more workable, e.g. by solving the exponential (iirc) complexity merge that Darcs has.

This is not true, actually. Pijul answers the question "how to model states so that conflicts are allowed (and hence modeled)", whereas in Darcs it is "how do operational transforms on patches alone inform us about conflicts"?
Post reply on HN