Just a quick comment...the third format option suggested... " fixed bug 547: some log message
or invalid bug 547: some log message or worksforme bug 547: some log message " ...is not possible using bugtraq properties in Subversion. Adding these properties in Subversion allows the interface to present a bug text field to accept the bug ID (or IDs as the case may be). The ID is then appended (or prepended if that option is selected) to the message in such a fashion... bug: 547 some log message or some log message bug: 547 Using the standard bugtraq properties, there is not a way for me to add to the "bug:" portion of the submitted comment dynamically. I therefore am requesting that this feature ensure that it is compatible with this. Great if you can make it work for all solutions, but please make sure that the third option mentioned previously is not the only available solution. Thanks a lot, Shawn Jacobson Software Developer Lynxspring, Inc. 8900 State Line Road, Suite 150 Leawood, KS 66206 tel: (913) 649-5969 fax: (913) 649-5968 [EMAIL PROTECTED] ---------------------------------------------- Solutions and Technology Converge Notice: This email message, together with any attachments, contains information of Lynxspring Inc., which may be confidential, proprietary, copyrighted and/or legally privileged. This email is intended solely for the use of the individual or entity named on the message. If you are not the intended recipient, and have received this message in error, please immediately return by email and then delete it. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristis Makris Sent: Tuesday, November 28, 2006 10:28 AM To: Sven Lankes Cc: [email protected] Subject: Re: [scmbug-users] How to implement resolve/fix bug through logmessage Hi Sven, On Tue, 2006-11-28 at 12:44 +0100, Sven Lankes wrote: > Hi all, > > I installed scmbug on our subversion/mantis Server yesterday and was > shocked to find out that it's not possible to mark a bug as resolved > using a log message. That was an astute observation. It has been requested in the past, yes. To be frank, it hasn't been implemented because not enough people requested it. Perhaps now it's time. > > I would like to have a shot at implementing the feature but I am not > quite sure as to how to implement the feature in a way that it's useful > outside of our own scope of mantis/subversion. An implementation of this feature would be merged-in instantly. Thanks so much! > I was thinking of adding a regexp that matches "closes bug xxxx: ..." > that would set the bug to a resolved/closed state and add the comment > after the colon as comment in the close-message. > > Is this something that would work with other bugtrackers? You have the general idea right. Now the specifics: "closes" may not mean much. For example, there may be multiple "closing" states. I'll take bugzilla for example: If a bug is in an an open state (e.g. "reopened" or "assigned") it can be resolved as: FIXED INVALID WONTFIX LATER REMIND WORKSFORME It is possible for example to do some work on the bug (e.g. to increase debugging in the software) and later determine that this wasn't really a bug, but still want to commit your changes. You would commit and mark at as "INVALID". Thus, I would like to have a way of also specifying the resolution type. I was hoping for something like: bug 547: Some log message goes here for fifty characters status: fixed or even in reverse: status: invalid bug 547: some log message. Or perhaps it would be extended to something like: fixed bug 547: some log message or invalid bug 547: some log message or worksforme bug 547: some log message I don't know how I feel about choosing between having an explicit "status:" or not. I haven't used this in the past. Go with your gut feeling and we'll see how it works. If you were to implement this I would recommend: - Insert in glue.conf.template.in in policies->{ log_template } a variable like status_regex (very similar to bugid_regex). - Modify Connection.pm.in:process_activity to append to $request a close_status. A blank close status may mean something in some bugtrackers, so perhaps a token we define here (e.g. SCMBUG_UNCHANGED) could mean that the status should not be changed. - Modify Daemon.pm.in:process_connection to retrieve the close_status. - Modify Integration.pm.in to check if the status is valid, similar to process_activity_verify with $request->{ policies }->{ open_bug_state } - Extend Mantis.pm.in as needed - if you were to also add subversion testcases in src/tests/product.test/svn/tests_svn.exp I really would merge this work instantly, else you'll have to wait for a while for me to write them; that's ok though. Implement this infrastructure and the backend check for Mantis, and I will implement the respective backend check for Bugzilla. How does this sound ? _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users _______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
