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