Setup issue (on Synology): chasing black hole in SVN post-commit hook...

[Zener131]

Hello.
At first: nice job ! But getting all to work on exotic platforms may be a real pain...

This is the post-commit hook in pure SVN mode, on the same server as MantisBT (a recent Synology NAS).

At first I had to turn the PHP SafeMode off because shell_exec() was failing...

Now at commit I get that in the log (my traces then result from Curl call):

CommitMsg: "new test, fixed issue #1 blah blah"
-d repo_name=MantisSetup -d data=7 -d api_key=yes
Processing svn log (xml)...
Parsed to revision 7.

Then nothing more. This was in SourceSVN.commit().process_svn_log_xml()

Nothing is added in the database (phpMyAdmin confirmed),
and no note appears in the bug #1 which exists and is associated with a project & repository both named MantisSetup, and is assigned to the (developper) User who commits.

• How could I proceed to understand what happens beyond ? Thanks for any clue.

Putting "echo 'was here' " everywhere in the code is not easy...
So I suggest to add a "verbose" mode to make the setup easier on such unnatural platforms.

Thanks, Best regards.

[dregad]

I agree that troubleshooting this plugin is indeed a pain today; to solve this I believe we would need to add proper logging, something I've had on my todo list but never got around to implementing.

[Zener131]

Hello.

I could finally find it with many "echo" and retries...

My repository was declared as a "standard repo" (let's start the simple way) and I was trying to commit a dummy file at the root (simply again), what TortoiseSVN allows.

When doing that, in SourceSVN.process_svn_log_xml(), none of the paths in the if-else-if logic is taken, and $t_changeset->branch keeps empty, what then causes to return an empty array and finally, exit silently at the end of caller checkin.php (# No more changesets to checkin).
Nice black hole.

By simply declaring the repository as not standard, I get the note added to the bug.

Well, maybe doing such a commit is not really compliant, but since it is possible, I guess it must happen and puzzle some Users, then I really think this is worth an alert in the logs (never leave the default case or final else empty) :-)

Best regards.

[amyreese]

'Standard repo' means that it expects a 'trunk' directory at the root of
the svn repository. Essentially, it runs all the commands against the
'trunk' subpath rather than the root, which is always going to return
nothing if trunk doesn't exist.
On Jun 14, 2014 9:30 AM, "Zener131" [email protected] wrote:

Hello.

I could finally find it with many "echo" and retries...

My repository was declared as a "standard repo" (let's starting the simple
way) and I was trying to commit a dummy file at the root (simply again),
what TortoiseSVN allows.

When doing that, in SourceSVN.process_svn_log_xml(), none of the paths in
the if-else-if logic is taken, and $t_changeset->branch keeps empty, what
then causes to return an empty array and finally, exit silently at the end
of caller checkin.php (# No more changesets to checkin).
Nice black hole.

By simply declaring the repository as not standard, I get the note added
to the bug.

Well, maybe doing such a commit is not really compliant, but I guess it
must happen and puzzle some Users, then I really thing this is worth an
alert in the logs (never leave the default case or final else empty) :-)

Best regards.

—
Reply to this email directly or view it on GitHub
#91 (comment)
.

[dregad]

Thanks for your feedback. As you have found the root cause, I'm closing this issue based on John's comment.

I opened #92 to keep track of the need for a proper logging feature (don't hold your breath for implementation though)