Re: Test Data for DigiKam

Gilles Caulier <[email protected]> Sun, 25 Sep 2022 12:00:42 +0200
Newsgroups gmane.comp.kde.digikam.devel
Message-ID <CAHFG6sHSkN-1PRhVZa1_gt3LERAfepy-jT=V9A=Fk5PA--Mtrg@mail.gmail.com>
Le sam. 24 sept. 2022 à 23:19, Steven Robbins <[email protected]> a écrit :
>
> Hello,
>
> In the interests of transparency, I have to say that I am unsure what to do.
>
> My original impression was that the decision was made to separate test and
> code and that the KDE sysadmins would have guidance on this.  That didn't turn
> out as I had imagined.
>
> After digging around a bit, my impression now is that the 7GB size of
> digikam's git repo is the issue.  As far as I can tell, the only way to fix
> that is to prune and re-write the repo.  That's not something I am highly
> motivated to do.
>
> Finally, I worry that separating data from code is going to place enough of a
> barrier to running tests that fewer will do so.  Testing is fundamentally
> important to me so this aspect is troubling.
>
> I don't really understand why Digikam has a 7 GB repo -- when the source
> tarball amounts to 300 MB (500 MB when unpacked).  I would speculate that
> there were things added then deleted in the past?
>
> Further, I wonder whether this can be handled more simply.  Atlassian [1] has
> a few ideas -- and maybe a git shallow clone for developers would help?
> Probably coupled with using GIT-LFS **in the main repo** for the large files.
>
> [1] https://www.atlassian.com/git/tutorials/big-repositories

This long tutorial is very instructive. I started to read, found some
help to checkout code for the CI/CD, but for the large binary files
history to purge in goal to reduce the repository size, i don't know
yet. The git prune can be a solution, but i never experienced...

Gilles