Locking problem (showstopper)

[Steve Bennett]

> -----Original Message-----
> 1) Are you using modified version of bzr or some plugin? Because
> mainline bzr does not have option --date for commit. Is it possible
> that your non-mainline version is incorrect?

Sorry, I should have mentioned that explicitly. I added about 3 lines to the
current bzr.dev version to add that feature. I doubt it's related, but who
knows?

> 
> 2) I'm not sure that I understand how to reproduce your problem.
> If it's repeatable error, can you provide exact sequence of actions?

I don't have an exact repro case yet. It tends to happen after some hundreds
or thousands of commits, which takes a few hours. I hope to get a better
idea of what triggers it. In the meantime I've hacked the source to remove
the prompt for breaking the lock, and I'm just breaking the lock and
retrying whenever it occurs. It seems to work...?

> It seems that repository stays locked (repository lock is actually
> special dir + special file with locking info) when you run `bzr update`.
> Is it possible, that you run several concurrent commands on the same time?

Nup, it's all definitely sequential. The way I'm running the command ensures
that Python.exe terminates before it runs the next command. But maybe bzr is
doing some multithreading or something and hasn't quite finished a command
occasionally?

> 
> 3) I don't understand why for you need local commits and then updates.
> If you wish import your old repository in Bazaar, I think
> the best way is to write special plugin for this task, if there is no

Yeah I know that's what I "should" do. The two main reasons I haven't done
this are that 1) I don't know Python and 2) we aren't committed to Bazaar.
If we end up using Subversion (or something else), then 80% of the code I'm
writing for the import is still applicable. If I write a custom import to
the BZR import tool (I forget its name for the moment), then that effort is
lost if we don't end up using Bzr.

> support for your old VCS. And even in the case if you don't want to
> write special plugin for import, you don't need local commits + update,
> IMO.

I don't "need" them. I'm using them for the pretty output - I'm doing local
commits on all sequential revisions with the same commit message, then doing
a real commit on that group. But if you think it's causing the problem,
maybe I should avoid doing that?

> 
> 4) There is probability that repository lock is removed by bzr, but it
> stays
> some time on disk. And if you have fast enough computer with slower HDD,
> may be it's the case. Also, there is option for NTFS HDD to choose between
> speed and reliablity of data on disk. Open properties for your HDD,
> select third tab on the properties panel (I don't have english windows,
> so I'm not sure how exactly it named, probably equipment[s], or
> device[s]),
> on device properties panel select Policy tab, and you'll see checkbox,
> that enable/disable write cache. May be this option will help in your
> case.

Hmm, interesting idea. I could try just putting an extra delay in somewhere?
I've certainly run into problems of this nature in the past with Windows,
where a process using a file terminates, then another process tries to
delete the file, but it can't, for a few seconds.

That actually sounds like the most likely suspect...and may lead someone to
a solution. Perhaps when the "unable to delete" error is encountered on
Windows, it needs to wait a couple of seconds then try once more?

I might try pausing for an extra couple of seconds every time I do a commit.

Steve