Yes, sorry. when something is deleted you need to record that something is no longer there rather than just deleting the record, as it creates an ambiguous scenario. Is it missing asset on the client, or do you actually want to remove the asset from all connected clients.
Honestly it's the edge cases that make replication/synchronization complicated. I would think about them now as you'll like find that you need to go back and add additional components to your solution to deal with them. In many cases these are non trivial.
To address your original question I would use both a rev number and a timestamp(sequenceID). The timestamp will track what changes have been accepted by the server or client. You need to track this as if you ask for everything since the last updated but for some reason encounter an error and only write the first five of ten items you need to be able to pick up where you left off.
Revision is important as you need some way of know if you're trying to commit data from a client to a server where the data is "out of date".
Say two clients and server have REV_1 of some asset. Client A makes a change and tries to commit the change. For whatever reason the client connection drops and the change isn't immediately pushed. Meanwhile client B also makes a change, but this is accepted by the server and now our asset is REV_2. When Client A reconnects, it is now trying to update REV_2 data with REV_1 data. That same client will also receive an update transaction as client B has beat it to the server. you now have a conflict scenario, but without rev numbers you wont know how to handle the changes. Using only time stamps client A made the first change, but client B was the first to update the server. Which one is newer? I guarantee that you will run into this scenario at some point and it's much better to engineer for that eventuality from the start.
You can still resort to simple handling such as first one in wins but there needs to be some logic there.
The couchDB protocol ( use the newer version) does a good job of calling to light all the potential problems. You can then work through how you want to handle them. In an always connected scenario, e.g, don't allow changes unless connected to the server, it's a bit simpler. However if you're building a mobile app or even desktop apps you may want to allow disconnect scenarios.