171–180 of 440 posts
Earlier quoted context omitted.
The pitch simply wasn’t true. Data was not destroyed and was restored hours later.
It's a pitch. The story has obviously been embellished and polished and condensed, ready public consumption. Being pedantic against it is not productive.
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…
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…
> 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 how long it takes to clone and compare that to the real GitHub.com
You will find the one we made takes 'seconds' (or minutes, depending on your network connection), while the the GitHub.com will take some time.
So, same data, two different results? The difference in this experiment rules out the 'slow' network protocol as the difference maker. The real reason is that the GitHub.com repo will have hundreds or thousands of commits.
Basically, the difference is the commit history, because that's how git needs to work. Git stores the diffs for the entire commit history, not just the literal files at the HEAD. I don't know what the network protocol has to do with that.
Quick note to say that discussions like this are asymmetric: the git aficionados are very sure about their opinions that it's fine. The people who believe git isn't great are unsure if perhaps they're holding it wrong or don't understand how to use it. So what you see in a thread like this is 90% posts strongly asserting that the OP is wrong while the potentially large number of people on the other side are scratchin…
> fwiw, I think they're pretty much right.
Is 'they' the strong posters or the head scratchers?
Wow, tons of classic hacker news feedback just like the "dropbox won't work" one [0]. And we know how that ended up. With the trend towards more and more non-devs writing code with the help of AI [1], I think you're absolutely correct with your assertion that something safer and easier than git is needed. The rest of the business case makes perfect sense too (git struggling with binaries and large files, massive code…
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…
Disclaimer: I am designing a Git alternative too. Maybe "cloud native" will have a pull for game companies, but I am not so sure. I think a lot of studios would want to self-host. "Git compatible" is an interesting phrase; does Diversion use the same type of backing store? If so, I am not so sure it will handle large files as well as hoped. I had to solve this problem myself, and I did, but it required a different st…
A VC would give you legitimacy to help you get the customers you need. What large customers are going to back you with their business unless they know there's some deep pockets behind you? There are few things more valuable than a business's source code, it encapsulates all of their business processes and is how all of the business's data is accessed.
Why would a company want to entrust you with this? How are you protecting against data loss, and the legal liability that comes with this responsibility (insurance, legal)?
Earlier quoted context omitted.
> but the whole team that fucked up hard IMHO. Multiple individuals with similar problems would tend to imply systematic inadequate training. Or the enterprise concerned adopting an inappropriately complex system for its intended userbase.
Or, git is both very complex and very useful, and a large portion of its users have a poor understanding of git but enough for it to be a useful tool. If you want to do source control (which you do), then you’re investing time into learning git and/or fixing git, or maybe using a project like this.
> 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 single large model) is the problem.
From the website I have no idea if this can do partial checkouts. I assume yes but its not stated at all.
> cloud native
A lot of studios want on-prem and self-hosted private cloud support. Cloud native is touted as a feature but details are left out. That has me wondering if some things don't work when I try to host on-prem or that its an afterthought.
Can I easily host this on my own k8s cluster? Its not stated. Cloud native doesn't mean it's on the internet
Another feature that artists like is file locking. P4 has it and git lfs actually has it too. The heavier usage of P4 streams and branches makes it hard use locks effectively these days. Merging something that was locked but now isn't is sticky business...maybe you guys solved that.
> File locking across branches - coming soon!
"coming soon"... so close.
Good luck to you guys but I think the pitch needs work.