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 ()