1 files changed, 70 insertions, 0 deletions
diff --git a/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body
new file mode 100644
index 0000000..6b7d3eb
--- /dev/null
+++ b/.be/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/6dcc910a-ce15-4eeb-b49b-4747719748ed/body
@@ -0,0 +1,70 @@
+On Sun, 2009-07-12 at 19:55 -0400, W. Trevor King wrote:
+> On Sun, Jul 12, 2009 at 11:20:10PM +0200, Ronny Pfannschmidt wrote:
+> > 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:
+> > > > > > 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
+> > > > 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
+> 
+> Sorry, I'm still having trouble with "doesn't fit into the normal
+> repository".  It's going to be large wherever you keep it.  You
+> worried about multiple branches all having these big tarballs in them
+> and want a "lightweight" checkout without all the big
+> tarballs/whatever?  I still think having some sort of "resources"
+> directory on an http server somewhere that you link to from comments
+> is the best plan.  If you use the
+>   be show --xml ID | be-xml-to-mbox | catmutt
+> approach, you can even write your comments in text/html and get
+> clickable links ;).  A "push big file to remote and commit comment
+> linking to it" script would be pretty simple and keep everything
+> consistent.
+thats probably what i want to do
+
+> 
+> > > 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
+> 
+> Then listing bugs in a remote repo will either involve httping tons of
+> tiny values files for each bug (slow?) or running some hypothetical
+> BE-server locally for each repo speaking some BE-specific protocol
+> (complicated?).  And how would you handle e.g. headless git repos,
+> where nothing's even checked out?
+> 
+> You could always run the cron job every 15 minutes, and rely on
+> whatever VCS you're using having some intelligent protocol/procedure
+> to keep bandwidth down ;).  If you need faster / more-efficient
+> updates, you'll probably need to throw out polling altogether and
+> setup all involved repos with a "push to central-repo on commit" hook
+> or some such.
+its intended to run on the place where i publish the repositories anyway