Posterous theme by Cory Watilo

Filed under: issue_tracking

Adding an OpenSearch provider for Redmine

Update: An OpenSearch plugin for Redmine has been created based on the work here.  I recommend you use that instead.  It is available at:

http://dev.holgerjust.de/projects/redmine-opensearch/wiki

Thanks to Holger for quickly turning this around.  Now, back to the original article:

Have you ever used your browser’s built-in search window?  Don’t answer that.

Internet Explorer and Firefox both allow search providers to be added to the built-in search window, so you can change which search the window actually performs.  By default my Firefox search comes with providers such as Google, Wikipedia, Answers.com, Amazon, etc.

I don’t actually use the feature much.  I’m used to typing Google searches in that box and don’t really think about anything else.  If I want to search Amazon, I go to Amazon.  But it is a convenience for Google.  The only way I might use it for something else were if there were another site I searched more often.

While it is arguable, I do search Redmine a lot for tickets, wiki info, etc.  As an experiment I wanted to switch my search box to Redmine.  I thought this would be a difficult task, perhaps involving coding.  Turns out is was much easier than I thought.  However, there was a lack of clear, simple steps to do so, so I’m sharing the process through which I went.

First of all, the search provider protocol, so to speak, is specified by OpenSearch.org.  I didn’t get a lot of help there.

I did, however, get help from a couple of sites if you just google “opensearch tutorial”.  While I still wasn’t sure exactly how to accomplish it, they made it a lot more comprehensible.

I also posted a discussion on the Redmine.org website, which landed me a key piece of help.  I thought I would have difficulty adapting the examples I was given, because I wanted to search an internal website not available on the web-at-large.  However, it wasn’t a problem after all.  I just couldn’t use the example on one web site that tried to use Google site search as the search provider.

The only caveat is that my implementation uses the most generic redmine search, which searches all projects.  More specific searches can be done after the first search.

There are two pieces you need:

  1. An opensearch description file available on your Redmine server
  2. A search provider notification link added to the template for Redmine’s html files, the one that includes the head tag

Here is the opensearch description file provided by another Redmine enthusiast, adapted for my site:

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">

    <ShortName>Redmine Search</ShortName>
    <Description>Search Redmine</Description>
    <Url template="http://redmine/search?q={searchTerms}"

         type="text/html" method="GET" />
    <Image height="16" width="16" type="image/vnd.microsoft.icon">http://redmine/favicon.ico</Image>
    <OutputEncoding>UTF-8</OutputEncoding>
    <InputEncoding>UTF-8</InputEncoding>
</OpenSearchDescription>

The reason for the edit above is that I previously posted another version of this file which turned out to be Firefox-specific, meaning it wouldn't work with IE.  This version works with both IE and Firefox.

As you can see, my server url is just http://redmine.  This won’t work for you, so you need to substitute your own.

You need to specify the template search string as well.  In the case of the general search, it’s simply your Redmine root url plus “/search”.  There are more specific project searches that include “/search/index/project-name”, where project-name is your project’s name, but that was too specific for my purposes.  You also want to tailor your search description.

Once that is customized, I needed to place it in the public directory on my Redmine server, which for me is c:\program files\bitnami redmine stack\apps\redmine\public.  Yours may be different.  I saved it as opensearchdescription.xml, which needs to be referenced elsewhere, so remember the name of yours.

Finally for this step, I wanted an icon associated with the search.  Unfortunately, Redmine hasn’t settled on a favicon as of my version, 0.8.4.  I couldn’t find a good one that is Redmine-specific, so I stole the one from ruby.org.  I also put this in the public directory, replacing the empty one there.

The other piece you need is a way to notify your browser that there is a search provider available.  This is done by a link present in the header of all of your pages on your site.  That requires modification of the base html template used by Redmine (other solutions are welcome, I don’t like customizing core Redmine files).

I added the following to apps/redmine/app/views/layout/base.rhtml, presented here in diff form:

<%= call_hook :view_layouts_base_html_head %>
<!-- page specific tags -->
<%= yield :header_tags -%>
+<link rel="search" href="http://redmine/opensearchdescription.xml"
+      type="application/opensearchdescription+xml"
+      title="Redmine" />
</head>
<body>
<div id="wrapper">

This is a link which I added right before the </head> tag.  It refers to the opensearchdescription.xml file I added earlier.

I also had to restart Redmine and clear my browser cache for everything to show up properly.

Once done, point your browser at your Redmine install and look for the “Add Redmine” entry in your search provider dropdown.  Once you add it, you still need to select the “Redmine” search provider entry.  This should do it.

Patching Redmine 0.8.x for email notifications on added news items regardless of user notification settings

That’s a mouthful.

Redmine 0.8.x does not send email notifications about added news items unless the user’s notification settings are set to permit updates about everything in the project, including all issue updates, etc.  This isn’t a very happy medium.

There is a ticket, #2549 at redmine.org that describes a “watch” feature for the news feed.  This would be ideal.  Since no real action seems to have been taken on it in the last year, I found a way to patch (read: hack) a dumb notification feature into the code.  I provide no warranty for this, it’s provided AS-IS.

The idea is that instead of sending to a project recipient list that has been filtered for users not wishing to see all notifications, to instead simply send to all project members.  To do this, I added a new method to the projects class which provides this unfiltered email list.  It requires two patches:

=== (+2,-2) apps/redmine/app/models/mailer.rb ===
@@ -101,7 +101,7 @@
   def news_added(news)
     redmine_headers 'Project' => news.project.identifier
-    recipients news.project.recipients
+    recipients news.project.news_recipients
     subject "[#{news.project.name}] #{l(:label_news)}: #{news.title}"
     body :news => news,
          :news_url => url_for(:controller => 'news', :action => 'show', :id => news)

and:

=== (+5,-1) apps/redmine/app/models/project.rb ===
@@ -205,6 +205,10 @@
     members.select {|m| m.mail_notification? || m.user.mail_notification?}.collect {|m| m.user.mail}
   end
+  def news_recipients
+    members.collect {|m| m.user.mail}
+  end

   # Returns an array of all custom fields enabled for project issues
   # (explictly associated custom fields and custom fields enabled for all projects)
   def all_issue_custom_fields

 

The second change create a new method, “news_recipients”, which is simply the email list of group members.  The first change makes the news_added event use the news_recipients list instead of the project’s regular recipients list.

This is a very naive approach, isn’t sanctioned by anyone, including me, and could easily have problems I don’t understand.  For example, I have no idea what this does with project members who have been locked out in the administration interface.  If security and privacy are important to your organization, do not use this patch.  You've been warned.

On a side note, I use Mercurial’s MQ extension to maintain such patches to source code on a production system.  This allows me to run with the patches until upgrade time, then to lift and reapply the patches after the upgrade process completes.

TortoiseSVN/Redmine integration

Spent the day working on integrating TortoiseSVN commit logs with Redmine issues.  Some cool stuff is possible.  This post is an adaptation of my status update for this task in my list, so it may not be completely coherent, but here it is:

Accomplished so far:

TortoiseSVN integration:
  1. Added bugtraq:url and bugtraq:logregex properties globally to repository folders
  2. Added webviewer:revision and webviewer:pathrevision properties globablly to repository folders
  3. Tested TortoiseSVN Redmine integration plugin

Redmine settings:

  1. Changed server repository settings so "fixed" keywords close and mark 100% done referenced issues

bugtraq folder properties

Configuration of bugtraq folder properties is described at http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html and http://stackoverflow.com/questions/516542/integrate-tortoisesvn-with-redmine.
These are properties which can be supported by any subversion client which chooses to implement them.  TortoiseSVN supports them.
The bugtraq:logregex property tells the client how to recognize a reference to an issue ID within the comment of a log.  It's value is a pair of regular expressions which tell the client how to recognize a reference to an issue ID and then how to extract the ID number from that phrase.
The pair of regular expressions used in this case is:
([Cc]loses|[Ii]ssue[Ii][Dd]|[Rr]eferences|[Rr]efs|[Ff]ixes(\s[Bb]ug)?)\s?#(\d+)
\d+
This allows the use of the following phrases to refer to an issue ID:
  • References: refs,references,IssueID
  • Fixes: fixes,closes,Fixes Bug
Using any of these phrases in a commit log message will cause TortoiseSVN to recognize it as an issue ID.  Tortoise will highlight the phrase in the commit to let you know it has been recognized.  Then, after committing, when you check the commit log that message will show up with a link for the ID number.  The bugtraq:url property determines how that id is turned into a link.  In this case, it points to the redmine server.  There is also a new column in the commit log which is just for issue ID so you can easily see issue ids in the log.
A log message may reference more than one issue id.  Each reference has to use the phrasing above.
The properties are set on folders.  In our case, they are set uniformly across all folders in the repository.  New folders do not get properties such as this created by default, but as long as most folders have them, it should still work.
It should still work because Tortoise examines the current working copy folder for the properties, and if not found, keeps looking higher in the working copy tree.  As long as one of the parent folders in the checkout has the properties, it will behave correctly.  Since they are currently set on every folder, the likelihood of the properties being found is high.
However, since checkouts are usually done at the project level (just for clarity: project not project group), then the properties need to be set at least at that level.  Therefore, any new project will need to have the properties set on it.  This can be done either explicitly on the project folder when it is created (preferably recursively after subfolders have been created as well).  Or it may be set recursively at a higher level in the directory tree.  This would need to be done either right after the project creation or perhaps by a periodic process sometime later.  A database commit hook could also enforce the setting of the property at the project level, but that would need development.

webviewer folder properties

The webviewer:revision property allows the TortoiseSVN client (and other clients) to relate the log back to a web-based view of the repository.  In this case, it relates to the repository view of Redmine.
When viewing the commit log for a file or folder in Tortoise, right-clicking the context menu when this property is set provides a "view revision in webviewer" context menu entry.  Clicking this entry takes you to the revision's changeset in redmine.  This is useful to see a more Redmine-integrated view of the repository than provided by TortoiseSVN.
The webviewer properties are set on folders similarly to the bugtraq properties and follows the same rules.
There is another property that allows you to go from the TortoiseSVN commit log to the Redmine view of a particular item (file or folder) at a particular revision.  That property is the webviewer:pathrevision property.  As mentioned above, it has been set.

TortoiseSVN Redmine integration plugin

TortoiseSVN issue tracker integration plugins are discussed under the heading Getting Information from the Issue Tracker at http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html.
TortoiseSVN integration plugins are modules that allow TortoiseSVN to retrieve an issue list from the issue tracker itself.  This makes it easier to remember the issue id associated with the changes being checked in.
Integration plugins are TortoiseSVN-specific and must be installed on the same machine as TortoiseSVN.  This means the plugin must be installed on each developer's machine.  It also means that other clients (such as the Visual Studio AnkhSVN plugin) do not get this capability as well.  This makes it easier to use Tortoise to do checkins, but is by no means a reason to abandon other clients.
The TortoiseSVN Redmine integration plugin can be obtained from http://code.google.com/p/chrismckee-project-bay/wiki/REDMINETSVN.
The Redmine plugin adds a button to the commit dialog in the upper right-hand corner.  The button is tied to the Redmine project URL by the configuration of the plugin.  Each Redmine project you are working on must have a configuration in the plugin in order for task lists to be available.
Because the plugin is sensitive to the project location of the working copy, it only shows those issues related to the project being checked in, which greatly simplifies things.  So the extra configuration is warranted and productive.
To configure the plugin, follow the directions at http://code.google.com/p/chrismckee-project-bay/wiki/REDMINETSVN#Setup.  The working copy directory is associated with the plugin and the project Atom feed from the issues list page for the project.  This configuration is done in the TortoiseSVN settings menu.  See the URL for full directions.

Redmine repository settings

The global settings for repositories in Redmine are at /redmine/settings">http://<your redmine server name>/redmine/settings under the Repositories tab.
By default, Redmine can respond to messages in the commit logs of checkins.  It automatically creates associations from an issue to a revision changeset when the issue is references in the commit log.  This makes it easier to keep track of the actual work of a task and changes made.
It can also take the action of closing an issue as well as setting the done percentage by responding to certain keywords in the commit log.
These features are similar to the earlier discussed TortoiseSVN capabilities associated with commit log keywords, but are implemented and configured separately.  The Redmine keyword recognition is performed separately from TortoiseSVN's.
There are two settings in the settings page referenced above.
The first is Referencing Keywords, which tell Redmine to make a link both in the issue as well as from the repository view.  The link in the issue refers to the repository change revision, and the link in the repository refers to the issue.
The second is Fixing keywords, which tell Redmine to set the status of the referenced issue as well as the Done percentage.
The current configuration recognizes the same words used in the TortoiseSVN integration.  refs, references, and IssueID make references.  fixes, closes, fixes bug change the status to Closed and set the Done percentage to 100%.  The ID itself must still be referenced by a pound-sign directly in front of the number such as #25.  Note that when an issue is closed, the link from the repository view still exists but has a strikethrough to indicate the closed status.

Yet more Subversion repository polling headaches

Either there is something very wrong with the way our repository is set up (i.e. my fault) or there is something wrong about the polling model for detecting changes in the repository.
This is the second or third time I’ve run into this issue.  Granted, we have not had the most fastidious design for our repository, however, I can’t believe that what we are doing on this small scale is so outside the pale of what other, much larger organizations (such as open-source hosters) are doing.  I just don’t think we’re that special.
The problem manifested itself today in the form of hundreds of authentications per second against Active Directory from a particular account and server.  The server is our Subversion repository server, naturally, and the account is the special build server account set up to monitor and build from our product locations in the repository.
The tide was sustained over a wide range of time and seemed to be contributing to visible load on the domain controller.  If not harmful, this is at the least embarrassing and annoying for our build infrastructure, which I’m very much invested in.  Nothing I know should be causing this kind of traffic, and if it is a consequence intrinsic to the system, I should find a way to make it less demanding.
I’ve run into similar issues with other tools before.  Evidently, polling a repository for changes is demanding on a repository.  We had an application called SVN monitor which was very nice.  Every time a commit was made to the repository, a notification would pop up from the system tray giving you the details, which you could then inspect with a pretty nice repository browser.  The polling interval could be configured as well.
Unfortunately, we would see enormous spikes in CPU usage on the SVN server when a few users would be polling for changes.  Limiting the number of polled locations and frequency of polling helped performance but greatly hampered the usefulness of the tool.  We eventually replaced it with the repository view from Redmine.
Back to tracking down the current issue.  The SVN server (VisualSVN) is configured for secure connections with Windows Authentication.  The authentication requests to AD coming from this server are responses to SVN clients making requests of the server.  Turning off the SVN server verified that it was indeed the source of the authentication requests.  There were only two servers configured to use that poll the subversion server using the account in question…Redmine and TeamCity, our build server.
The Redmine repository view does take some time (and presumably therefore, effort) to refresh its view.  It uses the subversion command line tools to do so.  However, it should only refresh when you visit the page.  So this isn’t a likely culprit unless something is very wrong.
TeamCity, on the other hand, is constantly polling to show you what changes might be pending for the next build.  This was the likely culprit.  Shutting it down quickly killed all of the authentication requests.  That was the winner.
However, what to do about it is an issue.  Obviously, it isn’t necessary to poll every 60 seconds for every VCS root in TeamCity, but there has to be a happy medium.  I reduced the polling interval globally to 10 minutes, which definitely helped.  There are only four VCS roots, and the TeamCity vcs log shows that they are polled individually each minute (by default)…so why the hundreds of authentication requests.  Something about the way TeamCity polls must break up the poll into lots of small requests, each requiring authentication.  This is what is nailing our domain controller.
Aside from reducing the polling interval, I’m not sure what else there is to do at the moment.  I haven’t posted a question on their support forum, but that’s on tap.  Perhaps there is more to come.

Project Milestones

Too often in the midst of a project, I grapple with making sense of what’s been done, what’s to do, what foggy ideas have sprung to mind and how to call them back to mind, and where I am in the whole mess.  While there is no substitute for clear and simple thinking, I’m not always blessed with that.  The devil is in the details of any project, and what starts as a simple goal with just a few steps often ends up teetering on all of the realities which come to light along the way.
While this may sound dramatic, I’m sure you can relate to the occasional feeling of inertia midway through an important project.  If you’re like me, you’ve been employing healthy doses of action and only minor doses of planning and tracking.  While it makes sense to spend the valuable resource of time on actually accomplishing your goal, you want to keep your footing sure along that path.  In this case, having been sick for a week has done a number on my ability to come back in full stride, so this seems like an opportune time to think about tools and processes to help get and keep things on track.
One great motivator for me is understanding how much time I’ve spent on things.  I’m always pushing along more than one project.  And sometimes I like to call it a day at 5 when I really haven’t put in a full day’s work.  And when it comes to things I like to ignore out of convenience, time-tracking is usually the first to go.
So I’m raising my consciousness in that area once again.  In the past I’ve used Excel spreadsheets to track time.  The handy Ctrl-: (Ctrl-Shift-;) puts in timestamps automatically, and lots of pretty formulas and graphs are a few clicks away.  I keep things simple, so I just track time in and out, not really per-project.
The issue with this is that it’s handy if I want to compare my log to my clocked hours on my paycheck, but it’s not a big motivator and it’s like the lawn…it grows and needs trimming and management periodically.  It’s not a motivator because it’s not easy to see the difference between a day worked hard and a day worked only so-so.  Something a bit more graphical might be useful for that.
I’m trying Klok for that reason.  Lifehacker readers give it the time-tracking five nod, so it can’t be all bad.  So far, it’s simple enough to make it easy to track a few projects at once.  It’s graphical, so it’s easy to see how hard I’ve been working which is nice.  It stays out of the way.  I’m looking forward to seeing how well it puts data out for timesheets/excel/tracking on issues.  It’s not an issue-tracking application, it’s not a project management application, which are reasons I like it so far.  I like applications that stick to doing one thing well and offer ways to integrate with my existing apps.
As far as project planning goes, I’ve got Redmine and some other project planning applications, but nothing I’m really happy with for just showing the overall train of things and where I am.  Today I broke out XMind and made a simple flow for one of my projects using the tree view, which allows for some order.  It’s not really meant for such things, but it’s good because it’s simple and visual, flexible to rearrange and has good status icons.  Not shareable enough though.  Their online mindmap sharing is pretty weak.  I’d like to post an editable, viewable version to Redmine’s wiki, but there’s currently no way to do that and not looking good on the horizon.  In the meantime I’ve decided to just save a copy of the picture to the netdrive to link from the Redmine wiki.  I added a lot more explanation of what the whole process is on the wiki page itself.  So the picture is kind of the “milestones” and where I am, whereas the page text is the more detailed plan.  It might be appropriate to link some of the items on the page to actual issues in the tracking system.  Of course, the overview is still useful (although maybe I should check out the Redmine Gantt?), so despite the fact that it’s not integrated it’s handy to make a unified overview picture.  I think I’ll keep it.
Still trying to get the right balance of planning, action and tracking.

Redmine plugins

I’ve found a number of the Redmine plugins to be innovative and look to be very useful.  Aside from the installation process being, well, command-line driven, they are simple to install and configure, for the most part.
Nothing against the venerable command-line.  I’m perfectly comfortable there.  However, with such a beautiful interface all around, seeing a prompt is fairly ugly in comparison.  And the actuality is that the platform-neutrality of a web interface gets muddied when you have to use the CLI due to the inevitable vagaries of cmd.exe versus bash, etc.  Proper environment variables and such are flies in the ointment.  Module and theme installation page in the Administration section, anyone?
But back to the plugins, the ones I found interesting were:
  • Code Review – automatically create and track issues by commenting on code in the repository.  Slick!
  • Question – Turn issue comments into questions directed at particular users (such as other developers who might have some useful knowledge).  Generates emails.  Great for knowledge capture that might otherwise be lost in forums or emails.
  • Embedded – Create a new tab that allows you to embed non-frames html files.  Useful for auto-generated html such as code documentation, test and coverage reports, etc.
Plugins that are interesting but I had trouble with:
  • Simple CI – Simple monitoring of continuous integration status via an RSS feed.  Looks rudimentary but useful, since the build server is the only important infrastructure not tied into Redmine, but it claimed my TeamCity RSS Feed was invalid even though it worked fine with Outlook.  More troubleshooting.
  • ezLibrarian – Resource reservation/tracking tab for things like books, machines, etc.  While it looks good in theory, the installation left incorrectly labeled tabs and fields.  Looks like an issue with the localization files (the author is not a native English-speaker).  The link given here is also not up to date, as I was able to get a more recent version from his github repository.  However, it did no better.  And what is Booty bay?
  • ezFAQ – from the same author.  A promising looking FAQ generator.  The docs say it doesn’t work with the 0.8.x series however, which is the latest stable.  Too bad.  It also modifies the Redmine core, which makes me leery.  Pass.
More to come on these as they actually see use in our production.
One note about configuring plugins after installation.  While most do not have a configuration section on the Administration > Plugins page, some do.  Some rely on custom fields in the projects, some do not.  Some add settings tabs in the projects.  All need to be enabled in Project > Settings > Modules.
The real trick, is however, that roles need to have permissions enabled on the new module as well.  Administration > Roles and Permissions takes you to the right place.  Look for the new module under each role and choose the appropriate permissions.  Most modules give no rights to any roles by default.

Redmine themes

There doesn’t appear to be a lot of documentation or reviews on the various themes for Redmine.  There are a few themes provided on the Redmine Themes List, along with one I found outside the list, Modula Mojito and its sibling Martini.  While they all look reasonably attractive, I had to try a couple to get a feel for any difference.
I tried two from the official theme list, Squeejee and Watersky.  While both initially seem like just color redefinitions of the basic Redmine UI, Watersky caught my attention because of its use of the famfamfam silk icons and the more light-hearted blue.
Whether these differences are more than skin deep remains to be seen.  Fortunately, Redmine makes it extremely easy to switch themes.  Just unzip the theme into the themes directory and restart the Redmine service, then choose the new theme from the Settings page.
Noteworthy is the SP theme, which is not yet released but is most assuredly a deep reworking of the Redmine UI.  Be sure to check out the demo which is just amazing.  Very professional and sure to be a virtual requirement for Redmine usage soon after release.  Fortunately the designers, Shane and Peter, have agreed to open source the theme.  Hopefully this will work itself in (as the default theme?) the mainline Redmine distribution.
Great work!

Moving Redmine Wiki pages and Connecting to the Bitnami MySQL instance

Apparently, you can’t move wiki pages between
Redmine projects like you can with Redmine issues.
I found this out because I was trying to rename a project’s URL in Redmine, but once the identifier is assigned, I guess you can’t do that either.  Or perhaps you can using a similar method to what I discuss here, I just didn’t think to go back and try mucking with the ID directly in MySQL.
In any case, the next best thing is to go into the MySQL tables and reassign the wiki_id of the pages you want to move.  So I made my new project, then tried to find a client with which to manipulate the tables.
I’m running Bitnami’s Redmine 0.8.4 on Windows, and after a little while I came across the MySQL GUI Tools Bundle.  They have a nice Windows installer, which worked fine.
The only trouble I had initially was getting the credentials.  I didn’t have any network issues, as I loaded the tools directly on the same server.  When it asked me for the connection details, I found I had to look up the username and password.  These are stored in Redmine’s database.yml file, under the production instance, which is located in Redmine’s config directory.
The GUI Query tool complained that I didn’t specify a default schema, mainly because I had no idea which one’s were available.  Apparently Bitnami gets in on the act here, since once I was able to open the database I could see the schema name is actually “bitname_redmine”.  This was ok by me.
The last piece was actually getting the identifiers and issuing the update.
From the “wikis” table I was able to get the id (not “project_id”) of the wikis in question.  I had to do the select manually since there didn’t seem to be a simple way to make the tool show me the table contents automatically.
Then the query was something like:
UPDATE wiki_pages
SET wiki_id = <new>
WHERE wiki_id = <old>
Executing the query worked, and then I was able to list all of the pages under the index of the new Wiki through Redmine.  One last touch was to copy and paste the contents of the old start page to the new start page manually.  Then I deleted the old start page and I was done.

Getting Subversion Repository access working with Bitnami Redmine 0.8.4 stack

I’ve been playing with Redmine for some time and am still impressed with the basic issue tracking and wiki functionality, but since starting to work with issues, I haven’t been tying them to work done in the source code repository.
Looking to remedy this, I set up the repository access details according to the project settings page.  This involved naming the Source Code Management system (Subversion), the root URL for the project, and a suitable login and password.
I did all this correctly, yet when I went to the Repository page for the project, all I got was an error saying the revision was not accessible.
A bit of research didn’t come up with a direct solution, but I did come to have a suspicion that worked out to be true.
First, I found out that the repository functionality in Redmine relies on the command-line subversion client.  This didn’t come with the Bitnami Redmine Stack (I’m on Windows, btw), so I installed it and rebooted to make sure the PATH environment variable got set properly.
After this, I ran the svn command as a test:
svn info https://my.repository.com/root
This prompted me to store the server credentials, which I accepted permanently.  This was definitely something I realized that I now how to do from the service account for Redmine.
Redmine, however, was configured to use the local system account, which doesn’t have an interactive login.  While I could have changed the service logon, I am loathe to do that to a running system.  Who knows what permissions will break.
Luckily, I remembered an old trick from the Sysinternals guys: psexec.
psexec allows you to do a telnet-like session to your own or another machine, including setting the user credentials.  It also has a special ‘-s’ switch for logging in as the system account.
A few tries got me to the magic incantation:
psexec –s –i cmd.exe
This got me an interactive window running the command interpreter as the local system account, which I verified by checking the environment variables.
Running the svn command allowed me to store the server credentials under the system account.
However, my ordeal was not over yet.  Fortunately, reading the Redmine Guide had alerted me to the fact that the first time you run the repository view, it takes a long time to index the repository into the database.  They weren’t kidding.  My browser finally timed out waiting for it to complete (but I knew some progress had been made since it was actually taking time this time around). Watching the server’s load with Process Explorer (another great Sysinternals tool) I could see it peak, sustain, trough and peak again over and over.
When it finished, I reloaded the web page, and voila!  Redmine repository happiness with Bitnami Redmine Stack as a local system service on Windows.