My current point of view is that repository should contain entity-specific modification methods like Add, Delete, etc. and UnitOfWork should contain just methods that are relevant to it in general like Commit (also known as SaveChanges, SubmitChanges) and Rollback (also known as ClearChanges). But Martin Fowler in his article about UnitOfWork suggests to add all modification methods to UnitOfWork.
So which way is better now, in the world of EF and NHibernate?
Update.
I should note that even with my preferable approach finally all modifications through repository go into UnitOfWork which is built into EF Context or NHibernate Session. And my UnitOfWork is more like UnitOfWorkManager (which manages internal ORM UnitOfWork).
In NHibernate world main functionality of UnitOfWork in implemented by ISession. ISession keeps track of what has changed and you do not need to have methods like RegisterClean or RegisterDirty. For a larger projects it is useful to hide ISession by using your own class that can be called UnitOfWork. For example:
The advantage of hiding ISession from application code is that this code will not reference NHibernate directly which enforces better layering. In other words it will be harder for application layer to start using NHibernate API directly, bypassing data access layer.
The repository itself will contain methods for adding new objects and possibly deleting: