Remote log sync (WIP) #69
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Prepping for some basic syncing
Had to switch to `cd` cause of the &&, but this also now does the `tail` on the remote server, which saves (a very small amount of) bandwidth
Bah, meant to amend this to the last, not sure how it slipped through
`$retrothresh` isn't applicable here, fixes syncing for quick (<`$retrothresh`) jumps between computers. Should be harmless, if there's updated pings it'll pull them in, otherwise will fill in or prompt as normal
|
Nice. |
Now, closing the window without saving should backfill from remote, instead of backfilling locally and then uploading Haven't tested this yet though
This was causing ERR pings when running from systemd
Missed this when moving into a function
Also fix backtick-and-system nonsense
Also move awk script into its own file and fix silly path error
Avoids depending on file modification time, which is unreliable
|
Thanks so much for writing this, @cincodenada! If it's been working nicely for you for the past month I'm sold on merging it! |
Now that we're using it in the daemon
In case we exit/are killed first...this shouldn't be necessary, but I seem to be dropping log messages, so...
This shouldn't be a silent failure
This should fix the erroneous err bug
The previous warning strategy was not effective because a) the user can't do anything from an editor to resolve this and b) the error messages weren't going to the file anyway, so it showed an empty file So now we just check for the presence of a merge file (if all goes well it will be cleaned up afterward) and throw up a big ol' warning if it exists
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a WIP, but I'm dogfooding it right now. Currently disabled by default, activates once you fill in
$remote_idin settings. Throwing up this PR cause it's in MVP stage and thus good enough for some preliminary feedback.So what's it do? Well, with the (rather generous) assumption that you have somewhere you can
scpto, this implements a very basic remote-sync and backup capability for TagTime logs. I added two extra bits intolaunch.pl(with concordant additions tosettings.pl) that accomplish the following:After any successful
launch.pl, TagTime copies its log up to a remote server, tagged with$remote_id, a user-specified machine-specific string to distinguish it from any other instances, so that any instance can access any other instance's log.Then, when launching, if there's a gap between the last logged ping and now, before filling it in with RETRO, it tries to pull down the latest (by modification time) log from the specified remote server, which was presumably previously uploaded by a different machine. It fills in the gap with pings from that file as well as it can, updates
$nxtpingtaking the new pings into account, and then proceeds as usual.I'll find out soon enough (and let y'all know) if I've missed anything obvious, but I believe this should accomplish my goal of being able to hop between computers without any manual logfiddling, and as a bonus, would even automatically recover from your log (or TagTime folder) somehow being wiped.
There's a small gotcha currently: if you are on computer A, leave it running, switch to computer B, answer some pings, and then return to A, you have to kill the politely-waiting
launch.plon A, lest it upload its stale log after you close the editor. I may add further checks to avoid this, but killinglaunch.plis easy enough for me as of now. If you turn off/sleep A, there's nothing to worry about, as it will pull the updated logs when it wakes back up.Obviously, caveat emptor, make sure you don't upload your logs to publicly-accessible places if you don't want to, I tried to make it as non-destructive as possible but I'm not responsible if it eats your logs and your mother's logs, etc etc.