.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/12c986be-d19a-4b8b-b1b5-68248ff4d331/comments/8ffc90d7-0be7-4b00-88e6-9ae1b65f7957/body

   1 On Sat, 2009-07-11 at 11:25 -0400, W. Trevor King wrote:
   2 > On Sat, Jul 11, 2009 at 03:13:05PM +0200, Ronny Pfannschmidt wrote:
   3 > > On Sat, 2009-07-11 at 08:50 -0400, W. Trevor King wrote:
   4 > > > On Sat, Jul 11, 2009 at 01:54:54PM +0200, Ronny Pfannschmidt wrote:
   5 > > > > 1. is there any way to aggregate over multiple public branches in order
   6 > > > > to get the complete bug state
   7 > > >
   8 > > > Keeping the bug data with the source helps synchronize bug state and
   9 > > > source code.  Bug state in branch A may not apply to branch B.  Some
  10 > > > people like to weaken this source-bug linkage by keeping their bugs in
  11 > > > a branch all by themselves (ditz [http://ditz.rubyforge.org/]
  12 > > > currently supports this workflow).  It sounds like you want to move
  13 > > > from "bugs with code" to "bugs and code in separate branches".  We
  14 > > > don't have an easy way to do that in BE at the moment, since
  15 > > > version-control systems like Git have a single working branch at a
  16 > > > time (I think :p).  What VCS are you using as a backend?
  17 > >
  18 > > the basic idea is to take a look at all public branches (for exaple all
  19 > > on lp/bitbucket/github) in order to tell the user of a webinterface that
  20 > > bug foo is fixed in branch xyz, and if its merged to the main branch
  21 >
  22 > Hmm.
  23 >
  24 > > > > 2. is there any model for storing bigger files at a central place (for
  25 > > > > some of my bugs i have multi-megabyte tarballs attached)
  26 > > >
  27 > > >   be comment ID "See the tarball at http://yourpage/something.tar.gz"
  28 > > > Then to grab the tarball, you'd use:
  29 > > >   wget `be show COMMENT-ID | sed -n 's/ *See the tarball at //p'`
  30 > > > to grab it.
  31 > > so the basic idea is to do it completely self-managed
  32 >
  33 > Well, it's going to be managed by somebody ;).  So far I'm not
  34 > convinced enough for the manager to be me, so I'm suggesting it be you
  35 > :p.
  36 >
  37 > > and have have heterogenous sources of extended data?
  38 >
  39 > I assume "extended data" here refers to your tarballs.  What sort of
  40 > homogenous source did you have in mind?  The comment body is currently
  41 > just a binary blob for non-text/* types, otherwise it's text in
  42 > whatever encoding you've configured.
  43 some kind of common upload target for a single project in order to have
  44 more reliable sources of stuff thats related to bugs but doesnt fit into
  45 the normal repository
  46
  47
  48 >
  49 > On Sun, Jul 12, 2009 at 12:57:35AM +1000, Ben Finney wrote:
  50 > > Ronny Pfannschmidt <Ronny.Pfannschmidt@gmx.de> writes:
  51 > >
  52 > > > i want to see the combination of the bug data of all branches
  53 > >
  54 > > How is a tool to determine the set of “all branches”? The distributed
  55 > > VCS model means that set is indeterminate.
  56 >
  57 > He could just make a list of branches he likes.
  58 >
  59 > Ronny, are you looking to check bug status across several repos on the
  60 > fly, or periodically run something (with cron, etc.) to update a
  61 > static multi-repo summary?
  62 on the fly access
  63
  64 >
  65 > The easiest implementation I can think of would be to keep local
  66 > branches (on whatever computer is hosting your web interface)
  67 > following your favorite repos.
  68 >   proxectX/
  69 >   |-- repoA
  70 >   |-- repoB
  71 >   `-- repoC
  72 > You'd pull upstream changes with a cron job.
  73 > Listing bugs would be something along the lines of
  74 >   projectX$ for repo in *
  75 >             do
  76 >               pushd $repo
  77 >               be list
  78 >             popd
  79 >             done | sort | uniq
  80 > Then to show bug status you would have something like
  81 >   projectX$ for repo in *
  82 >             do
  83 >               echo $repo
  84 >               pushd $repo
  85 >               be show ${BUGID}
  86 >               popd
  87 >             done
  88 > For a web frontend, you'd want to translate that to python/libbe.
  89 >
  90
  91 yes, the idea is to get a web fontend for multiple branches
  92 and maybe a local gtk fontend for local multi-branch setups
  93
  94 for some of my projects i have n local and m remote repos, and merging
  95 is not always intended soonish