Thanks for the feedback! We do hear that remote artists with flaky network connections is common, and plan to address it in several ways like CDC (a method for efficient chunking and diffing of binary files to minimize network transfer and storage duplication), local network caches or peer-to-peer transfers. Private cloud deployment or on-prem with SSO will also be available.
Decentralization is a cool concept, but didn't GitHub and BitBucket emerge because a centralized server was in demand? Git is a good tool for many uses, but when was the last time you pushed directly to a peer's repo on their machine? How many firewall and reverse proxy configurations did you have to setup to be able to do it?
It's kinda the standard procedure of securing your machine's ssh, I'd recommend trying to setup a bare repo and put it online so you see how easy it is to make it work, that's not Github but it's more than enough for your org, in fact before Github was created that's how we did it, it doesn't really take more than 1 afternoon to set it up, multi-user and all the other jazz.
But Github and Bitbucket aren't examples to compare Diversion to though, Github is just a node in the decentralized network of Git repos (your users, or whoever cloned). They even use an example of this feature, how they were able to recover after a mess-up, then with SVN that couldn't be done and they'd have really lose more than a month of work.
There's one of the reasons why Git was created, to make it easier to resolve conflicts, if you just want a main / children branches structure in one server then use SVN / Diversion but then don't complain when you have a branch "locked" and you cannot get your job done.
Diversion makes 100% sense if you follow the silly "one repo for the whole org" way big companies do, which still doesn't make any sense to me.
Indeed you're right the work that was erased from BitBucket was restored from one of the employees that didn't yet pull, the post was edited accordingly.
> the work that was erased from BitBucket was restored from one of the employees that didn't yet pull
Actually those commits that you considered lost, were still stored on everyone's personal computer in your team. You just didn't know how to use `git reflog` to find them.
The vast majority of version control system uses are not distributed, even if the system itself is (GitHub and BitBucket were born to essentially make Git centralized). An example use case is game studios having repos with very large histories (hundreds of GiBs and more) where the tip is significantly smaller. Having the entire repo history on your local machine might be infeasible, and usually unnecessary. Being able to get just the tip and get the rest via API calls solves this. Having things continuously synced has other benefits like preventing conflicts at the time they happen on files that are hard for conflict resolution like game scene files, graphics etc.
AI workflows are definitely a use case we are looking at in the near future. What types of files are you hosting on S3?
> An example use case is game studios having repos with very large histories (hundreds of GiBs and more) where the tip is significantly smaller. Having the entire repo history on your local machine might be infeasible, and usually unnecessary. Being able to get just the tip and get the rest via API calls solves this.
"Being able to get just the tip" is `git clone --depth 1`, isn't it?
And then you lose functionality, for example `git blame` depends on the history being available locally. If you want a working repository with all the source control features you need a regular clone. That's where "being able to get the rest via API calls..." kicks in :)
OK so `git clone --filter=blob:none`, then. That downloads the tip and commit history, but no historic blobs. `git blame` then works by downloading missing blobs on demand, which doesn't sound too different to making an API call.
All data is encrypted in-transit and at-rest, as per the industry standard. End-to-end encryption is an interesting feature with obvious extended privacy benefits on one hand, that could prevent a system from providing other features on the other hand. Depending on the requirement for end-to-end encryption, in some instances a custom NDA can be signed to mitigate a specific concern. It's a feature we haven't seen much demand for, but if that changes we may prioritize it higher on the road map. Would you mind sharing your use case or concern?
I think the question is "can any one outside my company/org access my code". Apparently it is because the tool offers cloud collaboration using web UI.
If you share your repository with a collaborator, they can access it of course. Same is true if you share your repository with end-to-end encryption, your collaborator should be able to decrypt and use it.
