transport shouldn't indirect through control_files
Bug #86919 reported by
Martin Pool
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Bazaar |
Fix Released
|
Medium
|
Martin Pool | ||
| bzr (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Bug Description
affects bzr
The Branch/
instance, typically called .control_files. Many of their transport
operations are passed through this object, which forwards them to the
Transport.
This does not seem to particularly help anything and possibly
discourages these objects from using more efficient methods that might
be available on the transport. It doesn't actually check that write
methods are guarded by the lock and doing so might not be really useful.
(And we could always have that protection in the transport if we wanted
it.)
--
Martin
| Changed in bzr: | |
| assignee: | nobody → mbp |
| importance: | Undecided → Medium |
| status: | New → Confirmed |
| Changed in bzr: | |
| importance: | Undecided → Low |
| status: | New → Triaged |
Revision history for this message
| Martin Pool (mbp) wrote | #1 |
Revision history for this message
| Martin Pool (mbp) wrote | #2 |
| Changed in bzr: | |
| status: | Confirmed → Fix Released |
| Changed in bzr (Ubuntu): | |
| status: | Triaged → Fix Released |
To post a comment you must log in.
bzr no longer indirects through control_files for IO-type operations, which was the original purpose of this bug. The main purpose of LockableFiles as it currently exists is to coordinate a transaction object with the state of the lock. It also still provides the _find_modes method.
_find_modes is already softly deprecated in favor of BzrDir.
If this reasoning is correct, then Branch, which does not use get_transaction, should never need a control_files. (Removing it may strictly be a compatibility break for Branch though.)
There are also quite a large number of methods on Branch that just forward to the control_files, that can go to a CountedLock instead.