Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
17 check-ins for the month beginning 2023-12-01 by user andybradford
Following month ↑|
2023-12-17
| ||
| 05:49 | When resuming a clone, delete the previous setup user so it can be reset. This also handles the case where a new --admin-user is passed in. ... (check-in: b86d4da5 user: andybradford tags: clone-resume) | |
|
2023-12-08
| ||
| 15:30 | Limit the scope to the error condition to clone operations only for now. ... (check-in: 29e9e84a user: andybradford tags: clone-resume) | |
| 14:33 | Only output clone retry warning if there is another round to go. ... (check-in: bdd22578 user: andybradford tags: clone-resume) | |
| 14:20 | The rebuilt string is only regenerated if the manifest changes, so use the mtime of when the rebuild is done instead. ... (check-in: a92fddc0 user: andybradford tags: clone-resume) | |
| 13:52 | If the clone is interrupted by the user this should constitute an error condition. ... (check-in: 2c8ad9a4 user: andybradford tags: clone-resume) | |
|
2023-12-05
| ||
| 14:12 | Clean up signal includes. ... (check-in: e6da7f08 user: andybradford tags: clone-resume) | |
|
2023-12-02
| ||
| 18:30 | Use a new pragma requested only in the first clone cycle to track the rebuilt time on the remote server to be able to error out if the rids are rebuilt before resuming a clone. This is currently just a fossilized string but it could instead be a hash of the components to make it more like a "code". Requesting the pragma only at the beginning does not account for the possibility that a rebuild will happen after the clone begins. I find that scenario highly unlikely, but grant that it might be possible. If the remote server does not yet support the pragma the client falls back to using the remote server-code. ... (check-in: 7f116a43 user: andybradford tags: clone-resume) | |
|
2023-12-01
| ||
| 22:37 | Typo corrections in comments only. No change in functionality. ... (check-in: a8b6fdc8 user: andybradford tags: trunk) | |
| 21:22 | Just write the value the first time it is seen since there is no need to have the value during the sync (yet). ... (check-in: 15b166df user: andybradford tags: clone-resume) | |
| 21:14 | Prevent resuming a clone from a different server by preserving the remote server-code and comparing on resume. This is a crude heuristic to determine whether or not it is likely that the remote server still has the same rids. A better heuristic may be to probe the server for known rids that have been received (e.g. each clone seqno that is sent by the server could be recorded and then probed with a pragma request by the client later on). ... (check-in: aa54ea41 user: andybradford tags: clone-resume) | |
| 20:31 | Prevent the resuming of a clone that does not have the product code. ... (check-in: 63af8da3 user: andybradford tags: clone-resume) | |
| 20:17 | Minor style change. ... (check-in: d8207954 user: andybradford tags: clone-resume) | |
| 20:12 | Skip all finalizing until the clone is complete. ... (check-in: 9fa25cd7 user: andybradford tags: clone-resume) | |
| 17:55 | Try to handle some error conditions better. First, if the clone's first sync didn't bring down any artifacts there isn't likely any point in continuing. Second, if on resuming a clone no artifacts were received, abort. Third, check if the project-code has changed earlier (this might be detected even earlier when the client receives the "push" card). ... (check-in: 17f3408f user: andybradford tags: clone-resume) | |
| 04:12 | Minor correction in comment. No change in functionality. ... (check-in: 4fdc41bd user: andybradford tags: clone-resume) | |
| 03:58 | Shorten warning message to fit in a terminal without wrapping. ... (check-in: 5bb6d261 user: andybradford tags: clone-resume) | |
| 03:53 | Verify that the project-code on resume hasn't changed per discussion in forum post d1a2ed56271602fa and rollback changes if they are different. ... (check-in: ee5b9420 user: andybradford tags: clone-resume) | |