3 ms·
It looks to me to be a continuous replication backup solution masquerading as a DVCS. Combining them is problematic in the real world because of local noise oth
by banish-m4 2y ago
It looks to me to be a continuous replication backup solution masquerading as a DVCS. Combining them is problematic in the real world because of local noise others don't need to see and of inadvertently committing secrets and temporary large files. The storage and networking demands for this would be enormous.
- SBArbeit 2y ago> inadvertently committing secrets Devs already do this all the time. That's why GitHub has Secret Scanning. The need for that kind of service doesn't change if the VCS changes. > temporary large files Saves in Grace are ephemeral, so those files will be deleted when the save references are deleted. There is a repo-level setting for how long that is, current default is seven days, but we'll see what makes sense. > The storage and networking demands for this would be enormous. Fortunately, Azure Blob Storage and AWS S3 and Google Cloud Storage are effectively infinite compared to any requirements from a version control system. I've only written the Azure Blob Storage implementation so far, but the idea is that Grace offloads all file upload/download traffic to those object storage services, using Azure SAS tokens [1] or AWS Presigned URL [2], etc. [1] https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview https://learn.microsoft.com/en-us/azure/storage/common/stora... [2] https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareO...