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