rt/docs/design_docs/cvs_integration

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