3 ms·

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 probab

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 even with a handful of customers. About technical matters, as a company I'd be very at unease to have all my code only in the cloud on somebody's else servers. At least with git there are dozens, hundreds, thousands of copies of any repository around the company. If GitHub or AWS close our accounts we can keep going on and move somewhere else.

monsieurbanana 3y ago
I agree that the "project size" argument doesn't make much sense, however size as in file size does. There are multiple methods to add support for large binary files in git, but none are great. With their focus on game developers, I imagine that's one of the primary use cases.
sasham 3y ago
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.
- pmontra 3y ago
  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.

monsieurbanana 3y ago

I agree that the "project size" argument doesn't make much sense, however size as in file size does. There are multiple methods to add support for large binary files in git, but none are great. With their focus on game developers, I imagine that's one of the primary use cases.

sasham 3y ago

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.

pmontra 3y ago
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.