"Backrev" is a software term, sort of the opposite of "upgrade". It means to go back to an older revision of a given program, library, or what-have-you. I'm assuming that the "rev" is derived from "revision", and I may well be wrong, but I can't seem to find any etymological background on the term.
Backrevving happens for two reasons: Some choose to backrev, and some have backrevs forced upon them by a broken installer.
Why would one choose to do this? It's not rare for new versions of software to be savagely broken; I seem to recal that NT4 service pack 1 broke the system so badly that people had to reinstall the OS from scratch. Version 1.0 of anything is usually a mess, but it's rare for the patch to make matters even worse. Be that as it may: That was a case where those who "upgraded" had to backrev for their lives. The initial release of version 6 of Microsoft's C++ compiler also had catastrophic effects on the system, requiring the user not merely to backrev the compiler/IDE/etc. itself, but also to reinstall the operating system. The service pack worked that time.
An involuntary backrev is an uglier matter. Most modern software comes packaged with an installer, which is a program which installs the software. Modern software also generally uses shared libraries of code, sometimes called DLLs. These "libraries" usually reside in a central location, and all programs go there to find them at runtime. In most cases, there will be many versions of a given shared library, and a given program will require or prefer to use a version of the library no older than a given date. For that reason, appropriate libraries are shipped with software, so they can be installed on the vict^H^H^H^Hend-user's system.
Now, a well-behaved installer will check the version of the library that's already installed, compare that to the version it's got, and install its own only if its own copy is newer than what the user's already got. Not all installers are well-behaved. Some of them blindly replace what's already there. If it's newer, they'll backrev it to whatever older version they've got.
Now imagine that yesterday you installed Filibuster 3.7, and it upgraded your syscrap.dll library to version 4.0, which is what Filibuster 3.7 requires in order to run. Today you install Iguanodon 3.0, which was released three years ago. It uses syscrap.dll too, but back then the current version of syscrap.dll was 2.4. Iguanodon 3.0 blindly and mindlessly replaces syscrap.dll 4.0 with syscrap.dll 2.4. Remember that eight hundred bucks you spent on that shiny new version of Filibuster, with the new vibrating widgets and counter-rotating button bars? And the flashing/rotating chart creator so you can give people epileptic fits during sales presentations and get them to sign the check before they recover their senses? Remember that? It won't run now. And all because you installed stupid Iguanodon 3.0 so you could put pictures of pretty girls petting lizards in your Excel spreadsheets. Now you have to call the system administrator and ask him to fix it, and he'll find out about those sexy lizards. You'll be bitterly ashamed. The sysadmin will waste half an hour finding the problem, and then he'll find a newer version of syscrap.dll somewhere and replace the obsolete one with that. He'll walk away muttering. The good news is that it's very likely that Iguanodon 3.0 will work fine with the newer version of syscrap1.
It's a nightmare, but there's no good way to avoid it. Sometimes it happens, and then you're stuck. You can't know until it's too late. The developers of the Iguanodon installer should've known better, but it's a problem that can very easily escape notice: When they wrote it, they were installing the newest version of syscrap. So what if that got blindly copied over whatever was there? That would not have caused a detectable problem back then:
If they never tested the install on a system with a newer version of that file, the problem never would have manifested.
Since a newer version did not exist at that time, it's not a problem that normal testing would catch.
A search on Google turns up a wealth of hits related to Novell and a few in the UNIX/Linux world, mostly referring to the voluntary sense of the term. It seems that NetWare admins spend most of their time installing ever-older versions of the product. I don't envy them.
I have often heard the term from Windows developers, but now that I think of it, they were all ex-NetWare developers (Draw your own conclusions about Novell's future, if any). In the Windows world, the involuntary-backrev problem used to be very common. It's getting less so as installers improve. "Backrev" is the only term I've heard to describe that situation, though I have heard people use verbose, ad-hoc terminology like "the [expletive deleted] [expletive deleted] installed an older [expletive deleted] version of the [expletive deleted] DLL [expletive deleted] [expletive deleted] ".
1 There are exceptions. New releases generally fix some bugs and introduce others. Some programs will have workarounds for old bugs, and very rarely the workaround will no longer work right when the bug is gone. There's also the matter of new bugs requiring new workarounds in old code. That sort of thing doesn't ruin your day too often, though.