Coffee|Code : Dan Scott, Caffeinated Librarian Geek

I've posted a second revision of the "academic reserves" requirements RFC. I'm not looking to boil the ocean with the first iteration of academic reserves for Evergreen (that's what third-party systems like ReservesDirect and Ares are for), but I am hoping that by engaging the community in a discussion we can ensure that we build something that satisfies the core set of requirements for academic institutions in the area of reserves. My lack of familiarity with what other institutions with more capable systems, or with local workarounds or third-party reserves systems installed, makes me nervous that I'm missing something obvious. So if you feel like weighing in on the discussion, please address your comments to the Evergreen General mailing list, add a comment here, or send me email if you prefer to keep your comments private.

The biggest change in the second revision of the RFC is the inclusion of a base set of requirements for electronic reserves. For physical items alone, the requirements expressed in the RFC go far beyond the capabilities of the ILS we currently use at Laurentian; getting even basic support for electronic reserves in Evergreen would be a huge win for us when we migrate.

That said, I'll probably start working on implementing a subset of the requirements real soon now; it should be easy enough to make a course correction should something significant turn up during the second round of comments.

I wrote a long blog post about the distributed version control workflow that the two Laurentian students working on Evergreen (Kevin Beswick and Craig Ricciuto) are using successfully this summer, only to lose the post to a session timeout and my own lack of caution (note to self: if writing directly in the browser text field, CTRL-A CTRL-C before hitting preview!). So the gist of the blog post was:

• bzr, with the bzr-svn plugin, works quite well for cloning and updating from a centralized Subversion repository like Evergreen's; just watch out for memory consumption issues due to memory leaks in the Python bindings for Subversion (fixed in the development version of bzr-svn)
• there's no compelling reason for Evergreen to move to a different version control system; it's easy to use a distributed version control workflow with the Evergreen Subversion repository as-is
• you can tar up a bzr branch and untar it where ever you like and "bzr up" will immediately happily work (which is how I worked around the severe memory constraints on this server that ended up repeatedly running into the Linux out of memory killer when I was trying to create a bzr-svn checkout from scratch)
• it's a hell of a lot faster to check out or branch from a bzr repository than it is from a Subversion repository, so if you're going to take this approach set up one clean bzr repository using bzr-svn and check out or branch from that using bzr, rather than repeatedly using bzr-svn to create new branches

To enable you to get a bzr repo of Evergreen quickly, I've set up (unofficial, of course, but updated hourly) bzr repositories of the most useful Evergreen branches as follows:

• Evergreen trunk
• Evergreen acq-experiment (acquisitions and serials branch)
• OpenSRF trunk

Enjoy!