.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/30a8b841-98ae-41b7-9ef2-6af7cffca8da/body

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