From a3000247b342fbc3a01813d899bc024d32715d9b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 22 Nov 2013 19:03:01 -0400 Subject: [PATCH] devblog --- doc/devblog/day_63__leverage.mdwn | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 doc/devblog/day_63__leverage.mdwn diff --git a/doc/devblog/day_63__leverage.mdwn b/doc/devblog/day_63__leverage.mdwn new file mode 100644 index 0000000000..57c64bd3ba --- /dev/null +++ b/doc/devblog/day_63__leverage.mdwn @@ -0,0 +1,23 @@ +The difference picking the right type can make! Last night, I realized that +the where I had a `distributionSha256sum :: String`, I should instead use +`distributionKey :: Key`. This means that when git-annex is eventually +downloading an upgrade, it can treat it as just another Key being +downloaded from the web. So the webapp will show that transfer along with +all the rest, and I can leverage tons of code for a new purpose. For +example, it can simply fsck the key once it's downloaded to verify its +checksum. + +Also, built a DistriutionUpdate program, which I'll run to generate the +info files for a new version. And since I keep git-annex releases in a +git-annex repo, this too leverages a lot of git-annex modules, and ended up +being just 60 easy lines of code. The upgrade notification code is tested +and working now. + +And, I made the assistant detect when the git-annex program binary is +replaced or modified. Used my existing DirWatcher code for that. The plan +is to restart the assistant on upgrade, although I need to add some sanity +checks (eg, reuse the lsof code) first. + +---- + +Today's work was sponsored by Paul Tötterman