Re: [Monotone-devel] Error handling via automate

[Nathaniel Smith]

On Sun, Sep 10, 2006 at 10:00:11AM +0200, Thomas Keller wrote:
> Nathaniel Smith schrieb:
> >Another possibility in this particular case would be "automate update"
> >simply require that the caller provide the target revision; then this
> >error can't happen.  Instead, the caller would go to get the target
> >for the update, discover there were multiple candidates, and then ask
> >the user (or whatever) before calling update at all.
> 
> Theoretically this is possible, yes, obviously there is the small chance
> that between mtn automate heads and mtn automate updates a db
> transaction happens, which commits a new head and therefor result in an
> update to a (maybe) unwanted revision.
> Yes, the chance is very, very small, but I don't feel good about this =)

It could just as well happen that immediately after you run 'update',
but before you have a chance to even look at your shiny new workspace,
some new revision arrives that, had it arrived just a few seconds
earlier, you would rather have updated to it.  Oh well, we have to
get used to that possibility; lucky thing our tool works perfectly
correctly either way :-).

(In fact, the situation is logically the same as if someone committed
a new revision to some _other_ database, and the reason you don't see
it is not because of a race condition in update, but because it hasn't
even been pushed yet.  Lots easier to relax than to worry about such
things.)

-- Nathaniel

-- 
Damn the Solar System.  Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
  -- Lord Jeffrey