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
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
jesse@FSCK.COM: ok. anyone here
interested in having RT as a bug tracker integrated with CVS? ()
marc: in principle, sure. ()
jesse@FSCK.COM: want to write up your
ideal of how such a beast would work? ()
alex_c: what sort of integration are you thinking of, Jesse? ()
jesse@FSCK.COM: well, that's what I want
to know, alex. lots of people want their bug trackers tied to their
version control. I want to know what people want it to _do_ ;) ()
alex_c: weird. :) ()
marc: similarly to what the debian bts does.
you put a magic string ("rt-closes#123") and it causes the bug in rt to
be closed (or appended with a different magic string) with the commit
message. also nice would be if rt would then generate links to a
webcvs server. ()
jhawk: Hrmm. cvs front-end that strips 'em out?
Perhaps with RT: lines instead of CVS: lines in the commit
interaction? ()
marc: the magic string goes in the commit
message, that is. no, use one of the magic post-commit scripts. ()
jesse@FSCK.COM: well, there's also the
pre-commit script to lock out commits wihtout a ticket id ()
jhawk: Personally, I don't want to force special
magic strings to the bug-tracking system, some of which may be
confidential, to appear in the cvs logs. ()
marc: I could see wanting that on a release
branch. ()
jhawk: I also think it would be cool to supply
template stuff for you to edit. ()
jesse@FSCK.COM: I'm not sure cvs can be
made to do that. can it? (generate templates) ()
jhawk: It would be reasonable, in my model, to
turn some kinds of RT: lines into things that fell in the commit
message, but not all kinds. ()
marc: I don't quite see jhawk's objection. ()
ghudson: In my observation, locking out commits
without a ticket ID is usually an impediment to development, and leads
to developers having the one bug which all commits cite. ()
jhawk: If you had a CVS frontend, it could geneate
the template and feed it to 'cvs commit -m' ()
ghudson: CVS can generate templates and verify
that they have been filled in. ()
jhawk: What Greg says sounds cool; greg, what do
you mean? marc: one sec. ()
marc: I think assuming a frontend is a terrible
idea. ()
jesse@FSCK.COM: greg: agreed. but people
seem to want it. the idea would be only for a locked down release
branch. ()
jhawk: marc: So, I might want to close an open
ticket as part of a commit message without that showing up in the
coommit message. Or to insert a splufty long comment into a ticket
while I do the commit but not close or really change the state, and
that comment might want to ramble a lot but not include that ramble in
the commit message. ()
jesse@FSCK.COM: well, then arguably, you
might want to not use the commit message for that update, but instead
just go straight to the bts ()
marc: I think the idea is to force you to
mention the ticket closing in the commit message. ()
jesse@FSCK.COM: but yeah, state changing
and 'update messages' are separate concepts that should both be
supported. ()
jesse@FSCK.COM: part of the idea is to
drag the commit message into the BTS ()
jhawk: Err, I think it quite frequent that I want
to put separate info in both the commit message and the ticket system,
and entering them at the same time seems cool. ()
jesse@FSCK.COM: ok. noted. I'll see if
that's doable, when i get around to this. ()
marc: so I think you want a custom front-end,
but I don't think what you want is what jesse is talking about. ()
jesse@FSCK.COM: the thing that would be
really cool that scare the pants off me is tracking which branches bugs
exist in / are fixed in ()
jesse@FSCK.COM: what jhawk wants should
be doable, now that I understand his reqts. ()
marc: that would require the bts to understand
branches in some fundamental way. ()
jesse@FSCK.COM: yes. see above, about
the pants. ()
sly: uh oh, not more people losing their pants... ..
ghudson: RT needs to know the names of branches
and their structure (so that you can tell it "fixed in foo" and it
knows that the bug is still fixed in anything that branches off of foo,
but not necessarily in other new branches), but nothing more than that.
jhawk: So, note that what I'm describing is how
I'd like the UI to be, from a generic architectural level, and not
really thinking terribly specific. Greg, can you explain the CVS
template thing? ()
jesse@FSCK.COM: and it needs to know
exactly "when" a branch happens. because "fixed in foo" won't fix
something that branched off foo yesterday ()
marc: jesse was talking about integrating rt
with cvs. building a new developent+repository+bts from scratch would
be a problem with larger scope :-) ()
jesse@FSCK.COM: marc: was that in
response to jhawk? ()
ghudson: CVS and templates: "rcsinfo" lets you
specify a template for log messages, and "commitinfo" lets you check
them. ()
ghudson: Er, sorry, my bad.
s/commitinfo/verifymsg/ ()
marc: with cvs, if you have the revision number
of the fix (which you should). you can use the branch version number to
get a date and see when the branch happened relative to the fix. ()
marc: jesse: yes. ()
jesse@FSCK.COM: Ok. would people
consider "integration with CVS" to be subpar or incomplete if it didn't
deal with tracking branches? ()
marc: incomplete relative to an ideal, but not
subpar, as it would still be useful. ()
allbery@CS.CMU.EDU: CVS's branch
support sucks so much that failure to work with it is hardly a bug ()
|
