[Monotone-devel] commit, queue, and post design

[Kevin Smith]

I'm increasingly uncomfortable with the way monotone handles queuing 
changes to be sent to a depot.

The immediate problem is that I have a bunch of packets queued for 
depots that no longer exist. Yes, I know I can delete them with sql, and 
that a command would be easy to add. Another warning sign for me is my 
confusion about not being able to push and unchanged fetched tree to my 
depot, and whether I ought to push the history or not.

Fundamentally, it seems wrong to queue packets at commit time. If depots 
are added or removed between the commit and the post, everything gets 
messed up. Really, the post command itself should figure out what each 
depot needs, and send it. As a side effect, commit would be a bit faster.

Essentially, right now monotone stores "state" about each depot. That 
seems overly complex and error-prone.

Am I off course here?

Kevin