At 12:25 30.06.2010 -0400, John Reese wrote: >On 06/30/2010 04:51 AM, Fabian Cenedese wrote: >> We expanded the original commit script to filter out unrelated >> commits, divide up commit messages for multiple bugs, find users >> if the svn user is different to the mantis user etc. Is this commit >> script still the way to go with the new system or is it not supported >> anymore? Is there another way to control the flow of data between >> subversion and mantis with the new plugin system? > >Firstly, the script-based integration is still available in version 1.2, but >it >is deprecated, and has been removed from the development branch slated for >1.3. > So in the interest of preparing for the future, it would be best to begin > work >on moving to the integration plugin, but the script you already have should >still work with 1.2.x. > >The new integration plugins continue to offer, or improve upon, all the >supported functionality from the original integration scripts. With a bit of >configuration as appropriate, it will continue to automatically resolve issues >given a certain message, and it actually contains built-in support for mapping >SVN usernames to accounts in MantisBT rather than needing custom scripting for >that. However, the plugin doesn't (currently) allow for filtering inbound >changesets, so I'm curious why you were using or needed that in the first >place; >perhaps there is another way to meet your requirements.
A commit message like "fixed #1, fixed #34: bla bla" had to close two Mantis issues, it's possible that this was already originally in. If a commit message had several lines it was split up. So with a message like fixed #2: foo added and adjusted bar only the first line was added as closing note to the mantis bug. And with fixed #3: yep fixed #78: nope each line was added to their respective Mantis issues but not the whole message. Of course you could say that this is bad style anyway, but it still happens. If Mantis 1.3 would now scan all svn messages and show the matching ones it would show the complete message. That's not grave, we could live with that. I was just wondering. If I understood your online description correctly Mantis would only close the issue after importing the latest repo changes, called via a cronjob. Of course the cron time is a matter of taste and can be very often, but I think Mantis loses a bit of synchronicity. Maybe the repo import could be started from a post-commit hook... I would need to try it out to find out if something wouldn't work for us but that won't be in the near future. I will speak up again if I get there. Thanks bye Fabi ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ mantisbt-help mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mantisbt-help
