monotone

Issue 7: fix minor race conditions in working copy rewriting

Reported by Unknown User, Feb 24, 2004

(This entry was imported from the savannah tracker, original 
location: https://savannah.nongnu.org/bugs/index.php?7894)

it is possible that if you run two copies of monotone concurrently 
or abort a run part way through an update or checkout, the working 
copy may be left in an inconsistent state relative to its manifest. 
no harm done to database, and the gap is already quite small and 
unlikely to be a problem; also unclear whether it's possible to 
solve perfectly.

Comment 1 by Unknown User, Feb 14, 2005

Perhaps I'm thinking too simply here, but what's wrong with keeping 
a lock in the MT/ directory and refusing to run monotone in the 
directory if it's held?

Comment 2 by Unknown User, Feb 17, 2005

See tests/t_undo_update.at for a description of a feature that would 
be very nice anyway, and would perhaps make this problem reasonably 
easy to solve Correctly.

Created: 20 years 2 months ago by Unknown User

Updated: 19 years 2 months ago

Status: New

Labels:
Type:Incorrect Behavior
Component:Working Copy
Priority:Medium

Quick Links:     www.monotone.ca    -     Downloads    -     Documentation    -     Wiki    -     Code Forge    -     Build Status