There’s also a good argument for a “none of the above” approach.
The problem with generic repositories is that you’re making the assumption that all objects in your system will support all four CRUD operations: Create, Read, Update, Delete. But in complex systems, you’ll likely have objects that support only a few of the operations. For instance, you might have objects that are read-only, or objects that are created but never updated.
You could break the IRepository interface into small interfaces, for Read, Delete, etc. but that gets messy pretty quickly.
Gregory Young makes a good argument (from a DDD / software layering perspective) that each repository ought to support only the operations that are specific to the domain object or aggregate you’re working with. Here’s his article on generic repositories.
And for an alternate view, see this Ayende blog post.