bug#5291: 23.1.91; "bzr status" FAILED

[Dan Nicolaescu <dann@ics.uci.edu>]

Eli Zaretskii <eliz@gnu.org> writes:

  > > Date: Sun, 03 Jan 2010 06:09:58 +0200
  > > From: Eli Zaretskii <eliz@gnu.org>
  > > Cc: 5291@debbugs.gnu.org
  > > 
  > > > Date: Sat, 2 Jan 2010 14:17:30 -0800 (PST)
  > > > From: Dan Nicolaescu <dann@ics.uci.edu>
  > > > Cc: 5291@debbugs.gnu.org
  > > > 
  > > > What exactly creates the d:/gnu/bzr/emacs/trunk/bzr_log.ahvp69 file?
  > > 
  > > "bzr commit" does.  This file is where it puts the list of files to be
  > > committed, then submits it to $EDITOR (in my case, emacsclient), and
  > > expects me to insert the commit message there.  After "bzr commit" is
  > > done (i.e., the changes committed), this file is deleted by bzr.
  > > 
  > > > Is your TEMP set to d:/gnu/bzr/emacs/trunk/ ?
  > > 
  > > No.  AFAIU, bzr creates these temporary files in the directory where
  > > you run "bzr commit".  I see these files created in the current
  > > directory on GNU/Linux as well, although I will have to check if the
  > > same problem happens there as well as on Windows.
  > > 
  > > > I think that if you change:
  > > >                    (vc-bzr-command "status" t 0 file)
  > > > to:
  > > >                    (vc-bzr-command "status" t 3 file)
  > > > in vc-bzr-status
  > > > it should work, but I am not 100% sure that's TRTD.
  > > 
  > > OK, I will look into this when I have a chance.  Thanks.
  > 
  > I found the problem.  It seems to be Windows-specific.  (I cannot
  > reproduce it on GNU/Linux, but I have a slightly different version of
  > Bazaar there, so it could be bzr-version specific as well.  Still, the
  > nature of the problem (see below) makes it a safe bet that it exists
  > only on Windows.)
  > 
  > The detailed reason for the failure is found in the .bzr.log file:
  > 
  >   LockContention: Could not acquire lock "D:/gnu/bzr/emacs/test/.bzr/checkout/dirstate": (32, 'CreateFileW', 'The process cannot access the file because it is being used by another process.')
  > 
  > What happens is evidently this:
  > 
  >   . I run "bzr ci", which locks dirstate and launches emacsclient to
  >     edit the commit message that it puts on a temporary file
  >     bzr_log.FOO in the directory where I run "bzr ci".
  > 
  >   . The file with the commit message pops up in Emacs, where I edit it.
  > 
  >   . When I'm done editing, I save the bzr_log.FOO file.
  > 
  >   . Emacs then run "bzr status bzr_log.FOO" as a side effect of C-x
  >     C-s, because the file is inside a versioned directory.  This "bzr
  >     status" tries to lock dirstate again, which fails, because Windows
  >     fails the CreateFileW system call due to sharing issues.
  > 
  > I could probably submit a bug for Bazaar, but they would probably say
  > that Emacs is to blame as well as Bazaar: it is Emacs who invokes the
  > second instance of bzr while the first is still running.

It seems that this is actually a combination of bzr "features": putting
a temporary file in a versioned directory plus the fact that "bzr status" blocks 
when a commit is in progress (i.e. a read lock blocks when a write lock
is on).

  > It would be nice if I could tell Bazaar to put those bzr_log.FOO files
  > under $TMPDIR, but there doesn't seem to be a way of doing that.
  > Anyone?
  > 
  > Any ideas for how best to resolve this?

Not sure we want to do something in emacs about this, it looks like bzr
needs fixing.