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

2 files changed, 0 insertions, 107 deletions

diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body
deleted file mode 100644
index 8991cfb..0000000
--- a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/body
+++ /dev/null
@@ -1,93 +0,0 @@
-> 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" ;).
-
-Mmm, my bad here.
-I normally speak about "report" as something that is not browseable, like
-the output of a report generator (reportlab or whatever), but I admit that
-basically also the html output I am working on is a report.
-
-
-> On Mon, Jul 06, 2009 at 10:38:56PM +0200, Gianluca Montecchi wrote:
->>
->> 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.
-
-I know that using libbe I am more tightly tied to the internals, but
-I am trying to keep the command code and the presentation code crearly
-separated to minimize this problem. I am not sure this is a real problem
-anyway.
-
-
-> 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
-> ;).
-
-The look is not a problem. I can always use the same html Steve is using.
-I am also playing with the idea to have the template themeable some time
-after I have a fully working version.
-
->
->> >    > 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.
-
-Of course.
-
-bye
-Gianluca
-
-
-_______________________________________________
-Be-devel mailing list
-Be-devel@bugseverywhere.org
-http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
diff --git a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/values b/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/values
deleted file mode 100644
index fc79745..0000000
--- a/.be/bugs/2f048ac5-5564-4b34-b7f9-605357267ed2/comments/c7ace551-2982-4683-bca3-b5e66056cce5/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <6f719a1c43fdcba8bdbfee1130072595.squirrel@webmail.grys.it>
-
-
-Author: gian@grys.it
-
-
-Content-type: text/plain
-
-
-Date: Tue, 07 Jul 2009 14:15:08 +0200
-
-
-In-reply-to: 83202b83-eea8-452f-8239-d468940bddba
-