Ævar Arnfjörð Bjarmason wrote: > There's surely other aspects of that square peg of large file tracking > not fitting the round hole of file locking, the point of my write-up was > not that *that* solution is perfect, but there's prior art here that's > very easily adopted to distributed locking if someone wanted to scratch > that itch, since the notion of keeping a log of who has/hasn't gotten a > file is very similar to a log of who has/hasn't locked some file(s) in > the tree. Actually they are fundamentally very different. git-annex's tracking of locations of files is eventually consistent, which of course means that at any given point in time it may be currently inconsistent. That is fine for tracking locations of files, but not for locking. When git-annex needs to do an operation that relies on someone else's copy of a file actually being present, it uses real locking. That locking is not centralized, instead it relies on the connections between git repositories. That turns out to be sufficient for git-annex's own locking needs, but it would not be sufficient to avoid file edit conflict problems in eg a split brain situation. -- see shy jo
Attachment:
signature.asc
Description: PGP signature
