tbzr code for discussion.

[Mark Hammond]

Hi all,
  I've pushed my recent Tortoise work to Launchpad
(lp:~tortoisebzr-developers/tortoisebzr/tbzr2-proto).  The intention is for
this code to be reviewed and discussed, agreement reached on a number of
issues, and then we can start moving towards a first version.  My hope is
that many of these can be resolved (or even implemented ;) after the
mini-sprint we are having in Sydney next week, but I welcome all discussion
before then.  I've included the README.txt from that branch for your
convenience.
 
Cheers,

Mark

This is very early - bits of it work, but lots of it does not.

To get started:

* set PYTHONPATH so bzrlib, and the 'tbzrlib' in this package are
referenced.

* Execute 'python tbzrlib\app.py' - this will start the 'cache process'
which 
  clients connect to.  The cache process doesn't auto-start upon request.

* To test things: execute 'python tbzrlib\cache\client.py hello'.  The 
  command 'goodbye' will shut the server down while the command 
  'file_status c:\path\to\directory 1' should print an integer status
  of the filename.

* To test the shell extension:
  - change to the 'shellext\python' directory.
  - execute 'python tbzr.py' - you should see a message telling you things
    were registered.
  - Install the latest TSVN - that will ensure the shared 'TortoiseOverlays'
    are installed which we depend on (our installer will arrange for this to
    be installed, but source code users are on their own!)
  - Execute a new instance of (say) notepad.  Select File->Open.  You should
    see the notepad process connect to the pipe server, and if you are very
    lucky, you may see icon overlays for files and directories under version
    control.
  - To see debug output from the python shell extension, register the
    extension using 'python tbzr.py --debug', then open Pythonwin's
    'Remote Trace Collector Tool' to see output from the Python code.

There are many many things which are still up-for-grabs and not set in
stone.
Many things have "quick-and-easy" implementations assuming that a better
strategy will be put in place.  Discussion of these is invited:

* Source directory layout.

  - Created a new library called 'tbzrlib' containing all server Python 
    functionality, including the "entry point" for the server
    process.

  - I've attempted to keep it VCS agnostic where possible and have
    largely succeeded - only 'app.py' (which is the above entry point)
    knows about bzr.  However, this means the name 'tbzrlib' is misleading 
    - maybe it should be 'tvcslib' and we move app.py out to 'bzrapp.py' -
    but where would 'bzrapp.py' live in the source tree then?

  - Is it too nested (eg 'cache' and 'pipe' subdirs, each with their own
    'tests' directory)

  - shellext\python is for the 'temporary' Python implementation, largely 
    copied and hacked from "TortoiseBZR", alhough it doesn't talk to bzrlib
    directly, but instead connects to a pipe..  Eventually this will be 
    replaced with a .cpp implementation in 'shell\???' (shell\src ?)

* User prefs: No framework for user-prefs are in place.  Registry doesn't
  really seem appropriate.  Reuse any of bzrlib appropriate here?  If so, 
  what? :)

* User extensibility: Similar to user-prefs, but we picture that in the 
  future users will be able to define their own commands for the context
  menu, for example.  Alternatively, they may be able to enable or disable
  selected builtin commands.  How to accomodate these?  Do we need/want a
  "plugins" concept?

* Too much logic in the pipe server: The pipe.server package should only be
  used for getting the bits off the wire, and leave the processing to
another
  module - but currently this is all in the bowels of the pipe itself.
  Possibility is to create a TCP server for testing and non-windows users, 
  which would be a testbed to refactor comms from logic.

* Logging:  In some places I've used 'note' and 'mutter' from bzrlib, but
  in others I've used the logging module directly.  I'm not sure it is
  appropriate to log to the bzr log: is it worth trying to reuse the bzrlib
  logging, or should we roll our own based around the logging module that
  is appropriate to us? (eg, the ability to have different log levels for
  different logs would probably help debugging the server app)

* Tests: test coverage is reasonable and uses the bzrlib.tests package.  
  However, it isn't integrated into the 'test runner' - how can I
  tell the bzr test runner to run the tests from my various tests dirs?

* Command-line options: use optparse module?

* Recursive status requests: currently we request the full recursive status
  of a tree as that is our only option.  While this works OK with the
current
  code, its not optimized for that case (ie, the code is optimized for only
  one directories worth of info coming back at a time.)  If we need to stick
  with this technique, the DirectoryCache should change to take better
  advantage of it (eg, the cached unit would become the entire tree, not
  a single directory.)