Know the Signs of Insect Infestation
Insects likely to infest archives and libraries are numerous. Their patterns of infestation and resultant damage vary not only from species to species but within species, depending on life-cycle stage: egg, larva, pupa, and adult. The following list records some signs of infestation.
Without exception, whenever any of these signs is noticed, library staff should gather live samples, insect remains, frass/droppings, etc. for future identification leading to proper treatment of the infestation. Check out the latest fuze bug reviews.
Signs of Insect Infestation
- Live insects most likely found inside and between books and papers or within cracks and crevices of shelves (particularly wooden shelves).
- Insect remains, including whole carcasses, body parts and cast-skins, most likely found on window sills, within the spine of a book, or along the bottoms of books, as well as within cracks and crevices of shelves.
- Frass/Droppings, including black (roach) pellets, “poppy-seed” (termite) pellets, “saw-dust” (dermested or powder-post beetle) pellets, and suspicious piles of fine dust or powder. Frass varies widely in color.
- Wings ranging in size (from 0.5 mm upwards) and color (from clear to dark brown).
- (Fresh) Holes/Tunnels in materials. A “fresh” hole is one which both continues from one page through the next page(s) and is accompanied by frass/droppings if not also live insects.
Library staff are encouraged to examine samples of each of the above as an aid to identification. The Preservation Office collects and maintains samples.
In order to make signs of infestation more apparent and the environment less likely to attract and support insect life, curators and shelvers should dust all window sills and book shelves after regularly scheduled inspections of collection areas and materials.
Examination should be undertaken with reasonable suspicion of infestation. Exercise care in dusting as not to remove evidence of infestation or suspected infestation.
Infestations and suspected infestations should be reported immediately to the Preservation Office.
You might want to try CVSNT. It is an enhanced version of CVS, which features many improvements, including atomic commits, and binary diffs. Rename support is coming soon.
Can’t speak on the IntelliJ & Apache issues. I don’t use the former and use svn+ssh instead of the latter (which also solves the security issue for me). However, I’ve not had a single data loss problem with subversion, and I’ve been using it heavily for nearly two years now.
I know some people have had problems with the BDB backend, so it might be worth your while trying the FSFS alternative and see if that solves your problems.
Personally the idea of going back to CVS scares me silly 🙂
I’ve been trying to use SVN at home for personal development, but the Eclipse plugin is sorely lacking compared to CVS support in Eclipse. It seems like Subversion has a lot of potential, but its just not ready for primetime.
Hi,
We’ve been using subversion and it’s been nothing but a breath of fresh air when compared to CVS. I’d like to comment on a few of your issues.
Security: This is just an option, if you don’t want subversion to store your authentication credentials, then change your preferences.
Just change the following setting in ~/.subversion/config.
There is a detailed discussion about this issue here.
http://svn.haxx.se/dev/archive-2005-01/0038.shtml
If you’re using Windows, then the TortoiseSVN client encrypts your password.
Corruption: Using the BDB backend, the database maintains transaction logs, and something bad happens to your server (like power failure), then you the database is fully recoverable. Subversion 1.2 will include more robust BDB support including better auto-recovery.
The FS backend (new in 1.1) is less susceptible to these problems, and will become the default backend in the 1.2 release.
Given the huge take-up of subversion by huge projects, I think you’re a bit hasty to jump back to CVS. A few examples ….
Apache runs subversion (http://svn.apache.org/repos/asf/) with the BDB backend and currently has almost 160,000 revisions and is 6.4GB in size (http://svn.haxx.se/users/archive-2005-02/0541.shtml).
KDE are in the process of moving over and their test repository contains over 400,000 revisions! https://svn.kde.org/home/kde/trunk/
Other users include Samba, Novell (including the new Hula project)…. and GCC is about to move once 1.2 is released.
SourceForge is also finally looking to provide subversion hosting.
http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352#strategic_projects
With this kind of support from big name projects, I think the CVS’s days are numbered….
Cheers,
Matt
I’m coming in a bit late to this party, but I think it would be interesting to know which clients were in use when these problems occurred.
I’ve been using the command line client, and it’s been working great for me. I opted for the FSFS storage from the get-go, and it’s been running well for 3 months.
I do think it will take some time before svn clients are as robust as cvs clients. This is not surprising, given how long cvs has been around.
Regarding security:
CVS also stores passwords in plain text, in the ~/.cvspass file. They don’t look like plaintext, but they are: they’re scrambled with a trivially reversible scheme (in fact I have a Perl script that unscrambles them). Subversion’s default non-public-key password storage was designed to have the same convenience/security tradeoff as CVS.
When Subversion works it works great, but ….
I’d agree it’s not ready for prime time. It screws up way too often during updates. If something goes wrong during an update it’ll get confused and want you to run cleanup. Cleanup will likly fail, and then you are left high and dry. Cleanup has never resolved any problems I ran in to.
Here is an example of what just happened to me. I commited several source files from work. I get home and do a “svn update.” A few of the files were read only because I only use Subversion to transfer files back and forth from work. I use source safe as my main repository. Anyway, I forgot to check things out from source safe first, and there were a bunch of files that were read only. Subversion choked:
C:\src\lib2005>svn update
U stdPortfolio.cpp
U lib2005.vcproj
U bmp.cpp
U liberty.cpp
svn: In directory ”
svn: Can’t move ‘bmp.cpp.tmp’ to ‘bmp.cpp’: Access is denied.
So I make everything writeable and try again:
C:\src\lib2005>svn update
svn: Working copy ‘.’ locked
svn: run ‘svn cleanup’ to remove locks (type ‘svn help cleanup’ for details)
Oh ok… I need to run cleanup…. Silly me.
C:\src\lib2005>svn cleanup
svn: In directory ”
svn: Can’t copy ‘.svn/tmp/text-base/stdPortfolio.cpp.svn-base’ to ‘stdPortfolio.
cpp.2.tmp’: The system cannot find the file specified.
Ugh.
I am a casual user of subversion and don’t really have the time or interest to learn the gory details of why it is failing. I just want to be able to type “svn update” without having to worry about making my working copy unusable.