git-annex (5.20131127) unstable; urgency=low

  * webapp: Detect when upgrades are available, and upgrade if the user
    desires.
    (Only when git-annex is installed using the prebuilt binaries
    from git-annex upstream, not from eg Debian.)
  * assistant: Detect when the git-annex binary is modified or replaced,
    and either prompt the user to restart the program, or automatically
    restart it.
  * annex.autoupgrade configures both the above upgrade behaviors.
  * Added support for quvi 0.9. Slightly suboptimal due to limitations in its
    interface compared with the old version.
  * Bug fix: annex.version did not get set on automatic upgrade to v5 direct
    mode repo, so the upgrade was performed repeatedly, slowing commands down.
  * webapp: Fix bug that broke switching between local repositories
    that use the new guarded direct mode.
  * Android: Fix stripping of the git-annex binary.
  * Android: Make terminal app show git-annex version number.
  * Android: Re-enable XMPP support.
  * reinject: Allow to be used in direct mode.
  * Futher improvements to git repo repair. Has now been tested in tens
    of thousands of intentionally damaged repos, and successfully
    repaired them all.
  * Allow use of --unused in bare repository.

# imported from the archive

1 files changed, 24 insertions, 0 deletions

diff --git a/doc/design/assistant/blog/day_223__progress_revisited.mdwn b/doc/design/assistant/blog/day_223__progress_revisited.mdwn
new file mode 100644
index 000000000..9f899899d
--- /dev/null
+++ b/doc/design/assistant/blog/day_223__progress_revisited.mdwn
@@ -0,0 +1,24 @@
+Went out and tried for the second time to record a screencast demoing
+setting up syncing between two computers using just Jabber and a cloud
+remote. I can't record this one at home, or viewers would think git-annex
+was crazy slow, when it's just my dialup. ;) But once again I encountered
+bugs, and so I found myself working on progress bars today, unexpectedly.
+
+Seems there was confusion in different parts of the progress bar code
+about whether an update contained the total number of bytes transferred, or
+the delta of bytes transferred since the last update. One way this bug
+showed up was progress bars that seemed to stick at 0% for a long time.
+Happened for most special remotes, although not for rsync or git remotes.
+In order to fix it comprehensively, I added a new BytesProcessed data type,
+that is explicitly a total quantity of bytes, not a delta. And checked and
+fixed all the places that used a delta as that type was knitted into
+the code.
+
+(Note that this doesn't necessarily fix every problem with progress bars.
+Particularly, buffering can now cause progress bars to seem to run ahead
+of transfers, reaching 100% when data is still being uploaded. Still,
+they should be a lot better than before.)
+
+I've just successfully run through the Jabber + Cloud remote setup process
+again, and it seems to be working great now. Maybe I'll still get the
+screencast recorded by the end of March.