Previous sync revisions don't get removed.
JustMaris opened this issue · 7 comments
Hello.
I've just noticed that in our git-sync root folder, there are more than 10 revision folders besides the one that is symlinked. Is it possible to make it so that only 1 folder is kept beside the one that is symlinked or to have any control?
At the same time, another git-sync repo only has one folder. What could cause this difference?
We're using git-sync v.3.6.7
Git-sync tries to clean up, but I can imagine a few failure modes. If some part of the process were to fail (e.g.gets restarted) then i could see maybe it would not retry before it gets the next sink and it would lose some historical state. V4 is much more aggressive about cleaning up ancient history and actually has a feature specifically to keep a certain number of historical directories and no more.
V4 will even try to clean up a v3 mess. That said, it will only try to convert one SHA, so if you already have a leak, it might not help. I can look into that, maybe.
Do you have a chance to try v4 rc2?
Hello.
After updating to Gitsync 4.0.0, there is still the issue of having multiple worktress stored.
What is the feature to keep a certain number of historical dictionaries?
Help me understand the problem. Is it
a) I have (for some reason) a bunch of old v3 worktrees I do not want
b) v4 is leaving old worktrees behind when it shouldn't
c) I want to retain some number of historical worktrees
I don't know why v3 would have left old worktrees lying around - if we can reproduce it (or if you have full -v 6 logs) which capture that, I would be happy to look at it. If you are seeing v4 leave old worktrees around I really want to know (because I have tests that say it should not, but corner cases happen).
I cleaned up the folder where the git-sync does the sync.
There was some weird behaviour with symlinks, which I could test out later and provide you with some further information.
Currently, the issue seems to be that there are leftover worktrees left. In one case, I observed 20 folders.
I will observe this on Monday further and will provide you with more logs if this issue persists or it was some setup problem.
Thanks. I do have tests that prove trees are removed, but maybe you have some case that I don't test well in which it breaks. I'll be happy to fix such bugs!
Did a further investigation and the issue was related to a larger repo struggling to be managed by git-sync due to efs provisioning.
Now that the platform side is fixed, git-sync manages everything successfully.
Thanks for the update.