On Sun, Nov 20, 2016 at 7:47 AM Jason Morgan <[email protected]> wrote:
Hi, Emailing the dev list rather than user list as it seems the user list has had just 4 emails in over a year so is probably dormant. I'm exicited to see that the activity on Bloodhound has picked up. This is encouraged me to install it here as it is clearly the most feature full bug tracking software other than JIRA, and for me being written in Python is a big advantage (I'm a big fan of the language) A couple issues, probably down to me not finding the correct documentation rather than actual bugs. Installation: The current tradition is to install non-packaged local deployments in /opt, however the instructions for installing Bloodhound want you to install it as a non-privileged user in ~ (tilde). Have you been following the BloodhoundInstall wiki? The source is downloaded and extracted in the Bloodhound user's home directory, however Bloodhound gets installed to /opt/bloodhound. https://issues.apache.org/bloodhound/wiki/BloodhoundInstall I wouldn't be surprised if there are errors in BloodhoundInstall, and we'd appreciate any contributions. Registration at issues.apache.org/bloodhound may still be disabled due to spam. If you email me directly I'll create you an account. This is OK (and preferred) for development but for a deployment not so. e.g. The distributed install instructions won't work as they are as they expect the logged in user to be called 'bloodhound' as this is the UID given for the WSGI app. 1: What would be the correct way to deploy Bloodhound? It seems to install in installer/bloodhound, surely this is not correct, am I doing this wrong or does the installer need some work? That sounds familiar, but the steps at BloodhoundInstall don't appear to install in installer/bloodhound. Perhaps you are following the instructions for developing with Bloodhound? I notice that the install method creates many files with absolute paths built into them (pointing to paths owned by a real user and not Mr Bloodhound), we all know this is not good practice. Perhaps there should be an issue raised to fix this? That also sounds familiar. Which options are you referring to? I seems to remember absolute paths for [trac] environment_factory and [trac] request_factory, but we may have addressed those in Release 8: https://issues.apache.org/bloodhound/ticket/795 Secondly: I'd like to use BH with SVN. I can't find any documentation for this. The SVN page in the settings wants an absolute path rather than a URL, does this mean that the SVN repos and BH must be on the same server (or NFS)? Yes, Trac (and therefore Bloodhound) only supports an SVN repository on the same server. If your SVN repository is remote, then a read-only instance needs to be mirrored to your server using svnsync. http://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt Luckily this is the case for us, but if I enter the SVN repos root path it then says I must run: trac-admin $ENV repository resync "serverside" serverside being the name of the repository. However it does not say where this should be run, what $ENV should be, it fails with Error: No Trac environment found at /opt/apache-bloodhound-0.8/installer/bloodhound/repository [Errno 2] No such file or directory: '/opt/apache-bloodhound-0.8/installer/bloodhound/repository/VERSION' what is it expecting to find in the non-existent directory repository? $ENV should be the path to the environment that you created in /opt/bloodhound/environments You may want to read: https://trac.edgewall.org/wiki/TracEnvironment I used trac many, many years ago, but it's changed enough for me to not be at all familier with it's operation. Any help appreciated Regards, Jason
