Implementing repositories "by the book" will typically mean to create one per entity or table (see here, for example). However, when your entities are uniform, and all of your repositories look very similar, it can make sense to implement a generic repository class (just as shown in the former link). That will probably be the better alternative for avoiding too much boiler plate code than the "big-ball-of-mud" repo.
Nevertheless, Fowler's description of the repository pattern does not explicitly require to have one repo per entity. So I agree to Telastyn: when there is bundled data, which has to be pulled and pushed always together in one query or transaction, it can make more sense to have one repo for more than one table.