From 629e95fd8eb1b1eda31c1412f2d5950092493c63 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 3 Aug 2021 14:03:25 -0400 Subject: [PATCH] update --- doc/todo/git-annex_branch_clocks.mdwn | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/doc/todo/git-annex_branch_clocks.mdwn b/doc/todo/git-annex_branch_clocks.mdwn index 563df28bc4..16a2724c30 100644 --- a/doc/todo/git-annex_branch_clocks.mdwn +++ b/doc/todo/git-annex_branch_clocks.mdwn @@ -63,8 +63,8 @@ into account. --- A better idea: When writing new information, check if the old -value for the log has a timestamp in the future. If so, don't use the -current timestamp for the new information, instead increment that future +value for the log has a timestamp `>=` current timestamp. If so, don't use the +current timestamp for the new information, instead increment the old timestamp. So when there's clock skew (forwards or backwards), this makes it fall back, effectively to vector clocks. @@ -74,3 +74,9 @@ of clock skew, the most recent change to a configuration wins. For state changes, it keeps the benefits of timestamps except when there's clock skew, in which case there are not any benefits of timestamps anymore so vector clocks is the best that can be done. --[[Joey]] + +(How would `GIT_ANNEX_VECTOR_CLOCK` interact with this? Maybe, when that's +set to a low number, it would be treated as the current time. So this would +let it be used and not, without issues, and also would let it be set to a +low number once, and not need to be changed, since git-annex would +increment as necessary.)