Merge lp:~jameinel/bzr/2.0.4-unregister-mem-trans into lp:bzr/2.0
| Status: | Rejected |
|---|---|
| Rejected by: | John A Meinel on 2010-01-08 |
| Proposed branch: | lp:~jameinel/bzr/2.0.4-unregister-mem-trans |
| Merge into: | lp:bzr/2.0 |
| Diff against target: |
269 lines (+54/-32) 3 files modified
bzrlib/tests/__init__.py (+1/-1) bzrlib/tests/test_transport.py (+45/-28) bzrlib/transport/memory.py (+8/-3) |
| To merge this branch: | bzr merge lp:~jameinel/bzr/2.0.4-unregister-mem-trans |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| John A Meinel | Disapprove on 2010-01-08 | ||
| Martin Pool | Disapprove on 2010-01-08 | ||
| Andrew Bennetts | 2010-01-07 | Approve on 2010-01-08 | |
|
Review via email:
|
|||
| John A Meinel (jameinel) wrote : | # |
| Andrew Bennetts (spiv) wrote : | # |
Looks good to me.
I wonder a little if the risk/reward tradeoff is right for lp:bzr/2.0, but it's probably fine. Definitely good to have in trunk, of course.
| Martin Pool (mbp) wrote : | # |
I would not merge this to 2.0 at least without further discussion: it doesn't specifically fix serious bugs, it is fairly large and it has some risk.
I hope John just misclicked when proposing the merge.
| John A Meinel (jameinel) wrote : | # |
There are a fair amount of mechanical changes (move MemoryTransport => memory.
255 @@ -315,11 +318,13 @@
256 result._files = self._files
257 result._locks = self._locks
258 return result
259 - register_
260 + self._memory_
261 + register_
262
263 def tearDown(self):
264 """See bzrlib.
265 # unregister this server
266 + unregister_
267
268 def get_url(self):
269 """See bzrlib.
Which I feel is sufficiently small to warrant merging to 2.0. If Martin feels differently, I'm fine only merging this to 2.1.
| Martin Pool (mbp) wrote : | # |
I think the main thing here is
* it doesn't actually benefit 2.0 users
* it makes the diff bigger for people to read in the next SRU
* any code change, even mechanically, has some small risk
I tried to explain this more in https:/
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Pool wrote:
> I think the main thing here is
>
> * it doesn't actually benefit 2.0 users
> * it makes the diff bigger for people to read in the next SRU
> * any code change, even mechanically, has some small risk
>
> I tried to explain this more in https:/
I had forgotten about the need to have a bug for SRU purposes.
Generally, I try to target anything small to 2.0, because otherwise my
default behavior is to just do everything in 'dev' and then nothing gets
into 2.0.
I'll just land this in 2.1.
merge: rejected
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkt
n8MAnRzNCbfTBRU
=XA3T
-----END PGP SIGNATURE-----
Unmerged revisions
- 4721. By John A Meinel on 2010-01-07
-
Add a test case.
- 4720. By John A Meinel on 2010-01-07
-
Have MemoryTransport
.tearDown unregister its transport. Small improvement, but it does free up a bit of memory, etc when running
a big test suite. (After running all of per_pack_repository, 84 memory
server instances are still registered.)

Martin noticed that MemoryServer doesn't unregister itself. This adds that to tearDown, and adds some tests for it.
In a quick test, I did see a bunch of MemoryServer registrations left over at the end of the test suite. For example, running all of "per_pack_ repository" (300 tests) left about 84 registered memory transports. From what I can tell it doesn't actually leave the MemoryServer in memory, just some functions registered in the transport_ list_registry. However, it is hygienic to clean them out.