Symirr TODO list
----------------

  symirr: ABORT: unexpected condition at smmerge.c line 135 (version 2.0.7)
  ABORT: unexpected condition at smxcomp.c line 161 (version 2.0.8)

  Got into a mess with the BOOKMARKS directory, because it was
    deleting it and recreating it every time, maybe due to switching
    between a real directory and symlinks 

  what happens when we symlink a file/dir, and a clash is detected; we
    have to rename WHAT exactly to the CLASH extension ... the
    original file?  the symlink?  both?

  bug in xtreediff syncing /cwrk; seems to get an 'X' and a 'END' at
    the same time in smxcomp.c:159; MAYBE FIXED NOW

  doing a lot of local commands, or sending/receiving a lot of small
    files, is slow because it requires a round-trip for each one.
    Send them in batches?  Speed it up some other way?

  write jot2man, to create a man-page
  write jot2bstxt, maybe
  get jot/ directory updated in symirr archive with new versions when ready

  test the -x and -p exclude options in test-suite
  test pax-output TGZs fully, test breaking all available ustar limits
  test symlink-handling more fully

  when symlinks are followed, and the destination directories have
    different modes, the chmug fails because it is trying to change
    the symlink and not the destination
  probably in general, following symlinks is not being handled
    correctly; for example for files as well
  maybe force an error return instead of a warning when a symlink to
    be followed is broken, since symlinks-to-follow are usually at the
    top level and should all be correct, and if not is because
    something is broken

  make -b the default, and have -n "no backups" option?
  add option --all-files?
  make *~ *.NO_SYMIRR be included by default, and have -X "standard
    exclusions" option

  smmapch coverage
  smmerge coverage (some cases)
  smxcomp coverage
  build up coverage testing suite
  eliminate all memory leaks

  maybe check history locally for a valid session, rather than
    remotely as at present ... ?  Makes fixing up easier ... maybe.
    Or check both ends?

  think about a better method than cached local-tree.gz and
    remote-tree.gz for accelerating transfer of remote tree
    (xtreediff), maybe doing something more symmetrical; xtree-rsync
    (see brain-dump) would do the job

  test-suite to show full profiling coverage, no memory leaks, and
    exercise of all rules

  when everything else is working very well, maybe add rsync-like
    syncing of large files and/or zlib compression

  maybe apply zlib compression to all large data transfers (files,
    trees), or for simplicity, maybe to the entire conversation; but
    then it is the same as using "ssh -C", except that we are more in
    control of sync-flush points -- so, maybe not so useful

  add machine name to CLASH names to make it easier to work out where
    a clash came from?  .CLASH-sunrise.uazu.net-XXXXXXXX

------------------------------------------------------------------------
