bzr_set.py doesn't report locked branches

Bug #637929 reported by Daniel Watkins (credativ)
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Server (MOVED TO GITHUB)
Confirmed
Wishlist
OpenERP's Framework R&D

Bug Description

If the bzr_set.py script hits a locked branch, it just sits idle, without reporting this fact. This can be a real pain, and should be fixable.

Changed in openobject-server:
status: New → Triaged
Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote :

Interesting improvement, keeping as wishlist for after v6.0.
Thanks for the suggestion!

Changed in openobject-server:
assignee: nobody → OpenERP's Framework R&D (openerp-dev-framework)
importance: Undecided → Wishlist
status: Triaged → Confirmed
Revision history for this message
Dimitri John Ledkov (ex-credativ) (dle-credativ) wrote :

Has this been considered for 6.1?

Revision history for this message
Olivier Dony (Odoo) (odo-openerp) wrote : Re: [Bug 637929] Re: bzr_set.py doesn't report locked branches

On 07/31/2011 10:11 PM, Dmitrijs Ledkovs (credativ) wrote:
> Has this been considered for 6.1?

No, but as this is a quite unrelated to core code, it could be improved
regardless of any release roadmap :-)

It might be a simple improvement, but a quick look at the bzrlib API did
not reveal anything to specify fail-fast locking for the bzr commands.
You would think that lock contention would always cause a timeout error,
similarly to what happens when you call these commands manually.

Maybe someone from the community would like to investigate further, and
perhaps provide clear steps to reproduce, or even a patch?

Revision history for this message
Ana Juaristi Olalde (ajuaristio) wrote :

Clear steps for reproduce:

1. Execute bzr_set.py
2. During execution, cut before finishing all branches.
3. The branche that is downloading on this moment stays locked. So next time
you execute bzr_setup you will have again the error.
5. manual solution: Go to de the downloading folder. Look for
.bzr/branch/lock and erase it.
Next time... if you execute bzr_set.py and all branches are downloaded,
problem is solved. If next time, error is shown again, it's better erasing
all .bzr/branch/lock subfolders located on all branches that you are
downloading, before starting script again.
It's a kind of little nighmare each time it happens.

Wishing this will give you a clue...

Thank you:

Ana

2011/8/6 Olivier Dony (OpenERP) <email address hidden>

> On 07/31/2011 10:11 PM, Dmitrijs Ledkovs (credativ) wrote:
> > Has this been considered for 6.1?
>
> No, but as this is a quite unrelated to core code, it could be improved
> regardless of any release roadmap :-)
>
> It might be a simple improvement, but a quick look at the bzrlib API did
> not reveal anything to specify fail-fast locking for the bzr commands.
> You would think that lock contention would always cause a timeout error,
> similarly to what happens when you call these commands manually.
>
> Maybe someone from the community would like to investigate further, and
> perhaps provide clear steps to reproduce, or even a patch?
>
> --
> You received this bug notification because you are a member of OpenERP
> CTP, which is subscribed to OpenERP Server.
> https://bugs.launchpad.net/bugs/637929
>
> Title:
> bzr_set.py doesn't report locked branches
>
> Status in OpenERP Server:
> Confirmed
>
> Bug description:
> If the bzr_set.py script hits a locked branch, it just sits idle,
> without reporting this fact. This can be a real pain, and should be
> fixable.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-server/+bug/637929/+subscriptions
>

--
Ana Juaristi Olalde <http://www.anajuaristi.com/>: Personal phone: 677 93 42
59. User/usuario skype: Avanzosc
CEO Avanzosc, S.L <http://www.avanzosc.com/> : Office phone / Tfono oficina:
(+34) 943 02 69 02
www.openerpsite.com

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.