new salsa team: nvidia-team

[Luca Boccassi]

On Sat, 2018-01-20 at 19:01 +0100, Andreas Beckmann wrote:
> On 2018-01-20 18:43, Luca Boccassi wrote:
> > > Right, forgot that the original plan was to keep the tarballs in
> > > SVN
> > > -
> > > I'll go and look if git LFS is enabled on Salsa - I'm pretty sure
> > > GitLab supports it.
> > 
> > Did a quick test and it looks like LFS is enabled - committed a
> > binary
> > file in a non-default branch, pushed - then cloned a different
> > branch
> > elsewhere and it didn't download the binary until the branch was
> > checked out.
> 
> we should probably have one ${REPO}-tarballs repository for each
> ${REPO}
> with blobs, I don't think I want to mix them into ${REPO}
> IIRC there are nvidia-cg-tookit, nvidia-cuda-toolkit and
> nvidia-graphics-drivers. We should be OK losing all the nvidia-
> settings
> etc. tarballs.
> 
> I still don't see how a workflow could look like ... we need some
> kind
> of shallow clone by default with the option to retrieve older
> tarballs
> easily ... (and without losing the current bits)
> Having a subdirectory for each version may (or may not) be a good
> idea.

With git LFS it only downloads the asset "on demand", and only the
present content of a branch - so if we have a "tarball" branch in the
n-g-d repository, with only the current versions, only those get
downloaded, and only on checkout of that branch specifically (eg: just
git clone repo won't fetch the binaries as they are not on the master
branch). Does this sound like what you would like?

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20180120/5c39d7ad/attachment.sig>