.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/4d192c6c-a4a8-4844-b083-2dd5926bd2d9/body

   1 On Sun, Jul 12, 2009 at 11:20:10PM +0200, Ronny Pfannschmidt wrote:
   2 > On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
   3 > > On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
   4 > > > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
   5 > > > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
   6 > > > > > 2. is there any model for storing bigger files at a central place (for
   7 > > > > > some of my bugs i have multi-megabyte tarballs attached)
   8 > > > >
   9 > > > >   be comment ID "See the tarball at http://yourpage/something.tar.gz"
  10 > > > > Then to grab the tarball, you'd use:
  11 > > > >   wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
  12 > > > > to grab it.
  13 > > >
  14 > > > so the basic idea is to do it completely self-managed
  15 > > > and have have heterogenous sources of extended data?
  16 > >
  17 > > I assume "extended data" here refers to your tarballs.  What sort of
  18 > > homogenous source did you have in mind?  The comment body is currently
  19 > > just a binary blob for non-text/* types, otherwise it's text in
  20 > > whatever encoding you've configured.
  21 >
  22 > some kind of common upload target for a single project in order to have
  23 > more reliable sources of stuff thats related to bugs but doesnt fit into
  24 > the normal repository
  25
  26 Sorry, I'm still having trouble with "doesn't fit into the normal
  27 repository".  It's going to be large wherever you keep it.  You
  28 worried about multiple branches all having these big tarballs in them
  29 and want a "lightweight" checkout without all the big
  30 tarballs/whatever?  I still think having some sort of "resources"
  31 directory on an http server somewhere that you link to from comments
  32 is the best plan.  If you use the
  33   be show --xml ID | be-xml-to-mbox | catmutt
  34 approach, you can even write your comments in text/html and get
  35 clickable links ;).  A "push big file to remote and commit comment
  36 linking to it" script would be pretty simple and keep everything
  37 consistent.
  38
  39 > > On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
  40 > > > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
  41 > > >
  42 > > > > i want to see the combination of the bug data of all branches
  43 > > >
  44 > > > How is a tool to determine the set of “all branches”? The distributed
  45 > > > VCS model means that set is indeterminate.
  46 > >
  47 > > He could just make a list of branches he likes.
  48 > >
  49 > > Ronny, are you looking to check bug status across several repos on the
  50 > > fly, or periodically run something (with cron, etc.) to update a
  51 > > static multi-repo summary?
  52 >
  53 > on the fly access
  54
  55 Then listing bugs in a remote repo will either involve httping tons of
  56 tiny values files for each bug (slow?) or running some hypothetical
  57 BE-server locally for each repo speaking some BE-specific protocol
  58 (complicated?).  And how would you handle e.g. headless git repos,
  59 where nothing's even checked out?
  60
  61 You could always run the cron job every 15 minutes, and rely on
  62 whatever VCS you're using having some intelligent protocol/procedure
  63 to keep bandwidth down ;).  If you need faster / more-efficient
  64 updates, you'll probably need to throw out polling altogether and
  65 setup all involved repos with a "push to central-repo on commit" hook
  66 or some such.
  67
  68 --
  69 This email may be signed or encrypted with GPG (http://www.gnupg.org).
  70 The GPG signature (if present) will be attached as 'signature.asc'.
  71 For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
  72
  73 My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt