update address standardization for cust_location changes
[freeside.git] / rt / docs / design_docs / cvs_integration
diff --git a/rt/docs/design_docs/cvs_integration b/rt/docs/design_docs/cvs_integration
deleted file mode 100644 (file)
index 45a758f..0000000
+++ /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 ()
-
-