Merged be.restructure, major internal reorganization.

Added a bunch of classes to make the commands, user interfaces, and
storage backends more abstract and distinct.  This should make it much
easier to extend and maintain BE.

Features:
 * Directory restructured:
   becommands/ -> libbe/commands
   submods sorted by functionality.
 * Lots of new classes:
   Option, Argument, Command
   InputOutput, StorageCallbacks, UserInterface
   Storage
 * Consolidated ID handling in libbe.util.id
 * Transitioned VCS backends for Python-based VCSs from subprocess
   calss to internal python calls.

Plus the user-visible changes:
 * New bugdir/bug/comment ID format replaces old bug:comment format.
 * Deprecated support for `be diff` on Arch and Darcs <= 2.3.1.  A new
   backend abstraction (Storage) makes the former implementation
   ungainly.
 * Improved command completion.
 * Removed commands close, open, email_bugs, 
 * Flipped some arguments
   `be assign BUG-ID [ASSIGNEE]` -> `be status ASSIGNED BUG-ID ...`
   `be severity BUG-ID SEVERITY` -> `be severity SEVERITY BUG-ID ...`
   `be status BUG-ID STATUS` -> `be status STATUS BUG-ID ...`

In the merge:
  * Added 'commit' to list of pagerless commands.
  * Updated doc/README.dev

See
#bea86499-824e-4e77-b085-2d581fa9ccab/1100c966-9671-4bc6-8b68-6d408a910da1#
for a discussion of why the changes were made and some of the
difficulties en-route.

2 files changed, 91 insertions, 0 deletions

diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/body
new file mode 100644
index 0000000..d2ef28c
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/body
@@ -0,0 +1,77 @@
+Those are beautiful templates -- can you share those?  I'd love to
+study the HTML and CSS behind them.
+
+On Sat, Feb 7, 2009 at 5:48 PM, Steve Losh <steve@stevelosh.com> wrote:
+> Hey Chris, thanks for the comments.
+>
+>>
+>> My initial impression is that this looks good enough already to merge as
+>> a replacement for the turbogears site.  What does everyone else think?
+>>
+>
+> I'm not quite sure it's there yet.  There are a bunch of bugs I've got
+> marked as "beta" that I'd like to see fixed before it's ready for real use.
+>  Hopefully they shouldn't be too tough to fix.  You can point CFBE at itself
+> to see them.  :)
+>
+>> Could you explain a little about how you handle authorship of bug
+>> changes at the moment, and if it looks plausible to try making it
+>> multiuser?  (Having it handle more than one "user" logged in at once.)
+>>
+>
+> That's something I need advice on.  Right now CFBE is pretty much only
+> suitable for local use - you check out whatever you're working on and use it
+> as a local interface to the bugs in the repository.  Change those, check in,
+> etc.  It's effectively just a pretty version of the command line be tool.
+>
+> I haven't used CherryPy's session/authentication support before.  This might
+> be a good time for me to learn.  One way it might be able to handle multiple
+> users hitting a central server:
+>
+> * Each user has to register with the server and be approved by an admin.
+> * Each account would be mapped to a contributor string, the same one that
+> would show up if you were going to commit to the repository.
+> * Once you have an account, you'd login to make any changes.
+>
+>
+> Aside from all that, I'm a little fuzzy on how a centralized interface to a
+> distributed bug tracking system should work.  A read-only interface to a
+> central "main" repository would be easy.  Run the server in read-only mode
+> pointing at the main repository.  People can use it to look at the bugs in
+> the tip of that repository.
+>
+> If it's not read-only, what happens when a user changes/adds/whatevers a
+> bug?  Should CFBE commit that change to the repository right then and there?
+>  Should it never commit, just update the bugdir and let the commits happen
+> manually?
+>
+> What happens when you have multiple branches for a repository?  Should there
+> be one CFBE instance for each branch, or a single one that lets you switch
+> between branches (effectively switching between revisions)?
+>
+> Those are the kind of things that don't really apply when CFBE is just a
+> local interface to a single repository.  If anyone has any advice on how a
+> multi-user interface should work I'd love to hear it!
+>
+> --
+> Steve Losh
+> http://stevelosh.com/
+>
+>
+> _______________________________________________
+> Be-devel mailing list
+> Be-devel@bugseverywhere.org
+> http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
+>
+
+
+
+-- 
+Matthew Wilson
+matt@tplus1.com
+http://tplus1.com
+
+_______________________________________________
+Be-devel mailing list
+Be-devel@bugseverywhere.org
+http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/values
new file mode 100644
index 0000000..ca3efd0
--- /dev/null
+++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/d9959864-ea91-475a-a075-f39aa6760f98/comments/1f25cba2-03ee-43e1-a042-ef6724938ad8/values
@@ -0,0 +1,14 @@
+Alt-id: <f6f643a20902071531y6aa3d7a6k7c5a4bd4aa5a04f6@mail.gmail.com>
+
+
+Author: Matthew Wilson <matt@tplus1.com>
+
+
+Content-type: text/plain
+
+
+Date: Sat, 07 Feb 2009 18:31:04 -0500
+
+
+In-reply-to: 21c90231-d7f2-49bb-97d9-99e16459d799
+