Repository navigation
[V3] Garbage collection - #1491
Conversation
|
Is it really necessary to perform garbage collection that aggresively? I would prefer a Git has a similar command, and performs GC from time to time itself. But it doesn't do so on every commit, rebase or whatever. |
|
Aggressive GC has some advantages when you do stuff like automatic tool
|
|
The first thing I have in mind is hopping between branches in Git repos. Maybe some more things which I'm not aware of right now. I can't say much about issues with FAKE, I never noticed a significant performance impact. But if I see it right, after this PR, Paket performs GC on every restore. Building in VS (or vanilla MSBuild) causes a restore for every project in a solution, if you do |
PR #1482 but rebased on v3
I've started on a proposal how we could implement garbage collection to clean up packages no longer needed in the
packagesfolder (and if possible the same forpaket-files). Addresses #1416.Since the packages folder is typically excluded from version control, we do not always have explicit information about a package being removed. What we do know is what packages are currently extracted in the packages folder, and what packages we actually expect to be there according to the lock file.
The proposed algorithm essentially goes through the subdirs of the packages folder, tries to imply group and package names, and drops all of these folders which we identify as a extracted package but are not known by the lock file (ignoring the version).
Questions: