Files in the git-annex branch use timestamps to ensure that the most recently recorded state wins. This is unsatisfying, because it requires accurate clocks amoung all users. It would be better to use vector clocks, where possible, but it is not possible to use vector clocks for all information in the branch.

To see why vector clocks can't be used for some information in the branch, consider location log files. They are meant to reflect the actual state of an external resource. Vector clocks can ensure that a consistent state is agreed on by distributed users, but there's no way to guarantee that state matches the actual state.

For example, let's assume there's a vector clock consisting of an an integer, and an object is being added and removed from a remote by multiple parties. First Alice logs (present, 1), and then some time later, Alice logs (missing, 2). Meanwhile, Bob merges (present, 1) from Alice and then logs (missing, 2), followed by (present, 3). At some later point, they merge back up, and the winning state is (present, 3) as it has the highest vector clock. Is the content really present on the remote? Well, we don't know, Alice could have removed it before Bob stored it, or afterwards.

But, other information in the branch could use vector clocks. Consider numcopies setting. It's fine if the winner of a conflict over that is not the one who set it most recently, as long as a value can be consistently determined. So, the numcopies setting, and similar other configuration, is not trying to track an external state, and so it could use vector clocks.

How would these vector clocks work, and how to transition to using them without confusing old versions of git-annex that expect timestamps? A change to a log could simply increment the clock from the previous version of the log. This would make the new git-annex normally lose when a conflicting change was written by an old git-annex, but the result would be consistent, so that's acceptable.

Files that are related to external state need to continue to use timestamps. But this could still be improved. Currently, if the clock is wronly set far in the future, logs using those timestamps will win over other logs for a long time. This could break git-annex badly as there becomes no way to correct wrong information.

Experimenting with GIT_ANNEX_VECTOR_CLOCK, it looks like git annex fsck is able to recover from wrong location information being recorded with a far future timestamp. It replaces that timestamp with the current one. However, if that then gets union merged with a change to the same location log made in another repository, fsck's correction can be lost in the merge. Re-running the fsck will eventually get the information corrected, once a non-union merge happens. However, git annex fsck can't correct other logs, like remote state logs, if they end up with bad information with a far future timestamp.

There's a mirror problem of information being recorded with a timestamp in the past and being ignored. But, at least in that case, re-recording good information with the right timestamp will fix the problem.

Consider making git-annex ignore future timestamps (with some amount of allowance for minor lock skew). There are two problems, one is that currently valid information gets ignored, until it's able to be re-recorded. The second is that when the timestamp slips into the past, the old, invalid information suddenly starts being taken into account.

A better idea: When writing new information, check if the old 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.

This would work for both kinds of logs. For configuration changes, it's kind of better than using only vector clocks, because in the absence 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.)

The vectorclock branch has this mostly implemented. --Joey

done --Joey