source-integration icon indicating copy to clipboard operation
source-integration copied to clipboard

SVN: Any way to parse revprop changes?

Open pantsmanuk opened this issue 11 years ago • 3 comments

Specifically, certain members of our development team insist on committing, testing the autobuild executables, then changing their commit messages to indicate fixes (rather than "speculating" on fixes beforehand). I currently can't see a way to have the SCI plugin(s) parse the revprop changes and update the already imported changeset logs. Is this even do-able with the current plugins?

Running SCI 0.18, SVN-I 0.16, WebSVN-I 0.17 against MantisBT 1.2.15 on Ubuntu 10.04 LTS

pantsmanuk avatar May 13 '13 09:05 pantsmanuk

That's not possible at the moment with the SVN plugin, because SVN doesn't make it obvious that data has changed (and IMO people shouldn't be making habits of changing that data). If this was Git, then the actual revision hash would change, so the plugin would import that revision fresh, but SVN doesn't change revision numbers. I'm not really sure that there is a good solution for this other than to make it easier for them to run automated tests/builds without needing to check in their changes, which is also really bad IMO.... :frowning:

amyreese avatar May 13 '13 15:05 amyreese

Thanks for the response John. I was worried that would be the case, and I entirely agree that relying on revprop changes is a problem, but some folks here just don't see it that way :(

The way it was done in our old "homebrew" SCI mechanism is via the post-revprop-change hook script; it checked if the change was a log change, and if it was added it to the issue note queue (re-running the changeset parsing at the same juncture). Just throwing out ideas here, since I don't mind bashing on PHP; could something similar be done via the plugin (perhaps with a new "update" page)? I've got the repository and revision in the hook script, so I can pass either/both to an update page called from the hook script with the new changeset log...

Comments welcomed at this juncture.

pantsmanuk avatar May 13 '13 15:05 pantsmanuk

(Teach me to look before opening my mouth...)

I see there already is a pages/update.php under Source. I'm guessing "id" in respect of that page refers to the mantis_plugin_Source_changeset_table id field (or barking up the wrong tree?); I'd have to wedge something prior to that to turn the SVN hook script $REV value into a m_p_S_changeset_t id value (a relatively simple SELECT statement will do that) to use the existing update functionality (or again, barking up the wrong tree and that's not what update.php is for?)

pantsmanuk avatar May 14 '13 11:05 pantsmanuk