Merge lp:~mwhudson/launchpad/puller-import-hack into lp:launchpad
| Status: | Merged |
|---|---|
| Approved by: | Aaron Bentley on 2010-04-15 |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | not available |
| Proposed branch: | lp:~mwhudson/launchpad/puller-import-hack |
| Merge into: | lp:launchpad |
| Diff against target: |
324 lines (+90/-80) 6 files modified
configs/testrunner/launchpad-lazr.conf (+0/-1) lib/lp/codehosting/codeimport/worker.py (+12/-8) lib/lp/codehosting/puller/tests/__init__.py (+1/-0) lib/lp/codehosting/puller/tests/test_acceptance.py (+10/-26) lib/lp/codehosting/puller/worker.py (+4/-36) lib/lp/codehosting/vfs/branchfs.py (+63/-9) |
| To merge this branch: | bzr merge lp:~mwhudson/launchpad/puller-import-hack |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Aaron Bentley (community) | 2010-04-14 | Approve on 2010-04-15 | |
|
Review via email:
|
|||
Commit Message
Use vfs-level copies when moving import branches around -- faster than 2a fetch, and safe because we control how the branches are made.
Description of the Change
Hi,
This branch adds a few hacks to the handling of code imports to avoid the problems of cpu intensive slow fetch.
In particular, when getting the branch from the central area to the slave and when pulling an imported branch to the codehost for the first time, just copy the branch at the vfs level.
Deploying this on production depends on https:/
Cheers,
mwh
| Michael Hudson-Doyle (mwhudson) wrote : | # |
On 15/04/10 03:41, Aaron Bentley wrote:
> Review: Needs Information
> What is the impact of removing the testrunner bzr_imports_
Yes, the value in the development config is a file:/// url.
> Instead of remote_
Ah, cool, thanks.
> Some of the test changes look like drive-bys, e.g. not wanting it to leave directories behind. Is that right?
I don't think I've really changed anything here, just folded the
addCleanup that followed every invocation of makeCleanDirectory into the
method itself.
> Is there a reason to join config.
No, none. Fixed.
> Did you consider using more specific name than _is_import? e.g. _vfs_initial_clone ? Or what about providing an initial_clone method on the BranchPolicy itself?
I thought about that name for about a microsecond, I have to admit.
Making it a method on the policy makes sense, partly because then it can
be tested separately...
> What about using sets to represent files_before and files_after? That's closer to the abstract representation, because order isn't important, and entries can only appear once. I don't really understand the purpose of this loop, either.
Yes, good point.
The point of the loop is to cope with the not-quite-
possibility that the branch being copied might be being written to as we
grab it. I think it can be written a bit more clearly now you mention
it, take a look.
> It might be nice to turn _runWithTransfo
Please no :-)
I think I have a strategy for getting rid of using the transform
fallback hook entirely now bzr has an ignore_fallbacks argument for
branch opening, but I'm more likely to do that in my no-hosted-area work
than here :)
Interdiff attached, although just looking at the preview diff again is
likely just as clear.
Cheers,
mwh
| Aaron Bentley (abentley) wrote : | # |
There was still another spot where you could use root_transport in lib/lp/

What is the impact of removing the testrunner bzr_imports_ root_url? Does this cause it to default to a more suitable value?
Instead of remote_ bzr_dir. transport. clone(' ..'), you should be able to use remote_ bzr_dir. root_transport.
Some of the test changes look like drive-bys, e.g. not wanting it to leave directories behind. Is that right?
Is there a reason to join config. launchpad. bzr_imports_ root_url and the branch id with path.join instead of urlutils.join?
Did you consider using more specific name than _is_import? e.g. _vfs_initial_clone ? Or what about providing an initial_clone method on the BranchPolicy itself?
What about using sets to represent files_before and files_after? That's closer to the abstract representation, because order isn't important, and entries can only appear once. I don't really understand the purpose of this loop, either.
It might be nice to turn _runWithTransfo rmFallbackLocat ionHookInstalle d into a ContextManager, but that's not necessary for this branch.