blog for the day
This commit is contained in:
parent
eb40227d15
commit
57fddd5cd2
1 changed files with 49 additions and 0 deletions
|
@ -0,0 +1,49 @@
|
||||||
|
Over Christmas, I'm working on making the assistant support direct
|
||||||
|
mode. I like to have a fairly detailed plan before starting this kind of
|
||||||
|
job, but in this case, I don't. (Also I have a cold so planning? Meh.)
|
||||||
|
This is a process of seeing what's broken in direct mode and fixing it.
|
||||||
|
I don't know if it'll be easy or hard. Let's find out..
|
||||||
|
|
||||||
|
* First, got direct mode adding of new files working. This was not hard, all the
|
||||||
|
pieces I needed were there. For now, it uses the same method as in
|
||||||
|
indirect mode to make sure nothing can modify the file while it's being added.
|
||||||
|
|
||||||
|
* An unexpected problem is that in its startup scan, the assistant runs
|
||||||
|
`git add --update` to detect and stage any deletions that happened
|
||||||
|
while it was not running. But in direct mode that also stages the full file
|
||||||
|
contents, so can't be used. Had to switch to using git plumbing to only
|
||||||
|
stage deleted files. Happily this also led to fixing a bug, where deletions
|
||||||
|
were not always committed at startup.
|
||||||
|
|
||||||
|
* Next, got it to commit when direct mode files are modified. The Watcher
|
||||||
|
thread gets a inotify event when this happens, so that was easy. (Although
|
||||||
|
in doing that I had to disable a guard in direct mode that made annexed
|
||||||
|
files co-exist with regular in-git files, so such mixed repositories
|
||||||
|
probably won't work in direct mode yet.)
|
||||||
|
|
||||||
|
However, naughty kqueue is another story, there are no kqueue events for
|
||||||
|
file modifications. So this won't work on OSX or the BSDs yet. I tried
|
||||||
|
setting some more kqueue flags in hope that one would make such events
|
||||||
|
appear, but no luck. Seems I will need to find some other method to detect
|
||||||
|
file modifications, possibly an OSX-specific API.
|
||||||
|
|
||||||
|
* Another unexpected problem: When an assistant receives new files from one
|
||||||
|
of its remotes, in direct mode it still sets up symlinks to the content.
|
||||||
|
This was because the Merger thread didn't use the `sync` command's direct
|
||||||
|
mode aware merge code.
|
||||||
|
|
||||||
|
One other interesting thing about file transfers in
|
||||||
|
direct mode is that they can sometimes happen before the git branch is
|
||||||
|
pushed and merged. When that happens the object is stored in indirect mode.
|
||||||
|
Happily the direct mode aware merger detects such objects and converts them
|
||||||
|
to direct mode.
|
||||||
|
|
||||||
|
* Noticed that when the assistant adds a new object for a modified direct
|
||||||
|
mode file, it neglects to update the mapping for old object, so it
|
||||||
|
incorrectly still maps that object to the file. That bad data could lead to
|
||||||
|
unknown buggy behavior.
|
||||||
|
|
||||||
|
This is complicated by a mapping only being maintained from objects to
|
||||||
|
files, but not a reverse mapping. To get from files to objects currently
|
||||||
|
requires querying git for the symlink target, which is relatively slow.
|
||||||
|
|
Loading…
Add table
Reference in a new issue