[merge] errors in deleting obsolete packs should not be fatal (was Re: Problems with NFS mounted filestore)

[Russel Winder]

On Mon, 2008-05-26 at 08:00 -0500, John Arbash Meinel wrote:

> Bazaar itself can be run from source without much difficulty. It should be as
> simple as running 'make' and then symlinking 'bzr' to something like ~/bin/bzr.
> 
> I would recommend a shared repository, in case you end up with more than one
> branch of bzr, but if you don't expect that, there is no difference.
> 
> bzr init-repo bzr
> cd bzr
> bzr co http://bazaar-vcs.org/bzr/bzr.dev
> cd bzr.dev
> make
> cd ~/bin
> ln -s ~/bzr/bzr.dev/bzr
> 
> You can apply Martin's patch with:
> 
> ~  bzr merge ../martins_changes.patch

Thanks for these instructions.  I followed them (more or less) and was
able to test Martin's patch -- fortunately it seems bzr-svn 0.4.10 works
with bzr 1.6.0 :-)

> Or you can wait a day or two when we've approved his patch and it is in bzr.dev.

I think Martin was angling for me to test it as part of the patch
approval.

> bzr is quite single-threaded. Also, these files are generally renamed from
> .bzr/repository/packs => .bzr/repository/obsolete-packs. If the files were open
> at the time, the rename would fail on windows.
> 
> And we only rename the stuff that we've determined to be copied into a new file,
> so they should have all been closed, etc. It is *possible* that a second process
> has opened those files, but it should be close to impossible for the 'bzr'
> process itself to still hold them.

OK that seems to indicate a second process rather than a branching
internal thing.  As I was checking Martin's branch I checked what was
around:

|> ps ax | grep bzr
10367 ?        S      0:00 /usr/bin/python /usr/bin/bzr dbus-broadcast
18310 pts/15   S+     0:00 tail -f .bzr.log
18507 pts/16   S+     0:12
python /home/users/russel/Repositories/Bazaar/Branches/Bzr/MartinsNFSPatch/bzr branch svn+ssh://www.concertant.com/home/subversion_repositories/ConcertantLLP
18547 pts/6    R+     0:00 grep bzr

10367 looks suspicious.  I killed it and tried again but no, the problem
still happens:

|> bzr branch svn
+ssh://www.concertant.com/home/subversion_repositories/ConcertantLLP 
bzr: ERROR: Device or resource busy:
"/home/users/russel/tmp/BazaarExpts/ConcertantLLP/.bzr/repository/obsolete_packs/.nfs0000000000c84276000000c1": [Errno 16] Device or resource busy: '/home/users/russel/tmp/BazaarExpts/ConcertantLLP/.bzr/repository/obsolete_packs/.nfs0000000000c84276000000c1'

It seems then that there must be something within the Bazaar branch
activity that is sequencing the delete in the wrong place -- but I am
speculating wildly based on no knowledge of the Bazaar codebase.

> RAII is a great model, but it unfortunately doesn't work well in python, or most
> auto-GC languages. Because you can't guarantee when your object will get garbage
> collected, especially if it ends up involved in a reference cycle.
> 
> Python has a 'try/finally' semantic which works just as well inside a function.
> (It doesn't do quite as well when you might be handing the resource out to
> different places, which may decide that you no longer need it, etc)

True.  RAII is close to useless per se in Java, Groovy, and Ruby as well
as Python; RAII is very much a C++ idiom.  However the philosophy that
underlies it is very relevant.  As you say try/finally is a good model
(for Java and Python) as is "execute around" which is used in language
with closures such as Ruby and Groovy.

The problem I find, which is clearly not the case here, is that far too
many Java, Groovy, Python, and Ruby people have never heard of RAII, and
are not sensitive to the resource allocation issues that it solves in C
++.

Of course there is the with clause in Python but I am not sure it allows
enough flexibility, but I need to play with it more.
 
-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080526/56f2ebb8/attachment.pgp