[00:12] <jelmer> fullermd: it shouldn't have to - fixing that is probably an easy fix
[00:12] <jelmer> fullermd: IIRC annotate doesn't require a working tree, it's probably just that it takes a lock on the working tree if there is a working tree
[00:14] <bob2> tree.try_lock_all_the_things()
[00:17] <jelmer> roughly
[00:28] <lifeless> fullermd:  jelmer: annotate annotates local edits too
[00:28] <lifeless> edit the file, then annotate it, local changes will show up appropriately.
[00:28] <jelmer> lifeless: that depends on the arguments though
[00:28] <lifeless> right, but thats' the default
[00:28] <lifeless> and fullermd didn't specify args.
[00:28] <jelmer> lifeless: e.g. 'bzr annotate -r3' takes a lock on the working tree where it shouldn't
[00:29] <jelmer> I didn't realize fullermd was doing a non-arguments annotate
[00:30] <lifeless> jelmer: I don't know if he is or isn't ;)
[00:31] <fullermd> I am, but even if it needs to lock to do that, it shouldn't sit around holding the lock forever   :p
[00:31] <fullermd> "bzr ci ; mmm...   ; bzr ci ; ... wtf is holding a lock?   *search* *search* *search* Oh, look, there's a ^Z's less off in another terminal..."
[00:34] <fullermd> (not that I'm _entirely_ sure why ann'ing local changes requires locking the dirstate either, but hey, locking for a second or two to do the ann is ignorable...)
[00:34] <lifeless> fullermd: so this is more a dirstate bug than annotate
[00:34] <lifeless> fullermd: because the dirstate can't be *read* safely without locking; the new one I put up a proof of concept of fixes this.
=== wedgwood_away is now known as wedgwood
=== wedgwood is now known as wedgwood_away