I'm trying to build a system which follows the repository and unit of work patterns to allow persistence ignorance/unit testing, etc etc. I'm looking for advice on dealing with Rollback. Ideally I want to use POCO's but I think I might need to at least implement an interface to provide a few bits and pieces.

So lets say we have two repositories, one context/unit of work.

I add one item, amend another item and delete a third item. Repeat for second repository, then I call rollback.

In the past I've used something akin to a DataSet for this. Each object has a state of pendingNew, pendingAmended, pendingDeleted, clean. There is also a copy last persisted version of the object for rollback. 

How would you implement this?

EDIT:

Ok, here's what I think I'm actually trying to get my head around. Prepare to be patterned :)

Ultimately the project is WPF MVVM. So we're looking at the Model to what ever the store is here.

I think I've been trying to conflate the model with the idea of repository, where as I think the model should use the UOW and Repositories to provide the features the model needs to provide. Does that sound better?

I want complete persistence ignorance, so imagine my domain includes a Customer, an Order and OrderLines. 

The GUI let's say has one button new order which allows the user to fill in Customer details, Order details and 1-n OrderLine details. He hits save and they go to the database, he hits cancel they don't.

So, in this case the model might ask the CustomerRepository for a customer, then the OrderRepository for a new Order, then the OrderLineRepository for each new Line, then tell the Unit of Work to save them.

Does that sound reasonable? It does to me, I think it's where the separation is defined. I'm half tempted to have another API between the model and the repositories. No, that's silly.

EDIT 2: This is an excellent article that has sort of [helped](http://codebetter.com/gregyoung/2009/01/16/ddd-the-generic-repository/) a little.