lock oddity

Jeff Licquia jeff at licquia.org
Wed Nov 21 20:55:53 GMT 2007


John Arbash Meinel wrote:
> The problem with setting a limit, is that all limits are essentially arbitrary.
> Some might say that a lock held for longer than 1 hour is strange. But then you
> get the person who is pushing their Mozilla source tree over dialup, because
> that is all they have.

At least on Linux, bzr seems to be aware of the PID of the locking 
process.  Could we be more aggressive, perhaps, if the process is missing?

I realize this may be difficult on Windows, but could we keep the 
current behavior there, and check processes on platforms which support it?

> I would probably say that your build process should be more forceful about
> complaining when updating fails. I'm pretty sure 'bzr pull' returns a different
> code if there are no changes versus if there are changes versus if something
> else fails (could not connect, lock timeout, etc.).

In the case of this particular build process, it complicates matters 
that the bzr update phase and build phase are completely separate jobs.

We could, I suppose, have some kind of notification on update failure; 
we already have that for builds.  Then, lock handling could be 
completely manual.




More information about the bazaar mailing list