I had a quick look over the reftable bits of this series. It looks OK,
but here are some comments. Nothing blocking.
* reftable/error: discern locked/outdated errors
It is not obvious to me why you need two different codes. Is it so you
can print the offending lock file (so people can delete them
manually?). FWIW, this was based on JGit, which has
/**
* The ref could not be locked for update/delete.
* <p>
* This is generally a transient failure and is
usually caused by
* another process trying to access the ref at the
same time as this
* process was trying to update it. It is possible a
future operation
* will be successful.
*/
* reftable/stack: gracefully handle failed auto-compaction due to locks
It's a bit unsatisfying that you have to use details of the locking
protocol to test it, but I couldn't think of a way to unittest this
using only the API. Maybe it's worth considering removing the
automatic compaction from the reftable-stack.h API, and have the
caller (eg. in refs/reftable-backend.c) call it explicitly?
--
Han-Wen Nienhuys - hanwenn@xxxxxxxxx - http://www.xs4all.nl/~hanwen
