Am 20.11.2005 um 17:11 schrieb Juliusz Chroboczek:
darcs batch take-lock
darcs batch release-lock
I wonder if we could combine these two together? Or could we at least
make
it so that release-lock can only release a lock taken by take-lock?
You're right; an additional issue is potentially holding the lock for
extended periods of time.
I think the solution is to switch to a ``store conditional'' type of
approach. Darcs whatsnew would provide an opaque token uniquely
identifying the current state of the repo (using either a hash or the
last modification date). Darcs batch record would take this token as
an argument, and fail if the current state of the repo doesn't match
the token.
Nice idea. I think the lock should also be "attached" to a PID.
A hash should be only a part of the "token" since although it is very
likely to be "unique", it is not guaranteed to be...
Suggestion:
- Exactly all (not necessarily direct) child processes of the PID have
access to the repository/lock.
- When the process with the locking PID dies the lock is released.
- This PID is given as an optional command line argument to the lock
command and is accepted only if it is the PID of a (not necessarily
direct) parent of the resulting Darcs process and has the same UID (and
probably some other constraints).
If no PID is given on the command line the PPID of the resulting Darcs
process is taken.
This would allow something like (Bash):
token=`darcs batch take-lock`
( darcs ... && darcs ... )
darcs batch release-lock $token
Daniel
_______________________________________________
darcs-users mailing list
[email protected]
http://www.abridgegame.org/mailman/listinfo/darcs-users
