diff options
Diffstat (limited to 'rt/docs/design_docs/cvs_integration')
| -rw-r--r-- | rt/docs/design_docs/cvs_integration | 164 |
1 files changed, 164 insertions, 0 deletions
diff --git a/rt/docs/design_docs/cvs_integration b/rt/docs/design_docs/cvs_integration new file mode 100644 index 0000000..35c8737 --- /dev/null +++ b/rt/docs/design_docs/cvs_integration @@ -0,0 +1,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 seperate 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 seperate 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 () + + |