Improve handling on monthly/yearly scheduling.
Code was still buggy, it turns out (though the recursion checker caught it). In the case of (Schedule (Monthly Nothing) AnyTime), where the last run was on yyyy-12-31, it looped forever. Also, the handling of (Schedule (Yearly Nothing) AnyTime) was wacky where the last run was yyyy-12-31. It would suggest a window starting on the 3rd for the next run (because 31 mod 28 is 3). I think that originally I was wanted to avoid running on 01-01 if it had just run on 12-31. But the code didn't accomplish this, and it's not necessary anyway. This is supposed to calculate the next window meeting the schedule, and for (Schedule (Monthly Nothing), the window starts at 01-01 and runs through 01-31. If that causes two back-to-back runs, well the next one will not be until 02-01 at the earliest. Also, back-to-back runs can be avoided, if desired, by using Divisible 2.
This commit is contained in:
parent
740788ccb6
commit
d955cfe78a
2 changed files with 13 additions and 10 deletions
6
debian/changelog
vendored
6
debian/changelog
vendored
|
@ -1,3 +1,9 @@
|
|||
git-annex (5.20140413) UNRELEASED; urgency=medium
|
||||
|
||||
* Improve handling on monthly/yearly scheduling.
|
||||
|
||||
-- Joey Hess <joeyh@debian.org> Fri, 11 Apr 2014 21:33:35 -0400
|
||||
|
||||
git-annex (5.20140412) unstable; urgency=high
|
||||
|
||||
* Last release didn't quite fix the high cpu issue in all cases, this should.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue