aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2012-06-22 17:17:41 -0400
committerGravatar Joey Hess <joey@kitenet.net>2012-06-22 17:17:41 -0400
commit264dd38c6547406041adad4fea2c603d5a146a97 (patch)
treef355c1600433ee1c73101f3a7847d08b2279f7b7
parent153942cc6eb4e1ab5ae730261aa3266fd1b41721 (diff)
blog for the day
-rw-r--r--doc/design/assistant/blog/day_15__its_aliiive.mdwn33
-rw-r--r--doc/design/assistant/syncing.mdwn3
2 files changed, 35 insertions, 1 deletions
diff --git a/doc/design/assistant/blog/day_15__its_aliiive.mdwn b/doc/design/assistant/blog/day_15__its_aliiive.mdwn
new file mode 100644
index 000000000..10ef4ffe5
--- /dev/null
+++ b/doc/design/assistant/blog/day_15__its_aliiive.mdwn
@@ -0,0 +1,33 @@
+Syncing works! I have two clones, and any file I create in the first
+is immediately visible in the second. Delete that file from the second, and
+it's immediately removed from the first.
+
+Most of my work today felt like stitching existing limbs onto a pre-existing
+monster. Took the committer thread, that waits for changes and commits them,
+and refashioned it into a pusher thread, that waits for commits and pushes
+them. Took the watcher thread, that watches for files being made,
+and refashioned it into a merger thread, that watches for git refs being
+updated. Pulled in bits of the `git annex sync` command to reanimate this.
+
+It may be a shambling hulk, but it works.
+
+Actually, it's not much of a shambling hulk; I refactored my code after
+copying it. ;)
+
+I think I'm up to 11 threads now in the new
+`git annex assistant` command, each with its own job, and each needing
+to avoid stepping on the other's toes. I did see one MVar deadlock error
+today, which I have not managed to reproduce after some changes. I think
+the committer thread was triggering the merger thread, which probably
+then waited on the Annex state MVar the committer thread had held.
+
+Anyway, it even pushes to remotes in parallel, and keeps track of remotes
+it failed to push to, although as of yet it doesn't do any attempt at
+periodically retrying.
+
+One bug I need to deal with is that the push code assumes any change
+made to the remote has already been pushed back to it. When it hasn't,
+the push will fail due to not being a fast-forward. I need to make it
+detect this case and pull before pushing.
+
+(I've pushed this work out in a new `assistant branch`.)
diff --git a/doc/design/assistant/syncing.mdwn b/doc/design/assistant/syncing.mdwn
index 05c7483dd..4f29df945 100644
--- a/doc/design/assistant/syncing.mdwn
+++ b/doc/design/assistant/syncing.mdwn
@@ -11,7 +11,8 @@ all the other git clones, at both the git level and the key/value level.
that merges in received changes, and follow it by the part that pushes out
changes (sending them to any other remotes).
[The watching can be done with the existing inotify code! This avoids needing
- any special mechanism to notify a remote that it's been synced to.]
+ any special mechanism to notify a remote that it's been synced to.]
+ **done**
2. Use a git merge driver that adds both conflicting files,
so conflicts never break a sync.
3. Investigate the XMPP approach like dvcs-autosync does, or other ways of