/stdhome

* perform update with conflict

* performing an "add", when the repo is not up-to-date (i.e., there are updates

   pending) just prints "stdhome add: bzr commit", with no other explaination as

   to what's going on

* add --all-files to `stdhome st` to show status of all files in repo?  or

   should we add `stdhome ls`?

* symlink substitutes don't acept a symlink in the repo and a directory on the

   FS (as well as the other way around).  Should they?  It means ~/src (which is

   a symlink in my home repo) shows as modified when compared to the symlink of

   the same name on oak.

* skip unchanged directories

   now that update, revert, resolve and init report on home dir changes, resolve

   and revert show all directories as being modified (because we always copy

   them out without checking for changes)

* add ~/bin/rebuild-tags!

* look at what need to be done before v0.1

* make the copy walker accept symlinks in place of files (as well as

   directories) if they are on the symlink accept list

* check that bin/quicktile.py on tims-laptop is an acceptable symlink

* !!! TAG 0.1 !!!

* check directory permissions before updating them

* during copy-out (not copy-in), show what is being changed with lines like

   "<SP><SP><OP><SP><FILE>" where OP is A (add), D (delete), M (modified) and K

   (kind change)

* currently, verbose print lines for bzr stuff are in the commands -- should

   they be in the bzr module?

* make the copy walker accept symlinks that differ if they are on the symlink

   accept list (so that symlinks can be pointed elsewhere in ~/)

* add code that can determine a relative file from a full file and a basepoint

* when ignoring files in the walker, populate the list of file more

   inteligently.  ".bzr" (and ".bzrignore") need to come from the VCS backend.

   ".stdhome", ".stdhomerc" and/or ".stdhomeignore" need to be converted to full

   filenames and then their relative file names derived from the configured home

   directory

* KNOWN ISSUE: handle renames as renames (rather than delete + add) because a

   directory renamed in the repo could contain other stuff that isn't versioned

   in ~/ which is lost, at the moment

* KNOWN ISSUE: decide on whether to implement remote --keep flag (see plan:483);

   currently, on the remote end, stuff deleted in repo during an update deletes

   files in ~/