trac-post-commit should go fine with svn merges

[Christian Parpart <trapni@…>]

Hi,

as I got *NO* response in the list, I'm trying it here.

trac-post-commit interprets fragments like "closes #7", "refs #8" and alike.

When a merge happens (using svk) e.g. using the following command: svk smerge -l /bugfix-branch /stable-branch where -l specifies to use the prio commit log messages as merge commit log messages;

this implies that the above mentioned "refs #8" (and alike) will be interpreted again.

is there a way to fix this in trac-post-commit?

[Christian Boos]

In the scenario you described, I think it makes sense for the commit message to be interpreted again, as this helps you to keep track in which branches the fixes have been incorporated.

[Christopher Lenz]

Later (if this is even an issue)

[Christian Boos]

I don't have svk installed at hand, but I think that if you don't also specify --verbatim, you'll get a header for the smerge commit log. In the post-commit hook, that could be used to special case this situation.

[Jason Winnebeck <jpwasp@…>]

Yeah, in my environment I specifically do want the "refs" to process again (although I'm doing merging through another took than svk). However, the problem is with the "closes" command — if a ticket is reopened you might not want to close it when copying an old command.

I don't think this is a problem that Trac could solve, though, since it doesn't know the source of any particular commit. trac-post-commit-hook can't solve every situation, or you could modify it to handle the svk cases.

[anatoly techtonik <techtonik@…>]

This ticket seems to be too old. SVK is no longer actively maintained, so I close this as "won't fix". It could be opened if the issue actual with SVN, but seems like its not, so making trac-post-commit-hook understand SVK merge information is a task for SVK community, not Trac.

[Christian Boos]

(clearing report:35)