Try our conversational search powered by Generative AI!
AI OnAI Off
How to handle the zip-files in the modules folder using Git or other tools?
Hi Mattias
Git LFS is designed for this purpose and I think this is probably the most effcient way without affecting how developers are used to work on daily basis.
Mar 15, 2020 23:15
Mattias Andrén
- Mar 15, 2020 23:30
Yes, I have investigated that as a possible solution as well. However it does not full-fill the "requests" of not having anything in the repo that isnt our own source code. But as you mention, this might be required to not affect the devs current work on daily basis.
Mattias Andrén
- Mar 16, 2020 13:05
Thats not a great option since from my understanding, for each commit of the zip-files git would basically create a copy of the zip and the repo size could potentionally become very large.
valdis
- Mar 16, 2020 19:48
it has never been issue so far in my experience. I would say that you need to give it a try and adjust / change when you see that it's not working for you.
It's a good idea to avoid checking in binary files, zip files etc yes. I agree on principle.
The zip-files for Episerver only change when upgrading Episerver though, which you are likely to do only once or twice per year normally.
I have yet to hit the limit in any of my projects. Missing zip-files however is a common problem that takes time to troubleshoot and correct especially when setting up deploy scripts to production etc. So although I agree on the principle I personally make an exception for these to simplify deployment and onboarding new devs. Let me know if you find a better way :)
Mar 17, 2020 17:27
Mattias Andrén
- Mar 18, 2020 14:44
I have never had any issue with checking in the files either (infact thats how most of my projects handles this).. however, one of our team members didnt really like the idea of keeping binaries/large-files in the repo since as mentioned.. that could in theory slow down some operations when using git (one of them beeing clone), which is a valid point.. even if its highly theoretic. We ended up using Git LFS for the .zip-files located under /modules/_protected, this allows our devs to work as they are used to with git (with one minor exception that they might need to install git lfs if thats not pre-installed in whichever tool they are using for git), and it keeps the files neatly separated from the "normal" git repo and wont make the repo grow "out of controll" (overexadurated).
Daniel Ovaska
- Mar 18, 2020 16:36
Fair enough. Just remember to fix the automatic deploy as well then to check out zips from LFS .
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
Hi!
My colleague and I have discussed for serveral days how to handle the zip-files thats provided by EPiServer and by default "installed"/located in the /modules/_protected/xxxx/ folder(s).
Our current SCM is Git, however.. Git is not really supposed to handle compressed or binary files, and especially not larger files. (like for instance Shell.zip which is 10Mb+).
So one of our ideas was to simply exclude the modules folder from our repository and then let NuGet re-download this during a package restore.. however.. it turns out that NuGet does not re-dowload any content-files during a restore, which then causes the "Publish-tool" in Visual Studio to not "function properly" since we are now missing files which should be included according to the .csproj, but they cant be found (and even if the publish would work, we would still be missing some crucial files for EPiServer to function properly).
Another thing that comes to mind is that we could of course extract all the files thats zipped, and then just treat them all as a part of our source-code.. but I guess that could make an upgrade somewhat harder than just "Install-Package EPiServer.Cms -Version {next version}".., and besides that.. a recommendation is to not have any source code except the one you have written yourself handled by Git.
Is there any "neat" way to handle this problem?
We also dont want to affect how the developers are used to work with .Net and EPiServer too much, since that might slow down the developing process or make it harder to introduce new members to the team.