| Commit message (Collapse) | Author | Age |
... | |
| | | |
|
| | |
| | |
| | |
| | | |
them all
|
| |/ |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a better approach to finding both when NM has lost a network
connection, and when a new network connection is made by NM.
Tested with network-manager 0.9.8.8.
This commit was sponsored by Cedric Staub.
|
| | |
| | |
| | |
| | | |
This commit was sponsored by Cedric Staub.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
pulls.
For sync, saves 1 ssh connection per remote. For remotedaemon, the same
ssh connection that is already open to run git-annex-shell notifychanges
is reused to pull from the remote.
Only potential problem is that this also enables connection caching
when the assistant syncs with a ssh remote. Including the sync it does
when a network connection has just come up. In that case, cached ssh
connections are likely to be stale, and so using them would hang.
Until I'm sure such problems have been dealt with, this commit needs to
stay on the remotecontrol branch, and not be merged to master.
This commit was sponsored by Alexandre Dupas.
|
| |/ |
|
|\|
| |
| |
| |
| | |
Conflicts:
debian/changelog
|
| | |
|
| |\ |
|
| | |
| | |
| | |
| | | |
Data.Time.Calendar
|
| | |
| | |
| | |
| | | |
Avoid back-to-back runs.
|
| | | |
|
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ |
|
| | | |
|
| | |
| | |
| | |
| | | |
The tarball on hackage will no longer correspond to the git tag. Oh well.
|
| | |\
| | |/
| |/| |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
candidate cn be found in next hundred years
Note that the exception thrown is not visible in the webapp currently
because it crashes one of Cronner's 2 worker threads, which is never
checked.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is supposed to look for a day past the last day it ran, not a month
past.
Seems to work, at least in anarcat's test case.
|
| | |\
| | |/
| |/| |
|
| | | |
|
| | |\ |
|
| | |/
| |/| |
|
| | | |
|
| | | |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | | |
and the last time the job ran was a day of the month > 12. This caused a runaway loop. Thanks to Anarcat for his assistance, and to Maximiliano Curia for identifying the cause of this bug.
|
| | | |\
| | | |/
| | |/| |
|
| | | | |
|
| | | |\
| | | |/
| | |/| |
|
| |/ / |
|
| | | |
|
| |\ \ |
|
| | | | |
|
| | | |\
| | | |/
| | |/| |
|
| |/ / |
|
| | |\
| | |/
| |/| |
|
| | |
| | |
| | |
| | | |
Closes: #744148
|
| | |\
| | |/
| |/| |
|