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

2 files changed, 0 insertions, 109 deletions

diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body
deleted file mode 100644
index debd486..0000000
--- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body
+++ /dev/null
@@ -1,95 +0,0 @@
-On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
-> On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
-> > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
-> > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
-> > > > 1. is there any way to aggregate over multiple public branches in order
-> > > > to get the complete bug state
-> > > 
-> > > Keeping the bug data with the source helps synchronize bug state and
-> > > source code.  Bug state in branch A may not apply to branch B.  Some
-> > > people like to weaken this source-bug linkage by keeping their bugs in
-> > > a branch all by themselves (ditz [http://ditz.rubyforge.org/]
-> > > currently supports this workflow).  It sounds like you want to move
-> > > from "bugs with code" to "bugs and code in separate branches".  We
-> > > don't have an easy way to do that in BE at the moment, since
-> > > version-control systems like Git have a single working branch at a
-> > > time (I think :p).  What VCS are you using as a backend?
-> >
-> > the basic idea is to take a look at all public branches (for exaple all
-> > on lp/bitbucket/github) in order to tell the user of a webinterface that
-> > bug foo is fixed in branch xyz, and if its merged to the main branch
-> 
-> Hmm.  
-> 
-> > > > 2. is there any model for storing bigger files at a central place (for
-> > > > some of my bugs i have multi-megabyte tarballs attached)
-> > > 
-> > >   be comment ID "See the tarball at http://yourpage/something.tar.gz"
-> > > Then to grab the tarball, you'd use:
-> > >   wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
-> > > to grab it.
-> > so the basic idea is to do it completely self-managed
-> 
-> Well, it's going to be managed by somebody ;).  So far I'm not
-> convinced enough for the manager to be me, so I'm suggesting it be you
-> :p.
-> 
-> > and have have heterogenous sources of extended data?
-> 
-> I assume "extended data" here refers to your tarballs.  What sort of
-> homogenous source did you have in mind?  The comment body is currently
-> just a binary blob for non-text/* types, otherwise it's text in
-> whatever encoding you've configured.
-some kind of common upload target for a single project in order to have
-more reliable sources of stuff thats related to bugs but doesnt fit into
-the normal repository
-
-
-> 
-> On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
-> > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
-> > 
-> > > i want to see the combination of the bug data of all branches
-> > 
-> > How is a tool to determine the set of “all branches”? The distributed
-> > VCS model means that set is indeterminate.
-> 
-> He could just make a list of branches he likes.
-> 
-> Ronny, are you looking to check bug status across several repos on the
-> fly, or periodically run something (with cron, etc.) to update a
-> static multi-repo summary?
-on the fly access
-
-> 
-> The easiest implementation I can think of would be to keep local
-> branches (on whatever computer is hosting your web interface)
-> following your favorite repos.
->   proxectX/
->   |-- repoA
->   |-- repoB
->   `-- repoC
-> You'd pull upstream changes with a cron job.
-> Listing bugs would be something along the lines of
->   projectX$ for repo in *
->             do
->               pushd $repo
->               be list
-> 	      popd
->             done | sort | uniq
-> Then to show bug status you would have something like
->   projectX$ for repo in *
->             do
->               echo $repo
->               pushd $repo
->               be show ${BUGID}
->               popd
->             done
-> For a web frontend, you'd want to translate that to python/libbe.
-> 
-
-yes, the idea is to get a web fontend for multiple branches 
-and maybe a local gtk fontend for local multi-branch setups
-
-for some of my projects i have n local and m remote repos, and merging
-is not always intended soonish
diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values
deleted file mode 100644
index 5a64ee0..0000000
--- a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <1247433610.14803.3.camel@localhost>
-
-
-Author: Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de>
-
-
-Content-type: text/plain
-
-
-Date: Sun, 12 Jul 2009 23:20:10 +0200
-
-
-In-reply-to: bd98f525-95ec-446a-84e8-34c7d6fa5b40
-