As we are scaling up the deployment of many git repos, a partial clone (which is not a shallow clone) may help federatedcode clients to fetch just what they need.
The expected effects are ensuring each federatedcode client can clone, fetch and checkout exactly what they need out of the "fleet" of 1000's git repos and tens of millions of package PURLs, metadata, scans, SBOMs and more.
This is just a bunch of pointer to review and support the design of efficient partial sync of a decentralized PurlDB/vcio deployment through federatedcode and focusing only on a slice as the "packages of interest".
The git partial clone feature and sparse checkout features have been there for a while. See these doc:
The two are closely related to achieve expected effects, as explained most clearly by @mslinn :
Sparse checkouts allow you to restrict the files and directories that Git can retrieve from the remote repository. When sparse checkout is used with partial cloning, the two features work together so that not only is the size of the working tree reduced, but the Git object database also reduced in size, so that only the requested objects are fetched from the remote repository, on demand.
See also:
As we are scaling up the deployment of many git repos, a partial clone (which is not a shallow clone) may help federatedcode clients to fetch just what they need.
The expected effects are ensuring each federatedcode client can clone, fetch and checkout exactly what they need out of the "fleet" of 1000's git repos and tens of millions of package PURLs, metadata, scans, SBOMs and more.
This is just a bunch of pointer to review and support the design of efficient partial sync of a decentralized PurlDB/vcio deployment through federatedcode and focusing only on a slice as the "packages of interest".
The git partial clone feature and sparse checkout features have been there for a while. See these doc:
The two are closely related to achieve expected effects, as explained most clearly by @mslinn :
See also: