On Fri, May 31, 2013 at 8:47 AM, Julian Foad <julianf...@btopenworld.com> wrote: > That's OK for manual investigation, but we're looking for a solution that > suitable for building into infrastructure management scripts, so it needs to > be portable and reliable, and stable across OS upgrades and the like.
Repositories on network storage also complicates this. We could use the contents of the write-lock file to store some details of who has the lock and possibly why (is it a freeze or not). When someone takes out a write lock they'd open the file with an exclusive lock and write out the details into the file. There would be a brief period where the data was unavailable, but we have to deal with that anyway because older code won't be writing this data out anyway. Given that freeze was intended for backup purposes I think a timeout for the lock is needed. People need a way to know that the backup failed. Without a timeout a permanently write-lock repo would just stack up more and more freeze commands as cron tried to run future backups. We've essentially made that more likely with the freeze command since if the command freeze is running never exits the write lock never gets returned.
