This article provides details on how to troubleshoot SubVersion in the Unix environment.
Agents, Administrators, End-User
If you check in a file and don’t see any corresponding info appear in the Manuscript case:
- Make sure you are using the correct syntax when referring to the case.
Try BugzID:1 (if you have a case number 1)
- See if the trigger is running.
- The post-commit script for Subversion has a line at the end that says
- Add a # character to the beginning of this line so after the commit runs it does NOT delete the file in /var/tmp
- Run a commit again and validate the file is there
- If the file is not there, try running the post-commit script directly (to make sure the problem is not svn failing to run it):
4.1. Go to your svn hooks directory
4.2. Run post-commit /path/to/svn/root/directory 1234 where the first argument is the root directory of your svn directory and “1234” is a revision number containing a Manuscript case id. If anything goes wrong, you will see it on your console output.
- See if the logBugDataSVN file is working. The easiest way to do this is to call it from the command line. (In the commands below, replace $REV with a valid revision number and $REPOS with the path to your repository.)
If the info is actually getting into Manuscript but the link back to WebSVN is not working:
- Outside of Manuscript navigate to your site and make sure WebSVN is working on its own. Note the URLs that it is using and make sure you have set the appropriate pointers for your server. You can edit the URLs by editing your repo settings in Avatar Menu > Source Control
- If you are using an older version of Manuscript and you see %2F in the URLs where you should see “/”, change your Apache AllowEncodedSlashes configuration.