Converted libbe.storage.vcs.base to new Storage format.

1 files changed, 0 insertions, 123 deletions

diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/body
deleted file mode 100644
index 9bf3851..0000000
--- a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/83202b83-eea8-452f-8239-d468940bddba/body
+++ /dev/null
@@ -1,123 +0,0 @@
-On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote:
-> 
-> Hello to everyone
-> 
-> As i said in a previous mail, I am working on a "html" command for be. 
-> The goal is to be able to do something like "be html /web/page" to have in the 
-> /web/page directory some static html pages that basically are the dump of the 
-> be repository, much like ditz have
-> This will enable a simple and fast publish of the bus list and details on the 
-> web, at least in read only mode.
-> 
-> So I'd like to ask some question:
-> 1) is it ok to develop this command ? I know that this is not a fully featured 
-> web interface, but I am sure that it can be usefull.
-> 
-> I am open to suggestion about it of course.
-> 
-> 2) I see that every command is implemented with a python file in the becommand 
-> dir. For a better code, I'd like to split the command implementation into two 
-> files: a file that contain the actual code and a second  file that have the html 
-> related part, any problem with this ? I don't like to have the html part and 
-> the code part in one big and unreadable file.
-> 
-> I'd like to hear other opinion about this.
-> 
-> Thanks for now
-> bye
-> Gianluca
-> 
-> 
-> _______________________________________________
-> Be-devel mailing list
-> Be-devel@bugseverywhere.org
-> http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
-
-On Mon, Jul 06, 2009 at 10:18:33PM +0200, Gianluca Montecchi wrote:
-> This sound like an interesting idea, but what i'd like to do is not, strictly 
-> speaking, a report. It is a full tree of html pages that are browseable, both 
-> on line and offline
-
-I'm not sure what distinction you're making about "report".  You're
-just producing a static snapshot of the current database status,
-right?  The number of pages and completeness of coverage are nice, but
-it's still a static entity generated from a particular snapshot, which
-is what I mean by "report" ;).
-
-> > > 2) I see that every command is implemented with a python file in the
-> > > becommand dir. For a better code, I'd like to split the command
-> > > implementation into two files: a file that contain the actual code and
-> > > a second file that have the html related part, any problem with this ?
-> >
-> > This sounds quite sensible to me. The existence of a command implies a
-> > module of the same name in ‘becommand’, but there's no necessary
-> > implication that that module can't import modules from elsewhere to do
-> > its work.
-> 
-> The "elsewhere"  for now is the same directory, just another module
-> 
-
-On Mon, Jul 06, 2009 at 10:38:56PM +0200, Gianluca Montecchi wrote:
-> > On Fri, Jul 03, 2009 at 10:50:17PM +0200, Gianluca Montecchi wrote:
-> > > The goal is to be able to do something like "be html /web/page" to have
-> > > in the /web/page directory some static html pages that basically are the
-> > > dump of the be repository, much like ditz have
-> >
-> > I think truly interactive frontends like Steve's working on need to be
-> > build on top of libbe directly, since they'll need to make lots of
-> > small changes to the database, and it's to slow to be reloading the
-> > database for every change.  Static dumps like my mbox or Gianluca's
-> > html could just parse the xml output of `be list' and other be
-> > commands.
-> 
-> Ok, but if I want to have an html dump that is browseable, I need to parse the 
-> xml. Am I correct ? 
-> If yes, should not be easiear to use directly the libbe ?
-
-Using libbe directly is easier, but also more tightly tied to the be
-internals which could weigh down future refactoring.  Partly I'm
-afraid of our 2.5 different html-output mechanisms.  Either their
-should be a single Right Way that tries to satisfy everyone, or a
-smorgasbord of loosely coupled translators, so it's not so painful to
-kill them if/when they go out of style :p.
-
-On Mon, Jul 06, 2009 at 10:46:54PM +0200, Gianluca Montecchi wrote:
-> On Saturday 04 July 2009 02:31:26 Chris Ball wrote:
-> > It might be a good idea for "be html" to use the CherryPy web interface
-> > that Steve is working on.  The command could start up the CherryPy app
-> > and scrape all of the available pages to get a stand-alone dump; this
-> > would avoid having to keep two (okay, more than two at this point)
-> > separate sets of HTML templates in the source tree.  What do you think?
-> 
-> It can be do, but this implies that CherryPy must be installed and configured, 
-> a thing that I don't want to impose. My idea is to offer a simpler way to have 
-> some html pages, where you just need to have BE installed.
-
-I agree that not needing CherryPy for a static html dump is good.
-Also, read-only templates will look different from the CherryPy
-interactive templates.  +1 for another quasi-redundant template set
-;).
-
-> >    > 2) I see that every command is implemented with a python file in
-> >    > the becommand dir. For a better code, I'd like to split the
-> >    > command implementation into two files: a file that contain the
-> >    > actual code and a second file that have the html related part,
-> >    > any problem with this ? I don't like to have the html part and
-> >    > the code part in one big and unreadable file.
-> >
-> > I agree that becommands/*.py commands should not contain any HTML
-> > layout code.  Putting it somewhere else instead sounds fine.
-> 
-> I am in doubt with the "somewhere else", since for now I put the html template 
-> into a separate file in the same directory. Suggestion ?
-
-I think that only code intended only for command line use only should
-go into becommands, but really, just dump it anywhere and we can shift
-it around later :p.
-
--- 
-This email may be signed or encrypted with GPG (http://www.gnupg.org).
-The GPG signature (if present) will be attached as 'signature.asc'.
-For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-
-My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt