1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
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.
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?
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.
--
This email may be signed or encrypted with GPG (http://www.gnupg.org).
The GPG signature (if present) will be attached as 'signature.asc'.
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
|
